On Tue, 12 Feb 2008, Guenter Knauf wrote:

> Meanwhile all modern browsers support SNI, and since OpenSSL 0.9.8f is out
> we have also a released OpenSSL version which supports SNI (must be enabled
> with enable-tlsext at compile time). GnuTLS has SNI support since version
> 0.5.10 (Oct. 2002), and NSS since version 3.11.1 (May 2006).

> Therefore we thought that cURL should also support SNI

Sounds Neat Indeed! ;-P

> and Kaspar created a patch:
> http://svwe10.itex.at/mirror/curl/source/curl-sni-v1.diff

It is surprisingly small I must say.

> In order to identify a cURL build which supports the SNI extension I did add
> few lines to lib/version.c:
> http://svwe10.itex.at/mirror/curl/source/version.c.diff

This check only works for OpenSSL, right? It would need to check for the
correct versions of GnuTLS and NSS as well to be somewhat generic. (and yassl
and qssl too in order to be complete - if they support it)

> when you have compiled OpenSSL 0.9.8f or later with 'enable-tlsext' and

Out of curiousity, do you happen to know why this isn't enabled by default in
openssl?

> as you can see I have tested from Win32 platform with OpenSSL which works so
> far; others who can test with NSS and GnuTLS are welcome.

I can do some testing with GnuTLS at least.

> 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,
> f.e:
> - should SNI be disabled at configure time (my 2ct: no, it can be
> automatically detected)

I agree, but that's also why I asked about openssl. Why do they have it
disabled by default? Is there a particular risk or impact involved with having
it enabled by default? If not, I think it should be enabled if a capable lib
is detected.

> - should SNI feature be switchable at runtime (my 2ct: yes)

I think it should, just most features are with libcurl as I have no doubts
that we will sooner or later face servers in the wild that have problems with
it.

> - should it be enabled or disabled by default (my 2ct: enabled)

I vote enabled too.

> - 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.

> and finally another question which unfortunately Patrick was not able to
> answer: what about the AS400 SSL support? We dont know yet if this SSL
> toolkit supports SNI too...

Well, we should of course still work fine even if it doesn't. It certainly
wouldn't surprise me if yassl doesn't support it either!

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html