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 [clemens.hlausc...@rise-world.com] Sent: Wednesday, 12 August 2015 11:15 To: Peter Gutmann; tls@ietf.org Subject: Re: [TLS] TLS and KCI vulnerable handshakes On 08/11/2015 02:05 PM, Peter Gutmann wrote: > Clemens Hlauschek <clemens.hlausc...@rise-world.com> writes: > >> 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 > > 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... 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" > > 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. > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
