Re: [TLS] Renego Indication RI patch interaction with TLS major version interop

[Marsh Ray <[e-mail]>]

On 6/15/2010 11:46 AM, Brian Smith wrote:
> 
> NSS has an explicit check that the first byte of every version number
> is 0x03. I imagine other implementations have a similar check.
> 
> Version handling in NSS will be revamped sometime before TLS 1.1 and
>  TLS 1.2 support are added to it, and  the patches for that work 
> already remove the check for 0x03.

It's no excuse, but NSS is mainly used on the client side so it doesn't
cause an interop problem.

> His test would probably be much more successful if he used 0x03FF as
>  the version number.

Perhaps, but the point of the test is to find out what fails.

> I don't think it is a big deal; the main consequence is that all TLS 
> version numbers should continue to start with 0x03.

That's not something compliant servers are allowed to decide. The power
to set protocol version numbering policy belongs to the IETF and IANA
for good reason.

As an app-layer developer I usually assert that either endpoint has the
right to terminate the connection at any time for any or no reason. But
the exception is for proposed protocol versions and extensions. As the
specs say, they need to be simply ignored by the servers to prevent
problems with forward compatibility.


On 6/15/2010 12:06 PM, Michael D'Errico wrote:
> There is an even bigger problem.  Both www.microsoft.com and 
> www.ibm.com abort an attempt at connecting to them using TLS 1.2 or 
> even 1.1!

That's really lame.

> I have not done more extensive testing to see how much of the 
> Internet suffers from this, but if these "big guys" can't get it
> right....

A bit ironic, eh? Chances are they outsource their static content
hosting to the same providers or use the same offload accelerators as
everybody else. It'd probably be more significant if it were amazon.com
or google.com.

- Marsh