Subject: [TLS] TLS and KCI vulnerable handshakes

From: Clemens Hlauschek <[email-masked]>
Date: Mon, 10 Aug 2015 12:12:42 -0400

Hi,

I published a paper today on KCI-attacks in TLS. This might be of
interest to the TLS WG.

https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek

Regards,
Clemens

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Aug 2015 18:05:36 +0000

Clemens Hlauschek <[email-masked]> writes:

>I published a paper today on KCI-attacks in TLS. This might be of interest to
>the TLS WG.
>

Some comments on this, it looks like it requires a "cert with static (EC)DH
key" in order to work, which would mean an X9.42 cert.  Since no (public) CA
that I know of can handle or issue such certs, this probably provides a
reasonable amount of defence against this attack...

In terms of the suggested countermeasures:

>Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and
>disable specifically the KeyAgreement flag

Since the keyUsage flags are widely ignored by implementations, this won't
provide the protection that the text implies.

Peter.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 11 Aug 2015 14:25:42 -0400

> reasonable amount of defence against this attack…

No, a regular ECDSA certificate would do.
That is, the attack would work as long as 
- a client has an ECDSA certificate, and
- it enables any static TLS_ECDH_* cipher suite, and
- its ECDSA private key has been stolen (or chosen) by an attacker.

Best,
Karthik

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Aug 2015 11:29:12 -0700

> - its ECDSA private key has been stolen (or chosen) by an attacker.

I don't see how that would work.  A client that understands the cert
to be ECDSA won't pair the key with the server's ECDH share, they will
sign the session transcript with it.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 11 Aug 2015 22:05:44 +0300

> sign the session transcript with it.

a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is
no ECDSA-specific keytype in X.509.

b) SSL v3.0 server PoP (still there in TLS v1.2) does not sign
transcript but only the public key (only TLS 1.3 fixes this).
Logjam, anyone?

c) Non-signature client certs (like ECDH) don't have transcript
signatures either.

Attacker can just replay randoms and SKE, and then compute client-
side PMS. Game Over, EMS will not save you.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Aug 2015 14:06:31 -0700

> no ECDSA-specific keytype in X.509.

Maybe I should have been clearer.  The certificate might not include a
(strong) signal that allows the client to distinguish between ECDSA
and fixed ECDH, but the client might be configured with that
knowledge.

I checked NSS and there doesn't seem to be any way that it could be
coerced into using the (EC)DH pair from a client certificate in a key
exchange.  Even though it supports some fixed (EC)DH suites.

NSS (incorrectly) adopts the posture that _ECDH_ suites are
half-static: the server share is in the certificate, but the client
side is fully ephemeral.  This is clearly in violation of RFC 5246,
Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
that right now :)

---

From: Clemens Hlauschek <[email-masked]>
Date: Tue, 11 Aug 2015 19:38:43 -0400

> and fixed ECDH, but the client might be configured with that

There is no difference between an ECDH and an ECDSA, apart from
(possibly) the KeyUsage Extension.

> exchange.  Even though it supports some fixed (EC)DH suites.

To the best of our knowledge, NSS does not support fixed ECDH client
authentication. I checked the code manually. Prof Matt Green also
verified with EKR at Mozilla during the pre-public disclosure phase that
NSS is not vulnerable.

> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about

Please elaborate. I do not see how this half-static behaviour
constitutes any violations of the mentioned RFCs. I would say
half-static ECDH handshake is not only fully spec conforming, but *the*
way to do an ECDH handshake when client authentication (*_fixed_(ec)dh)
is not requested by the server. OpenSSL, as well as other
implementations, do the same.

Clemens

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Aug 2015 16:59:35 -0700

> (possibly) the KeyUsage Extension.

I'l try again.  Even if the certificate does not include that signal,
the software that accepts that signal might make assumptions or have
configuration that cause it to only be used in one way or another.
See NSS.

> constitutes any violations of the mentioned RFCs.

Both the above cited sections say very clearly that for fixed (EC)DH
cipher suites the client where the client has a fixed (EC)DH
certificate, the client MUST send an empty ClientKeyExchange.

Of course, you might say that this is simply a consequence of not
supporting fixed (EC)DH for client authentication, and then it's not
technically in violation.  The value of the ClientCertificateType from
the CertificateRequest is likely important here, but that field is
systematically ignored in practice (NSS ignores it).

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 11 Aug 2015 20:19:30 -0400

On Tue 2015-08-11 19:59:35 -0400, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek <[email-masked]> wrote:
 [ MT wrote: ]
> certificate, the client MUST send an empty ClientKeyExchange.

that's not how i'm reading 5246 §7.4.7  -- i see it as saying if the
client has decided to send a fixed (EC)DH cert, then it MUST send an
empty ClientKey Exchange.

I see no requirement that a client MUST send a certificate if it has one
that satisfies the server's CertificateRequest (and i would be strongly
opposed to adding such a requirement -- clients should not be forced to
reveal identity to a server just because of CertificateRequest message
in the handshake).

