Re: [TLS] Proposal for hybrid solution using most of the ideas
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Proposal for hybrid solution using most of the ideas
Hello Nasko,
Let me see if I read this correctly:
- For TLS with Extensions, use the RI extension? Is that right? Or
another signaling extension?
- For SSLv3/TLS without Extensions use the special cipher. Only in this
case, or also when the Extension is used, just in case a non-Extension
server tolerates Extension (it IS known to happen occasionally), but do
understand the cipher?
- If the server understand RI, it uses that
- If it does not understand the RI, but the cipher, send the special
certificate
Correct so far?
If so, provided that this is always done for all the Client's Hellos, also
the first on the connection (I got an impression from your email that this
was not required, which could cause problems for first handshakes) I think
it should work (though some will say it is too complex, but with this kind
of legacy issues you can't fix a problem like this in a simple way).
The reason the RI/fallback must be used on the first negotiation is, aside
from the MITM attack, that I as a client need to be able to tell up front
what I am dealing with, whether to include information in the Security
information, adjust security levels, display a warning dialog, or refuse
to connect to an unpatched server. I can't wait for a possible
renegotiation.
Mike was concerned about session resume, but I do not think that is a real
issue, since we already know the parameters of the server by this time:
- If the server is using RI, the check will be part of the Hellos
- If the server is using the fallback, we already know that it does (it
is part of the TLS Session information) and modify the Finished
calculations accordingly.
- If it is using neither, then we also know that, and does not enable
the modified Finished calculation mode.
The S->C signaling is only needed during a full negotiation, while the
C->S signaling is needed each Hello since the server might not want to
resume a session.
Mike do have a point about the cipher suites that does not use
certificates. I am not too concerned about the Anonymous ciphers (they are
too vulnerable anyway), but there are IIRC several suites relying on
different key exchange methods than PKI (though not supported by Opera).
How are those going to be secured?
It might be an idea to consider writing this up a bit more formally.
On Thu, 19 Nov 2009 00:43:05 +0100, Nasko Oskov <noskov at microsoft.com>
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 col
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.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve at opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
