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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> 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.

I think you might be barking up the wrong tree.

This MITM-susceptibility is _not_ a problem specific to SSLv3.
It is a problem that affects the entire installed base of
TLS v1.0, TLS v1.1 and TLS v1.2 in _exactly_ the same fashion.

What I do NOT want to happen is that we kill the entire installed
base of TLS-servers now (including TLS v1.2 servers), which is what
will be doing if we disable our clients to talk to servers that
are not updated -- completely independent whether these servers
are actually vulnerable.


As far as upgrading/fixing is concerned: I do _not_ see an issue
the SSLv3 spec that would prevent the proposed fix to be used
even for sessions negotiated with protocol version 0x03,0x00.

There is, however, the problem with killing interoperability
to an installed base by having the client unconditionally send
a TLS extension in each initial ClientHello.

The issue of interoperability with that installed base seems to
have been sufficiently severe, that at least one Browser vendor
decided to implement a re-connect retry logic with a fallback
to extension-free SSLv3 ClientHello.


Do you really want to say "nice work -- we want you to remove
or disable the fallback and ignore your customers complaints" --
and not because that fallback is bad or because their clients
have a vulnerability -- but because we believe there is going
to remain a small amount of unfixed servers where the attack will
remain possible (but affecting only the users/customers
of that servers).
  

> 
> >> What about a transition 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?

What I meant was the transition period to an area of fixed servers.

We need to ship clients capable of secure renegotiation before we
can disable the old renegotiation on the servers.

And we need to upgrade servers to secure renegotiation before we
can suggest updated clients to discontinue talking to old servers.

And this is again, totally independent of the protocol version
implemented by those clients and servers, it affects all of
them in the exact same fashion and with the exact same severity.
(actually, the likelyhood of servers implementing or agreeing
 to renegotiation might increase with the supported TLS version,
 TLS v1.1 servers are more likely to be vulnerable to MITM than
 SSLv3 servers, because more of them implement renegotiation).


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

Servers performing a traditional SSL handshake is _not_ a security
problem.  Servers performing a traditional renegotiation is a likely
a security problem.

Clients can not currently notice what the server is doing, and the
problem exists, because a clients initial handshake can be proxied
into a servers renegotiation.


A client that is performing an initial handshake does _not_ know
whether there is a security problem, therefore I'm very reluctant
to suggest clients to warn users when performing a traditional
initial handshake.  It is going to be unfair to an ever-growing
number of servers.


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

Doing the secure renegotiation through the TLS extension in an
official renegotiation is not the problem.  Fixing means that the
code will have to be changed.  If the change is sufficiently small,
it can be added with a relative small amount of work to servers
at all protocol levels, including SSLv3.

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

The most interesting piece is actually a signaling from the server
to the client that it is performing an _initial_ handshake.  That is
an important information that the client does not currently have.
And adding such a signal might be the easiest for old servers that
need neither renegotiation and neither new TLSv1.x protocol features.

In principle, every element in the vanilla ServerHello might be a
candidate for such signaling.  But unless the client provides an
indication for understanding and accepting a protocol change
through a signal in ClientHello, we are extremely limited.

That signaling from server to client that it is doing an initial
handshake should be
 - fully backwards compatible with oldest clients
 - very very very low number of false positives


Looking at SSL/TLS handshake messages from Server to Client:

   ServerHello (always sent)
       struct {
           ProtocolVersion server_version;
           Random random;
           SessionID session_id;
           CipherSuite cipher_suite;
           CompressionMethod compression_method;
       } ServerHello;

  ServerHelloDone (not sent on Session resume, empty)
      struct { } ServerHelloDone;

  ChangeCipherSpec (not a handshake message, unprotected, empty)

  Finished (always sent)
       struct {
           opaque verify_data[12];
       } Finished;


Looking at the ServerHello contents in detail, what elements
could be re-purposed in a _completely_ backwards compatible fashion:

   ProtocolVersion   -  no
   Random            -  potentially
   SessionID         -  not really 
   CipherSuite       -  no
   CompressionMethod -  no

and looking at Random in detail:

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       gmt_unix_time
       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.

   random_bytes
       28 bytes generated by a secure random number generator.


So the smallest possible change to a server that could be used
to signal to ANY client that it believes to be doing an initial
handshake might be to set the most significant octet of the
gmt_unix_time to zero in order for a server to signal in an
extremely backward compatible fashion to the client that it
is performing an initial TLS handshake on a connection.

Unaware of how many server out in the wild do this by accident,
or how many forget to use network byte order for this value
(and would cause an accidental gmt_unix_time collision every
 256 seconds), all of the sensible old implementations out there
are going to always signal the initial handshake to conservative
clients that still do not send a TLS extension in year 2106.

The remaining 28 octets of the random still provide "some"
amount of collision resistance against accidental challenge reuse.

This change is so small, that it might even be considered for
very old code in very constrained environments, e.g. like
a 10+ year old satellite in orbit -- I would really like to
hear from folks with such constraints think about implementing
renegotiation protection with the TLS extension -- because
they might have an actual need for rekeying (rather than
requesting client certs) through renegotiation.


The purpose of this minimalistic change is that _one_day_
we will really be able to recommend to clients/browsers that they
warn when they encounter servers that do _not_ indicate when they're
doing an initial handshake (either because they're old und unchanged
or because someone is trying an MITM on one of the few remaining old
servers that has neither been fixed nor renegotiation reliably disabled).


-Martin