so i think NSS is doing the Right Thing here too.

   --dkg

---

From: Clemens Hlauschek <[email-masked]>
Date: Tue, 11 Aug 2015 20:25:08 -0400

> configuration that cause it to only be used in one way or another.

NSS does not support

rsa_fixed_ecdh
ecdsa_fixed_ecdh
rsa_fixed_dh
dh_fixed_dh,

although it supports ECDH_ECDSA and ECDH_RSA (if I remember correctly)

so your point is moot. Anyway, the only client implementations we found
that were actually vulnerable to the attack (Safari/Mac OS X --
supporting (EC)DH_* key exchange and *fixed_(ec)dh client
authentication) did not make these assumption you are talking about, and
I can not see why they should.

We are currently working on  a video showcasing an actual attack (Safari
-- Facebook).

> certificate, the client MUST send an empty ClientKeyExchange.

Yes, that is correct. But for fixed (EC)DH client authentication.

> systematically ignored in practice (NSS ignores it).

I could find nowhere in the spec that a (non-ephemeral)
 (EC)DH key agreement necessary implies fixed (EC)DH client
authentication to be used. The other direction (fixed (EC)DH client
authentication requires a (EC)DH key agreement, is insinuated by the
spec, but still left ambiguous (a conclusion I came to after discussing
exactly that with the OpenSSL developers).

Regards,
Clemens

---

From: Clemens Hlauschek <[email-masked]>
Date: Tue, 11 Aug 2015 20:38:52 -0400

> reasonable amount of defence against this attack...

Thanks for the critical reading. Actually, your point is touched upon in
the paper. Instead of an ECDH certificate, an ECDSA certificate can be
used by the attacker. The case for DH/DSS is different, and your point
is valid for this latter case. I am working on a video showcasing the
attack (Safari <-> Facebook), but if you decide that you still would not
trust our claims made in the paper, it would be trivial to reproduce the
attack: our MitM proof-of-concept implementation was realized with less
than 10 patched lines of the openssl/stunnel codebase.

See also RFC 4492:
"Note that there is no structural difference between ECDH and ECDSA
keys.  A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations"

> provide the protection that the text implies.

In case of the vulnerable Safari / SecureTransport / Mac OS X clients,
it does make a difference, so having correct X509 KeyUsage settings is
the best (and only sensible for servers supporting ECDSA) recommendation
for server-side mitigation, from our perspective. The facebook.com
security teams very quickly implemented that change. While it is
certainly true that keyUsage flags are ignored by many implementations
(this is also mentioned in the paper), checking (it is ambiguous
according to the TLS specs whether it is mandatory for ECDH, but it is
mandatory for DH if the KeyUsage extension is present) seems to have
become more widespread recently.

Best,
Clemens

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 12 Aug 2015 01:50:23 +0000

Ilari Liusvaara <[email-masked]> writes:

>a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is no
>ECDSA-specific keytype in X.509.

That's always concerned me about ECC certs, all you can say about a key is
"ECC", not "signing key" or "key agreement key" (I'm sure this was seen as a
great feature when the key format was designed, "ECC is so much more flexible
than RSA, you can use it for anything!").  My code explicitly ACLs ECC keys
coming from certs to be signing-only in order to deal with this problem.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 17 Aug 2015 12:38:54 +0000

So apart from being an interesting paper, it also points out (yet again) that
TLS has waaaay too many baggage suites and mechanisms that provide nothing but
an attack vector (it's not unique in this regard, other protocols also carry
around a vast amount of baggage and unnecessary flexibility whose only
apparent use is attack vectors, because certainly no implementation seems to
be using it.  SSH springs immediately to mind, TLS has all the baggage suites
and SSH has the unnecessary flexibility).

One thing that I'd really like to know is that given the non-PFS (EC)DH suites
were obviously a dumb idea and barely supported by anything (not just in terms
of TLS code, no public CA I know of will issue the required X9.42 certs,
although as the paper points out you can get ECDH ones that can be misused),
why did OpenSSL add support for them as late as 1.0.2?  Does anyone know why
they were added?

Peter.

________________________________________
From: Clemens Hlauschek [[email-masked]]
Sent: Wednesday, 12 August 2015 11:15
To: Peter Gutmann; [email-masked]
Subject: Re: [TLS] TLS and KCI vulnerable handshakes

See also RFC 4492:

Best,
Clemens

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Aug 2015 15:18:14 +0000

> why did OpenSSL add support for them as late as 1.0.2?  Does anyone know why

I can't answer why, but I know what and when:

The cipher-suites that were added to 1.0.2 were fixed finite-field
DH ciphers, not fixed ECDH.

DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(256) Mac=AEAD
DH-DSS-AES256-SHA       SSLv3 Kx=DH/DSS   Au=DH   Enc=AES(256)  Mac=SHA1
DH-DSS-AES256-SHA256    TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(256)  Mac=SHA256
DH-DSS-CAMELLIA256-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(256) Mac=SHA1
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(256) Mac=AEAD
DH-RSA-AES256-SHA       SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA1
DH-RSA-AES256-SHA256    TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA256
DH-RSA-CAMELLIA256-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(256) Mac=SHA1
DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(128) Mac=AEAD
DH-DSS-AES128-SHA       SSLv3 Kx=DH/DSS   Au=DH   Enc=AES(128)  Mac=SHA1
DH-DSS-AES128-SHA256    TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(128)  Mac=SHA256
DH-DSS-CAMELLIA128-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(128) Mac=SHA1
DH-DSS-SEED-SHA         SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(128) Mac=AEAD
DH-RSA-AES128-SHA       SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA1
DH-RSA-AES128-SHA256    TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA256
DH-RSA-CAMELLIA128-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(128) Mac=SHA1
DH-RSA-SEED-SHA         SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
DH-DSS-DES-CBC3-SHA     SSLv3 Kx=DH/DSS   Au=DH   Enc=3DES(168) Mac=SHA1
DH-RSA-DES-CBC3-SHA     SSLv3 Kx=DH/RSA   Au=DH   Enc=3DES(168) Mac=SHA1
DH-DSS-DES-CBC-SHA      SSLv3 Kx=DH/DSS   Au=DH   Enc=DES(56)   Mac=SHA1
DH-RSA-DES-CBC-SHA      SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1

The relevant code was added to the 1.0.2 dev branch in Apr of 2012,
backporting said code from the "master" branch where fixed DH
support was enabled in January of 2012.

On a related note, for what it's worth ECDSA certs are constrained
by keyUsage if the extension is present.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Aug 2015 15:36:45 +0000

> by keyUsage if the extension is present.

My thoughts on these from the openssl-team list (non-public) from
May of 2015:

  * Remove.  Frankly, I think all the static DH ciphers (even non-export)
    are useless bloat.  Nobody uses them, and they lead to large client
    HELLO messages, and interop issues.

    I'd like to see them all deprecated, that'd be 42 fewer useless
    ciphersuites.

  * > Oh - except DH only. I think we need to keep static ECDH. I've been told
    > there are some servers out there that are configured to do static ECDH
    > with their ECDSA cert.

    Whatever for?  Why go to all that trouble to defeat forward secrecy?

And now there are additional reasons to drop support for these from
"master".  Making incompatible changes in 1.0.2 patch releases is
perhaps not an option (unless removal of DHr/DHd/ECDHr/ECDHe can
be reasonably positioned as a bug fix).

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 17 Aug 2015 15:53:59 +0000

>I can't answer why, but I know what and when:

I was trying to avoid finger-pointing so I didn't go through the changelog to
see whodunnit, I was more interested in the motivation.  Same for Apple, why
would you implement something that pretty much no-one else (at the time)
supported, and for good reason?

Having said that though:

that sort of stuff just compounds the WTF.  Static DH + DSA + single DES, added in 2012.
W. T. F.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Aug 2015 16:07:59 +0000

> I was more interested in the motivation.  Same for Apple,
> why would you implement something that pretty much no-one else (at the
> time) supported, and for good reason?

Perhaps because this was a year before Snowden and the mindset was unquestioning complete RFC implementation?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Aug 2015 16:09:40 +0000

> that sort of stuff just compounds the WTF.  Static DH + DSA + single DES, added in 2012.

The mechanics of how it happened are simple enough.  The ciphers
were there all along for around a decade or so, but they were all
disabled because the key exchage method was not implemented.

What happened in 2012 is that the key exchange got implemented, so
presto-magic a new single-DES fixed-DH cipher.

I'd like to see more attention paid to changes that explicitly or
implicitly introduce new ciphers that fall into the WTF category.

I hope we'll be able to exercise more discretion going forward.

That said, has https://tools.ietf.org/html/rfc5469 been sufficiently
well publicized?  I've seen a lot of discussion around the deprecation
of RC4, but DES and IDEA seem to have lingered on...

--
	Viktor.

---

From: Clemens Hlauschek <[email-masked]>
Date: Tue, 11 Aug 2015 19:15:39 -0400

See also RFC 4492:

Best,
Clemens

---

From: Watson Ladd <[email-masked]>
Date: Sat, 22 Aug 2015 18:40:01 -0700

On Aug 17, 2015 9:08 AM, "Salz, Rich" <[email-masked]> wrote:
> Perhaps because this was a year before Snowden and the mindset was
unquestioning complete RFC implementation?

<rant>

We've known since at least 2001 that the TLS RFC contains misfeatures. Core
OpenSSL developers wrote documents detailing how TLS connections can be
attacked through the use of these features, documents still sitting on the
OpenSSL website, dated 2004.  These documents were not brought up on the
TLS mailing list, or at TLS meetings. It's not until 2011 that we started
to see fixes for these problems. Why wasn't the attitude always one of
maintaining security for users?

If Snowden told you the Internet was a scary place, you weren't paying
attention.

</rant>