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
