TLS X.509 certificate hygiene...

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS X.509 certificate hygiene...

Viktor Dukhovni

I've recently come across an interoperability problem between my
DANE survey scan engine and some STARTTLS implementations on remote
SMTP servers.  The issue resulted from an upgrade of the TLS library
(not OpenSSL, which does not seem to mind) on my side, which introduced
more strict checking of the certificate "keyUsage" extension.

This seems to be intended to address Bleichenbacher-style attacks
on the legacy RSA key exchange mechanism which performs "Key
Encipherment", while these days the preferred mechanism is
DHE or ECDHE which uses the certificate for "DigitalSignature".

There is no mention of enforcing keyUsage constraints in TLS RFCs,
prior to TLS 1.3 (RFC 8446 appendix E.8) and even there there is
not a clearly stated requirement to perform such enforcement.

So there's no need to "panic", but I though I'd mention that
your certificates should probably either not set "keyUsage"
at all, or if they do, it makes more sense to rule out
RSA key transport, rather than restrict oneself to it.

Therefore, make sure your certificate (not extended)
keyUsage is either not there at all, or perhaps
specifies:

        keyUsage = digitalSignature

and perhaps not "keyEncipherment" (RSA key transport).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: TLS X.509 certificate hygiene...

Alice Wonder
On 11/05/2018 06:58 PM, Viktor Dukhovni wrote:

>
> I've recently come across an interoperability problem between my
> DANE survey scan engine and some STARTTLS implementations on remote
> SMTP servers.  The issue resulted from an upgrade of the TLS library
> (not OpenSSL, which does not seem to mind) on my side, which introduced
> more strict checking of the certificate "keyUsage" extension.
>
> This seems to be intended to address Bleichenbacher-style attacks
> on the legacy RSA key exchange mechanism which performs "Key
> Encipherment", while these days the preferred mechanism is
> DHE or ECDHE which uses the certificate for "DigitalSignature".
>
> There is no mention of enforcing keyUsage constraints in TLS RFCs,
> prior to TLS 1.3 (RFC 8446 appendix E.8) and even there there is
> not a clearly stated requirement to perform such enforcement.
>
> So there's no need to "panic", but I though I'd mention that
> your certificates should probably either not set "keyUsage"
> at all, or if they do, it makes more sense to rule out
> RSA key transport, rather than restrict oneself to it.
>
> Therefore, make sure your certificate (not extended)
> keyUsage is either not there at all, or perhaps
> specifies:
>
> keyUsage = digitalSignature
>
> and perhaps not "keyEncipherment" (RSA key transport).
>

if not using keyUsage but using extendedKeyUsage within req_extensions
should digitalSignature be used?

I basically do the following for my postfix certs

[req]
distinguished_name     = dn
req_extensions         = ext
prompt                 = no

[dn]
CN                     = ${FQDN}

[ext]
basicConstraints       = critical,CA:FALSE
extendedKeyUsage       = serverAuth,clientAuth
subjectAltName         = @san

