Re: [TLS] Proposal for hybrid solution using most of the ideas

[Marsh Ray <marsh at extendedsubset.com>]

Dr Stephen Henson wrote:
> 
> What browsers and many libraries (including OpenSSL) do in the first place is to
> send an initial "version discovery" SSLv3 compatible client hello (or even
> SSLv2) with the version number set to the maximum number of SSL/TLS supported.
> The reply then indicates the version of SSL/TLS supported. Until that point you
> don't know what the server supports. So the connection can end up talking TLS
> v1.2 even though it initially sent and SSLv3 compatible client hello.

So using extensions (even when both ends support TLS 1.1) would
significantly change the client hello for many current clients? Yngve of
Opera and Nelson of Mozilla had posted some connection logic that didn't
work quite like that. But now that you mention it that is what I see
from typical non-browser clients.

Back to unified SSL/TLS solutions then.

Looks like C->S signaling could be achieved back to SSLv2 with the magic
cipher suite technique.

For S->C, setting that high bit in the version field is looking not so
bad now.

RFC 4346:
> server_version
>       This field will contain the lower of that suggested by the client
>       in the client hello and the highest supported by the server.

What worries me is that a great many inspecting firewalls are going to
see that and freak out because the server is replying with a version
higher than the client.

Perhaps those nice, friendly, and helpful networking hardware and
software vendors on this list will offer some lab time to check this out?

Another possibility is bit 15 of cipher_suite, assuming there will not
be a need for 32769 different cipher suites before extensions become usable.

- Marsh