I think you still didn't understood the problem. There are two versions in SSL one is record layer hello version and the client hello version. Any application that support TLS versions 1.0, 1.1, 1.3 or SSLv3 (client hello version) may contain SSL 3.0 as the record layer version number and the once the negotiation is done the record layer version is updated. The problem is not with SSLv3 alone the problem is with all the TLS versions 1.0, 1.1, 1.3 or SSLv3 who has the record layer version as SSLv3 for client hello packet.
The problem is the application using gnutls instead of openssl has record layer hello version set to SSL 3.0 for client hello handshake and the client hello version to TLSv2 (max TLS version supported by client). What i suggest is fetching of SNI is still valid even if the record layer version is 3.0 and the actual client hello version is any of the TLS versions including SSLv3. On Thu, Apr 10, 2014 at 2:34 PM, Willy Tarreau <[email protected]> wrote: > [image: Boxbe] <https://www.boxbe.com/overview> Willy Tarreau ([email protected]) > is not on your Guest > List<https://www.boxbe.com/approved-list?tc_serial=16879868868&tc_rand=1178275786&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FRec&key=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D>| > Approve > sender<https://www.boxbe.com/anno?tc_serial=16879868868&tc_rand=1178275786&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FRec&key=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D>| > Approve > domain<https://www.boxbe.com/anno?tc_serial=16879868868&tc_rand=1178275786&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&dom&token=%2Fwy11T7R1QVKnkycPjMukAJgXwKDuCjUkkpoPo3fnUbD27SXBkGi8peGgEmh%2FRec&key=pl7vWF6XC3JfowFZA%2F0CL7u6ZiLZzX%2BJ6UJhky1jiZM%3D> > > Hi, > > On Thu, Apr 10, 2014 at 10:33:38AM +0530, Pravin Tatti wrote: > > Hi, > > > > The function smp_fetch_ssl_hello_sni() only supports record layer version > > and client hello version greater than or equal to 3.1. But as in the > > RFC5246 in appendix E says that "TLS versions 1.0, 1.1, and 1.2, and SSL > > 3.0 are very similar" and also if we check the last 2 paras as mentioned > > below > > > > " Earlier versions of the TLS specification were not fully clear on what > > the record layer version number (TLSPlaintext.version) should contain > when > > sending ClientHello (i.e., before it is known which version of the > protocol > > will be employed). Thus, TLS servers compliant with this specification > MUST > > accept any value {03,XX} as the record layer version number for > > ClientHello. > > > > TLS clients that wish to negotiate with older servers MAY send any value > > {03,XX} as the record layer version number. Typical values would be > > {03,00}, the lowest version number supported by the client, and the value > > of ClientHello.client_version. No single value will guarantee > > interoperability with all old servers, but this is a complex topic beyond > > the scope of this document. " > > > > This indicates that the tls record version might be SSL 3.0 and the > client > > hello might be TLS version 1.0, 1.1 or 1.2. > > > > Do we need to consider this case while parsing in > smp_fetch_ssl_hello_sni() > > or is there any other specific reason for it. > > > > I noticed such kind of issue when application is using gnutls instead of > > openssl. > > ie., the record layer version is SSL 3.0 and client hello is 3.3. > > Well, there is no particular reason for being limited to a certain set of > versions, however I think we did it this way because SNI started to be used > long after any client totally stopped supporting SSLv3, so it did not > appear > that there was any intersection between SSLv3 and SNI. But if there is, > sure, > maybe propose a patch! > > Thanks, > Willy > > >