(obviously with any alternate names in [san]

-=-

I'm also under the impression that the basicConstraints likey isn't
necessary because CA:FALSE is assumed when not specified. Is that true?
Reply | Threaded
Open this post in threaded view
|

Re: TLS X.509 certificate hygiene...

Viktor Dukhovni


> On Nov 5, 2018, at 10:18 PM, Alice Wonder <[hidden email]> wrote:
>
> if not using keyUsage but using extendedKeyUsage within req_extensions should digitalSignature be used?
>
> I basically do the following for my postfix certs
>
> [req]
> distinguished_name     = dn
> req_extensions         = ext
> prompt                 = no
>
> [dn]
> CN                     = ${FQDN}
>
> [ext]
> basicConstraints       = critical,CA:FALSE
> extendedKeyUsage       = serverAuth,clientAuth
> subjectAltName         = @san
>
> (obviously with any alternate names in [san]

This is perfectly fine.  And "digitalSignature" is only a "keyUsage" bit,
extendedKeyUsage is about higher-level application purpose "OIDs", not
the basic keyUsage bits.

A typical RSA certificate from a CA will have (using the equivalent
OpenSSL value names):

        keyUsage = keyEncipherment, digitalSignature
        extendedKeyUsage = serverAuth, clientAuth

Now the "keyEncipherment" bit is a concession to legacy interoperability,
and is perhaps no longer wise.  You get better resistance to some attacks
by going with just "digitalSignature", provided you're willing to forgo
RSA key exchange.  However, there are likely still various sending MTAs
that don't support PFS (DHE/ECDHE) ciphers, and disabling RSA key exchange
in MTA is likely premature.

Check your logs for evidence of TLS <= 1.2 ciphers that don't have
"AECDH", "ADH", "ECDHE" or "DHE" in their names.  On my personal domain
I see in recent logs:

22850 ADH-AES256-GCM-SHA384
 2425 ECDHE-RSA-AES256-GCM-SHA384
  804 AECDH-AES256-SHA
  382 AES256-GCM-SHA384
  368 ECDHE-RSA-AES256-SHA
  293 ADH-AES256-SHA
  234 DHE-RSA-AES256-GCM-SHA384
  160 ECDHE-RSA-AES256-SHA384
  158 DHE-RSA-AES256-SHA
   39 DHE-RSA-AES256-SHA256
    1 ECDHE-RSA-AES128-GCM-SHA256

No inbound connections out of ~27k that use non-PFS RSA key transport.
So it sure looks like I'd not cause any cleartext downgrades or other
problems by listing a keyUsage of just "DigitalSignature".

That said, most client likely don't enforce the keyUsage, so it is
likely to not matter much yet.  Just something to keep in mind as
things evolve...

--
        Viktor.

P.S.

FWIW, my inbound TLS 1.3 connections are pretty much all from freebsd.org
mailing lists:

   TLSv1.3 with cipher TLS_AES_256_GCM_SHA384

here we don't see "DHE" or "ECDHE" in the cipher name, because TLS 1.3
ciphers are defined and negotiated separately from signature algorithms,
so the cipher name does not say anything about which asymmetric algorithms
were used for key exchange and authentication.

The only other use of TLS 1.3 is from a couple of "iDevices" in the hands
of two of my submission users, so some Apple software is doing SMTP
submission with TLS 1.3.

Reply | Threaded
Open this post in threaded view
|

Re: TLS X.509 certificate hygiene...

pg151
Viktor,

On Wed, Nov 7, 2018, at 12:03 AM, Viktor Dukhovni wrote:
> Check your logs for evidence of TLS <= 1.2 ciphers

Doing the quick check you mentioned, first for my messy 'test' server, results are just

        11 TLS_AES_256_GCM_SHA384

Those log messages, for me, are all generated on internal connections, e.g.,

        /var/log/postfix/postfix.log:Nov  4 15:21:45 mx postfix/postscreen-internal/smtpd[15675]: Anonymous TLS connection established from mx.example.com[XX.XX.XX.XX]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

IIUC (?), 'something' in my current config, is enabling that internal use of the TLS_AES_256_GCM_SHA384 cipher ... and, if I were to disable 'keyEncipherment' and generate/use new certs, I'd likely drop to cleartext?

Here, atm,

        cat master.cf
                [mx.example.com]:25  inet  n  -  n  -  1  postscreen
                 -o postscreen_tls_security_level=may
                 -o smtpd_service_name=postscreen-internal
                 ...

                postscreen-internal  pass  -  -  n  -  -  smtpd
                 -o syslog_name=postfix/postscreen-internal
                 -o smtpd_tls_security_level=may
                 ...

and

        cat main.cf
                ...
                smtp_tls_mandatory_protocols     = !SSLv2, !SSLv3
                smtpd_tls_mandatory_protocols    = !SSLv2, !SSLv3
                tlsproxy_tls_protocols           = $smtpd_tls_protocols
                tlsproxy_tls_mandatory_protocols = $smtpd_tls_mandatory_protocols
                smtp_tls_protocols               = !SSLv2, !SSLv3
                smtpd_tls_protocols              = !SSLv2, !SSLv3
                lmtp_tls_protocols               = !SSLv2, !SSLv3
                lmtp_tls_mandatory_protocols     = !SSLv2, !SSLv3
                smtpd_tls_eecdh_grade = auto
                tls_eecdh_auto_curves = X25519 X448 secp384r1 prime256v1 secp521r1
                tls_preempt_cipherlist = yes

                tls_high_cipherlist   = !PSK:!aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED!CAMELLIA:AEAD:-AEAD:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:@STRENGTH
                tls_medium_cipherlist = !PSK:!aDSS:!MD5:!kECDH:!kDH:!RC2:!RC5:!IDEA:!SEED!CAMELLIA:AEAD:-AEAD:CHACHA20:-CHACHA20:aNULL:-aNULL:HIGH:MEDIUM:@STRENGTH

                smtpd_tls_mandatory_ciphers = medium
                smtpd_tls_ciphers           = medium
                smtpd_tls_mandatory_exclude_ciphers =  aNULL
                smtpd_tls_exclude_ciphers           = EXPORT, LOW, RC4, eNULL, NULL
                tlsproxy_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers
                ...


If, in fact, I need to NOT use the "non-PFS RSA key transport", even for that internal transport, would I need to specifically, additionally exclude a particular cipher/protocol here?

Or is it simply not an issue, and unaffected, for this internal transport?

For that matter, is it possible to specifically limit that internal transport to a specific, efficient but secure, cipher?

I suspect it all needs a modernizing clean-up, since, admittedly, it's a bit long-in-the-tooth ...
Reply | Threaded
Open this post in threaded view
|

Re: TLS X.509 certificate hygiene...

Viktor Dukhovni
On Wed, Nov 07, 2018 at 08:07:40AM -0800, [hidden email] wrote:

> On Wed, Nov 7, 2018, at 12:03 AM, Viktor Dukhovni wrote:
> > Check your logs for evidence of TLS <= 1.2 ciphers
>
> Doing the quick check you mentioned, first for my messy 'test' server, results are just
>
> 11 TLS_AES_256_GCM_SHA384

That's TLS 1.3, which as I mentioned is a different beast.  It
always does PFS, and never RSA key exchange, but this is not reflected
in the cipher name, because the ciphers no longer specify the key
exchange method.

> /var/log/postfix/postfix.log:Nov  4 15:21:45 mx postfix/postscreen-internal/smtpd[15675]: Anonymous TLS connection established from mx.example.com[XX.XX.XX.XX]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>
> IIUC (?), 'something' in my current config, is enabling that internal use of the TLS_AES_256_GCM_SHA384 cipher ... and, if I were to disable 'keyEncipherment' and generate/use new certs, I'd likely drop to cleartext?
>

No, you just did not read my post carefully enough... :-)
The TLS 1.3 connections are out of scope and can be ignored.

> If, in fact, I need to NOT use the "non-PFS RSA key transport",
> even for that internal transport, would I need to specifically,
> additionally exclude a particular cipher/protocol here?

If you wanted to avoid RSA key transport, you could add 'kRSA' to
your list of *smtpd* TLS cipher exclusions.  I'm not saying that
you should do that, but if RSA key transport is never used in
practice, it may be reasonable to disable it.

Outbound, I still see a handful of kRSA connections to sites that
don't have PFS turned on:

   6 omgi.iij.ad.jp   AES128-GCM-SHA256
   1 nibbler.inwx.net AES256-GCM-SHA384

and it is the *server* operator's job to define the appropriate
policy for their own keys/certs.  So I would not at this time suggest
any similar exclusion for the SMTP client.

Keep in mind that TLS in SMTP is still predominantly opportunistic,
and generally even less than perfect encryption is still better
than none.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: TLS X.509 certificate hygiene...

pg151
Viktor

On Wed, Nov 7, 2018, at 8:34 AM, Viktor Dukhovni wrote:
> ...

Thx for the clarifications!

> That's TLS 1.3, which as I mentioned is a different beast.  It
> always does PFS, and never RSA key exchange, but this is not reflected
> in the cipher name, because the ciphers no longer specify the key
> exchange method.

ah!  missed/misunderstood that completely!

Re: this particular, *internal* connection,

/var/log/postfix/postfix.log:Nov  4 15:21:45 mx postfix/postscreen-internal/smtpd[15675]: Anonymous TLS connection established from mx.example.com[XX.XX.XX.XX]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

i.e., 'between' *my* external/postscreen listener instance and *my* internal/after-postscreen smtpd instance, does it make any particular difference/improvement to explicitly change/limit that cipher to a single, mandatory choice?  given that it *IS* tls1.3 with PFS, my inclination is simply ... leave it be.

> No, you just did not read my post carefully enough... :-)

