Subject: [TLS] Preventing cross-protocol attacks in TLS protocol

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 May 2012 13:56:20 +0200

Hello,
 I've submitted a proposal on how to prevent attacks similar in nature
with the Wagner and Schneier's one, at:
http://www.ietf.org/id/draft-mavrogiannopoulos-tls-server-key-exchage-00.txt

Please consider adopting this or any other protection for the protocol.

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 May 2012 14:52:34 -0500

> Please consider adopting this or any other protection for the protocol.

I think this is a good robustness improvement to the protocol and may 
bring other benefits. I actually considered including a very similar 
change in draft-ray-encrypted-handshake, but did not do so primarily due 
to scope.

However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect 
against the attack described.

Thankfully, all evidence points to this attack being impractical with 
all current clients. But let us consider a hypothetical client and 
server which in combination are vulnerable to this SKE-switcheroo attack.

The severity of the attack is such that the MitM is able to obtain the 
client-side premaster secret and is therefore able to impersonate the 
legitimate server. This must be the case or else the client would detect 
the change in the accepted cipher suite when the client validates the 
server's Finished message. But if the MitM can get away with convincing 
the client that the legitimate server selected a different cipher suite, 
he can just as easily convince the client that the server does not 
support draft-mavrogiannopoulos-tls-server-key-exchage.

Client certs introduce a signature over the same handshake messages but 
don't mitigate the attack either. The attacker can simply not request 
one from the client or ignore the one that is sent. Opt-in schemes 
usually don't work very well for strengthening authentication.

Nevertheless, if future extensions, key exchange methods, and/or TLS 
versions were to require this protocol change it could be quite useful. 
It could allow a client to authenticate the server at the point of the 
SKE message. This could enable him to transmit the client cert, NP(N), 
and other RFC 4680 messages under Encrypted Handshake secure even from 
active attacks. It could also enable the client to be secure in starting 
falsely the sending of an application data record.

Again I think this SKE change is a useful improvement, but only in 
conjunction with some other extension that benefits from the client 
resisting active attacks before the server Finished. So I don't see much 
value in negotiating it independently with its own separate extension. 
Perhaps I am missing something.

- Marsh

P.S. While we're on the subject of this attack, we need to remember that 
server support for any new key exchange method could instantly make this 
attack practical. New key exchange methods MUST either require this 
improved SKE or they MUST have a ServerXParams format that is believed 
to be rejected by all current and future clients for all key exchange 
types. E.g., leading with a fixed number of 0x00 bytes might work.

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 May 2012 15:24:18 -0500

On Thu, May 17, 2012 at 2:52 PM, Marsh Ray <[email-masked]> wrote:
> > [...]
> I think this is a good robustness improvement to the protocol and may bring
> other benefits. I actually considered including a very similar change in
> draft-ray-encrypted-handshake, but did not do so primarily due to scope.
>
> [great explanation elided]

To fix this in a way that resists downgrade attacks methinks you'll
need a certificate extension by which to indicate that the server
supports the new SKE.

Then the client can send the TLS extension in its ClientHello, the
server sends the new SKE, and if the MITM tries to play any funny
games [*] the client will know it from the server's cert.

[*] Stripping this extension, pasting an SKE intended for an old
client, working out the downgraded key exchange's output, then making
the Finished messages come out.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 17 May 2012 23:22:01 +0200

> support draft-mavrogiannopoulos-tls-server-key-exchage.

Hello,
 This is the same issue as in the TLS version and protocol negotiation.
Even if both peers support TLS 1.2 but they are willing to accept SSL
3.0, then they may end up using it if it has a vulnerability. The same
in this case. All TLS protocol versions are vulnerable unless this
extension is sent. Thus a client has to require this extension to be
present to prevent cross protocol attacks.

regards,
Nikos

---

From: Geoffrey Keating <[email-masked]>
Date: 17 May 2012 14:34:24 -0700

> present to prevent cross protocol attacks.

Isn't that actually caused by this very attack?  There is a version
field in PreMasterSecret, sent in the non-DH cases when no
ServerKeyExchange is needed, but there is no version field signed in
ServerKeyExchange.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 18 May 2012 09:25:35 +0200

> present to prevent cross protocol attacks.

There is something (a hack) that can be done to ensure detection by the
server of a conformant client, in the case of an active adversary. That
is to add a magic number in the client nonce, or to replace the
timestamp with a magic value. This would reduce the available entropy,
but ensure that a conformant server will notice the support of the new
format, even if the adversary removes the extension from the client hello.

regards,
Nikos