Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

[Marsh Ray <[e-mail]>]

Michael D'Errico wrote:
>> 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.

Even if Michael were, is there a choice? Is it even that unprecedented?

Many endpoints no longer talk SSLv2. Presumably there was at least some
software that once spoke earlier variants.

Why were they abandoned, was it for saving bytes? Probably not. Did it
make or save anybody much money? Probably not, SNI would long have been
adopted if money were a sufficient motivator.

No, earlier versions were abandoned because they were found to be
less-than-ideal in the security department.

This weakness is one of the last nails in the coffin for SSLv3, doomed
from the start due to its lack of proper extensibility. It seems
appropriate since it was 3.0 that quietly introduced this renegotiation bug.

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

In some sense, SSLv3 was given the "legacy" label in January 1999, the
date on RFC 2246 defining TLS 1.0. Who can complain after having been
given 11 years' notice?

For fixing TLS, there will certainly be a transition period the length
of which will be determined by vendors, admins, and users as always.

>>> 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?
> []
> 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.

It's an attack on a protocol which both parties are counting on for
secure communications. There's nothing inherent in it that favors the
security of one side over the other.

>> 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.

What if variants of the attack allow MITM to renegotiate with the client
and inject data towards it?

Doesn't the server application have just as much an interest in the
integrity of the message as the client app does? Would you want to
exchange critical secret documents with someone who was known to fall
for simple email scams?

> 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.

I believe the key is correct information at the appropriate times.

I personally would expect my browser to warn me if it was falling back
to a less secure communication path. Users should expect to be given
both complete raw information and synthesized recommendations such that
they can 1) make an informed decision, 2) not be talked-down to, 3)
learn something if they're in that mood.

>>>>    - 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.

A simple 'renegotiating' flag has been proposed several times, but I
don't think it adequately addresses the problem (binding the sessions
over a single connection).

Now MITM just has to put the client in some state such that the client
believes he's renegotiating (without losing the connection crypto state
or having some private key). It's certainly allowed for a conformant TLS
client to be willing to renegotiate with MITM. I believe there are
actual applications that may do that (intentionally or not).

Perhaps it could be useful for SSLv3 though.

Really though, we need to smuggle as much content as we can from the
previous Finished messages. For example, probably no one would mind if
we used some of those bottom bits of the GMT time in the ClientHello
"random". We could probably put a few bits in the random area, too.
After all, if they were willing to throw away 30+ bits of entropy (13%
of it!) just to send the current time, surely we could use some space
for verify data. Just 10 bits could make the attack 1000x harder.

The same trick could be used to smuggle Finished verify data in the
Server Hello as well.

Thinking about it, the Hello messages are passed under the same crypto
params as the verify data was originally, so it's not disclosing
anything new. They also cannot be manipulated to assume certain values
without breaking the hash in way that would be catastrophic even without
renegotiation. They are statistically psuedorandom.

One thing is that the Finished verify data is longer than the
Hello.Random. Go figure. So we might take a subset of its bits, or they
could be distributed as a statistical "watermark" on top of actual
random data. For a worst-case estimate we could assume verify data are
altogether free of entry. Even then we could make the MITM's job about a
billion times harder at the cost of only another 13% of entropy from the
random pool.

Seems like something along these lines might work. This may be
cryptographically dumb in some obvious way. I haven't thought about it
much until just now and obviously it would need review.

>> 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.

There are many, many deployments of TLS that will upgrade both endpoints
to the most secure version the millisecond it becomes available from
their vendors. They are very much in the real world.

- Marsh