yeah, yeah, we've been OVER that already.  wouldn't be the *1st* time! ;-)

( in my own "defense" 'careful reading' does not _necessarily_ always equate to 'correct understanding' :-) )

> The TLS 1.3 connections are out of scope and can be ignored.

Got it.

> Outbound, I still see a handful of kRSA connections to sites that
> don't have PFS turned on:
>
>    6 omgi.iij.ad.jp   AES128-GCM-SHA256
>    1 nibbler.inwx.net AES256-GCM-SHA384
>
> and it is the *server* operator's job to define the appropriate
> policy for their own keys/certs.  So I would not at this time suggest
> any similar exclusion for the SMTP client.
>
> Keep in mind that TLS in SMTP is still predominantly opportunistic,
> and generally even less than perfect encryption is still better
> than none.

Yep.  That message is certainly clear enough. And a good reminder, nonetheless, of the assumptions about TLS usage in SMTP 'vs' in webserver.
<rant>Even though, TBH, I've 'had it' with lazy AND sloppy server admins, and would LIKE to erase them from my server interactions.  I don't mind broken -- I do my own fair share of that! -- as long as you're at least 'trying' to keep current/secure.</rant>

Reply | Threaded
Open this post in threaded view
|

Re: TLS X.509 certificate hygiene...

Viktor Dukhovni
On Wed, Nov 07, 2018 at 08:52:26AM -0800, [hidden email] wrote:

> Re: this particular, *internal* connection,
>
> Nov  4 15:21:45 mx postfix/postscreen-internal/smtpd[15675]:
>   Anonymous TLS connection established from mx.example.com[XX.XX.XX.XX]:
>   TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
>
> i.e., 'between' *my* external/postscreen listener instance and *my*
> internal/after-postscreen smtpd instance, does it make any particular
> difference/improvement to explicitly change/limit that cipher to a single,
> mandatory choice?  given that it *IS* tls1.3 with PFS, my inclination is
> simply ... leave it be.

No leave it be.

--
        Viktor.