Re: [TLS] Deprecating SSLv3

[Yuhong Bao <[e-mail]>]

> > Just a few days ago I was working on a customer message about interop
> > problems with a Business-2-Business scenario, and the Server that is used
> > seems to be an extensions-intolerant TLSv1.0 server.  The server is OK
> > with ClientHello.client_version = { 3, 3 }, but when ClientHello includes
> > any TLS extensions, it will abort with a fatal unexpected_message(10) alert.
> > 
> >  (the Website is http://www.elemica.com,
> >    the service(s) are on https://preprod.connect.elemica.com:5443
> >                      and https://connect.elemica.com:5443
> >    authentication is by TLS client certificate, but you'll see the
> >    TLS extensions intolerance by the fatal alert response to ClientHello.
> > 
> > > I think we can safely banish a protocol that only 0.5% of servers require
> > > for interoperability.
> > 
> > Maybe you can, but I can not.  The support load would still be prohibitive.
> 
> In the case you're talking about you can connect using TLS1.0 without 
> extensions, and while that is suboptimal in general it is allowed under 
> current draft (and supported with TLS_FALLBACK_SCSV).
> 
> Anyway, you should file a complaint to the manufacturer that it haven't 
> addressed the POODLE vulnerability in their product (or that it doesn't 
> implement advertised protocols properly).
> If you don't have a contract under which you can do that or can't change the 
> TLS library yourself, you have much bigger problems anyway...
I'd explicitly say that the problem is TLS extensions intolerance which would cause browsers to fall back to SSLv3.As a side note, while TLS extensions intolerance is a bit painful too, I feel that it is worth the effort to eliminate. Besides SNI and OCSP stapling, there is also RFC 7366 which is an Encrypt after MAC extension for TLS.
Yuhong Bao