Re: [TLS] TLSrenego - current summary of semantics and possibilities

[Michael D'Errico <[e-mail]>]

> What you're asking for is to discontinue talking to the entire installed
> base of SSL&TLS implementations.  i.e. clients should only talk to
> updated servers (which means they must be updated clients).

I'm not asking for that.  People seem confused about who sees the
renegotiation.  The client *does not* see a renegotiation in the MITM
attack.  It simply connects once giving its credentials, and the attack
is complete.

> What about a transistion period?
> (A world-wide "SSL/TLS flag day" is probably unlikely) 

Yes, very unlikely.

>> Simply finishing the *initial* handshake completes the attack!  (The
>> server saw it as a renegotiation, not the client.)
> 
> But you do realize that it is an attack on the server?

I just learned of the "confused deputy" attack and it appears that this
is an example of that, with the server acting as the confused deputy.

The server is attacked, but the client is also a victim because they
need to spend the time and energy convincing their credit card company
they didn't order something.

> And do you further realize, that it is a problem of the server
> that request or at least allow renegotiation -- those that reject
> renegotiation are _not_ vulnerable.

Agreed.

> Considering how careless some security folks invent means to coerce
> someones software to talk to someone else (e.g. certificate URL TLS extension,
> AIA in X.509 certs), I don't feel it is fair to hold the TLS clients
> responsible for the problem.

They are not responsible, but they need to be given a defense mechanism.
If they choose not to use the mechanism (i.e. by not sending the extension
on initial connect), they are not going to be protected by that mechanism.

> What you're asking for means that the Browsers should discontinue
> their re-connect fallback with a SSLv3 ClientHello, because the
> MITM could be able to coerce the browsers to do it.

He can indeed.  This is a really bad flaw.  I'm saying that it's risky to
fall back, but I'm sure that won't stop everyone from doing it.

>> To protect against this, the only thing that a client can do is include
>> the empty renegotiation info extension.  If the server returns it and
>> the handshake completes, there is no MITM.  In fact if you were to then
>> renegotiate, you wouldn't need the extension (!) because you are already
>> certain that the handshake was with the server and not the MITM.
> 
> HUH?  The Renegotiation_Info is required for cryptographic binding
> during the renegotiation handshake.  Without it, there is zero protection.

 From just the client's perspective, all it needs is for its initial
handshake to have sent and received an empty renegotiation info extension.
Once that handshake completes, it knows that there is no MITM.  From then
on, it doesn't need secure renegotiation; it can only be talking to the
same server.

 From the server's perspective, though, it does need the cryptographic
binding since it can't tell if a renegotiation is real or proxied.

>> There are a few possible results of sending the extension:
>>
>>      a) the server responds with the extension
>>      b) the server responds without including the extension
>>      c) the server "crashes" because of the extension
> 
> You have forgotten
>        d) the server sends a fatal handshake alert
>        e) the server closes the network connection

(e) is the same as (c), and (d) can be forged too.

>>> Overloading ("abusing") the semantics of other regular elements
>>> of an SSL/TLS handshake that have a lesser likelihood to upset
>>> legacy servers.
>>>
>>>    - Assign one (or two) specific ciphersuite IDs that the client
>>>      can include in the ciphersuites list which signal the clients
>>>      notion of the connection state (initial vs. renegotiation)
>>>      to the server.
>>>
>>>    - Assign one (or two) compression algorithm IDs that the client
>>>      can include in the supported compression algorithms list which
>>>      signal the clients notion of the connection state (initial vs.
>>>      renegotiation) to the server.
>> I would not like to see this kind of solution.  If code has to change,
>> Do The Right Thing.
> 
> The IETF should provide solutions to the _real_ world.
> Limiting our solutions to an ideal world of academic purity will
> hurt the entire community of end users around the world.

If it's not possible to Do The Right Thing, then I am onboard with
doing whatever it takes.  Hijacking a ciphersuite number wouldn't
be the end of the world.

Mike