Re: [TLS] One approach to rollback protection

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Yngve N. Pettersen wrote:
> > 
> > - How easy would it be for a server or client implementor to get it wrong?
> 
> Looking at the varying interpretations of what value the client_version
> in RSA premaster secret should be checked against and the age of the
> implementations that got this wrong -- EASY, I assume.
> 
> But if you take that as a measure, we would have to shut down the IETF.
> 
> If there is any hope at all (and I defy to give up that hope), let's
> try to be clearer than the existing spec on _all_ details of the
> version negotiation ("nanny spec"), and see how it works out.
> 
> Compared to rfc5746 renego, this proposal is "simple" on my scorecard.


The real issue is not whether an implementor gets something wrong
(which can happen to every human being), but whether the implementor
ships an incorrect implementation that would have been caught by
sensible interop testing prior to shipment.

Doing a superficial, black-box interop testing with all default
settings is not much proof of anything and regularly insufficient.
Some amount of testing methodology is advisable.

(Maybe the IESG should require description of suitable interop test
 scenarios in protocol specifications--or an option to be removed
 from a spec?)
 
For complex entire protocols, testing all possible combinations
of options results in a combinatorial explosion (cartesian product
of all options) and is frequently quite unpractical.

But for testing individual protocol options (and negotiation thereof)
for interop, a cartesian product may be quite practical _and_
necessary to get any meaningful results.

I believe that the TLS version negotiation is a protocol option where
a more thorough interop testing is fairly practical and extremely valuable.


Basic complexity:

  1. max client TLS version >  max server TLS version
  2. max client TLS version == max server TLS version
  3. max client TLS version <  max server TLS version

Additional complexity: perform a renegotiation after (1), (2), (3).

To interop test the original TLS version negotiation
(i.e. Record.version, ClientHello.client_version
 and RSA PremasterSecret.client_version) the prerequisite
for full coverage is that both implementations have at
least two protocol versions in common.  common support for SSLv3&TLSv1.0
is already sufficient for a meaningful interop test!

One of (1), (2), (3) is going to be the result of
the default install.  The other two must be created
by tweaking the configuration of TLS client or TLS server
or both (enabling or disabling protocol versions)

Example:  interop testing openssl-1.0.0d client
          and and Win7+IIS 7.5 server

default config:  openssl-1.0.0d  implements SSLv3/TLSv1.0, offers TLSv1.0
default config:  Win7 implements SSLv3->TLSv1.2, TLSv1.2 disabled

Configure IIS 7.5 to request a client certificate (in order
to have renegotiation covered by the interop test)

initial test after default install represents scenario (3) above.

   openssl s_client -connect win7iis:443 -no_ssl2
     [--> ClientHello.client_version=TLSv1.0...]
     [<-- ServerHello.server_version=TLSv1.0...]
     [... initial handshake succeeds...]
     GET / HTTP/1.0<Enter><Enter>
     [<-- HelloRequest]
     [--> ClientHello.client_version=TLSv1.0...]
     [<-- ServerHello.server_version=TLSv1.0...]
     [...renegotiation handshake succeeds...]
     [...server reply for / ...]

In order to test scenario (1) and (2), disable protocol
versions TLSv1.0, TLSv1.1 and TLSv1.2 for Server of the SCHANNEL
Security Provider on the Win7/IIS machine and reboot.

testing scenario (1) from above:

   openssl s_client -connect win7iis:443 -no_ssl2
     [--> ClientHello.client_version=TLSv1.0...]
     [<-- ServerHello.server_version=SSLv3...]
     [... initial handshake succeeds...]
     GET / HTTP/1.0<Enter><Enter>
     [<-- HelloRequest]
     [--> ClientHello.client_version=SSLv3...]
     [<-- ServerHello.server_version=SSLv3...]
     [--> ClientKeyExchange+ChangeCipherSpec+Finished]
   ***** Win7/IIS-7.5 unexpectedly closes network connection.

testing scenario (2) from above:

   openssl s_client -connect win7iis:443 -no_ssl2 -ssl3
     [--> ClientHello.client_version=SSLv3...]
     [<-- ServerHello.server_version=SSLv3...]
     [... initial handshake succeeds...]
     GET / HTTP/1.0<Enter><Enter>
     [<-- HelloRequest]
     [--> ClientHello.client_version=SSLv3...]
     [<-- ServerHello.server_version=SSLv3...]
     [...renegotiation handshake succeeds...]
     [...server reply for / ...]


The unexpected termination of the network connection for interop
scenario (1) indicates a TLS version negotiation problem.

If you retry scenario (1) with other TLS/Web Servers, there is
no such interop problem. Even Windows2003/IIS 6.0 works just fine
in the same situation.

The interop problem with Win7/IIS-7.5 appears like an incorrect check
on the RSA premaster secret client_version on the renegotiation handshake.
Win7 SChannel appears to check against ClientHello.client_version
of the initial TLS handshake, while it ought to check (if at all)
against the ClientHello.client_version of the current TLS handshake.


This interop problem shows in exactly the same fashion when I use
an openssl-0.9.7d (17-Mar-2004) client, such as included in SLES-9sp3.
(btw. have I messed around too much with my Win7 machine, or does IIS-7.5
 really _not_ have insecure renegotiation disabled by default?).


An alternative TLS version negotiation scheme through SCSV 
for TLSv1.0 and above) results in a few more relevant test scenarios,
as does additional support for TLSv1.1 and TLSv1.2.  But I believe
the interop testing effort is still fairly manageable.


Would it be too much to ask implementors for interop-testing some
3 to 8 scenarios before shipping an implementation of the alternative
TLS version negotiation scheme, to ensure that everyone gets this
right before shipping this time?


-Martin