>> The patch is a proposal for further discussion - there are a couple of
>> questions which need to be discussed, and are not yet coded in the patch,

I agree with all your answers to these questions, Daniel, except that
this one here -

>> - if we disable SNI at runtime, should it be sparate for SNI only, or just
>> for all TLS extensions?
>
> I think we should disable SNI only, and once we support other extensions we
> make them all possible to get individually enabled/disabled.

might be difficult (if not impossible) to achieve with a specific
toolkit. NSS e.g. does not have an explicit way of setting/clearing the
SNI extension - SSL_SetURL() is used to set the host name (it's already
present in the current version of lib/nss.c), and if it's set, NSS will
automatically send the SNI extension.

Peter Sylvester wrote:
> This means that ssl2 is disabled by default (which is probably a good
> thing today).

I agree. GnuTLS doesn't support it anyway, and for NSS my patch will
actually disable SSLv2 by default.

> There is another way to disable the extension: When an IP address is
> used, the servername cannot be used.

Correct. If the TLS toolkit really checks for that before it will the
server name onto the wire ;-) Both OpenSSL and GnuTLS don't do this
currently and will happily send out SNI extensions with literal IPv4
addresses... That's why I've added the Curl_inet_pton calls before
setting the server name.

Kaspar
Received on 2008-02-12