Re: [TLS] Proposal for hybrid solution using most of the ideas

[Michael D'Errico <mike-list at pobox.com>]

So you want to have two solutions, one for TLS 1.0+ and another for
SSLv3?  I'm not sure why we need two when any solution that works
for SSL will also work for TLS.

Also the Certificate message is optional, so it would cause trouble
for some cipher suites.

And even more importantly, there is only ServerHello sent when you
resume an old session!

Mike


Nasko Oskov wrote:
> Currently, many browsers attempt to negotiate TLS with extensions, but if it fails for any reason, they re-start the negotiation without extensions (either as a TLS negotiation or an SSLv2/3) negotiation. That behavior leads to a trivial downgrade attack by a MiTM - all the MiTM has to do is fail any negotiation with the renegotiation extension present and wait for the browser to try a negotiation without it. This leads to situation where the client is unaware if there is MiTM or real server that doesn't support extensions. If we want browsers to be secure we have no choice but fixing SSLv3 somehow or disabling it entirely.
>
> I've been reading all the ideas people have come up with and there are some good suggestions in all the mails exchanged. After discussing the various approaches with Paul Leach and passing some ideas around with Marsh Ray, we came up with a blended approach to solving the overall problem. I would like to propose a solution that uses some of the ideas brought up. 
> We all agree that there are two parts to the solution - signaling and changing state to allow for detection of the attack (aka cryptographically binding the two handshakes), so the general spirit is to use single way of changing state and different signaling for TLS and SSLv3.
>
> For SSLv3, we can use the cipher suite idea and define the magic cipher suite value that SSLv3 client will send out to the server. Based on this indicator, server knows whether to use regular running hash as it is today or use the modified running hash. The problem for SSLv3 is the signal from the server to the client. S->C signaling must be done in a handshake message preceding the Finish message, so both client and server can agree on the version of the running hash. The one dynamic field we know from experience is handled properly by implementations is the list of certificates. We can use the server Certificate message as the signal by including specially defined certificate in the list of certificates sent by the server. If the server sees the magic cipher suite, the special certificate is included at the end of the certs being sent. We can define the cert to be the smallest possible server (aka very little real data in it) and include an unique OID to ensure we don't c
ol
>  lide with some real usage of "empty" certificate.
>
> Here is the matrix for interop:
>
>                  Old server                              New server
> ----------------------------------------------------------------------------
> Old Client |       as is                 |  server detects old client on 
>            |                             |  ClientHello and can interop 
>            |                             |  based on config
>            |                             |  
> ----------------------------------------------------------------------------
> New Client |  detects old server         |  server detects new client on 
>            | on Certificate message and  |   initial handshake  
>            | can interop based on config |  client detects new server on 
>            |                             |   Certificate
>            |                             |  both start using the modified 
>            |                             |   running hash
> ----------------------------------------------------------------------------
>
> There are few ways the running hash can be modified and it seems inserting the previous Finished message into the running hash is something everyone agrees should work. Inserting it as the initial input to the new running hash is a clean approach and allows for easier logic. The only drawback is that the SSLv3 client will have to keep two hash states around until the Certificate message is received, but the client needs to keep the ClientHello around until the ServerHello is received back, so the complexity should not be much greater.
>
> For TLS 1.0 and above, we can use this same approach with very little modification. Since we have clear signaling in the Hello messages using extensions, both client and server can detect unpatched parties and based on config either proceed or terminate. The major difference is that TLS client doesn't have to maintain two different hash states, since server signals the client and the client can make the decision whether to hash the previous Finished message into the running hash or not. As such, the extension as proposed today does not need to transmit the actual Finished messages, as they will be cached on each end. 
>
> Overall what we achieve is:
> * modifying the running hash only for renegotiations, which allows interop for cases where renego is not needed (a big portion of the traffic)
> * clear signaling in TLS implementations
> * backwards compatible solution for SSLv3
> * both sides can interop or not with unpatched parties based on configuration
> * even if both sides are lenient in behavior, they are secure as long as both of them are patched
> * clients falling back from TLS to SSLv3 because of extensions compatibility will be safe
>
> Alternatively, we can use the existing draft for TLS and the proposed solution here for SSLv3.
>
> Nasko
>
> P.S. The extension will have to be a "MUST" for all TLS implementations, otherwise the MiTM can downgrade to TLS without extensions and we are back at having the problem. This requires, among other things, that browser fallback logic be slightly changed. There should not be a case of sending a TLS ClientHello without the extension. If the server reacts poorly, a downgrade directly to SSLv3 plus the signaling solution should be attempted.