cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PATCH] support for server name indication (RFC 4366)

From: Guenter Knauf <eflash_at_gmx.net>
Date: Tue, 12 Feb 2008 15:14:17 +0100

Hi,
> It is surprisingly small I must say.
I also suprisingly mentioned that to Kaspar...

> 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)
yup - was just a quick hack so I could see that my build supports SNI.
There should be some logic perhaps go into setup.h to determine if SNI is available with the used SSL toolkit.

> Out of curiousity, do you happen to know why this isn't enabled by default
> in openssl?
hard to say; it came up around mid 2006 in OpenSSL 0.9.9-dev where its ensabled by default.
Steve Henson, one of the core devs, did then backport it for OpenSSL 0.9.8f, and there he introduced it as optional; probably that has only something to do with some policy about new features in a stable branch? I didnt ask him yet....

>> 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.
I dont think that it can be a problem to have it compiled into the code;

>> - 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.
exactly our thoughts, there might be older SSL toolkits getting crazy when receiving a server hello...

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

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

Guen.
Received on 2008-02-12