Hi Guen,

2008/2/12, Guenter Knauf wrote:

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

Nearly all TLS extensions introduce a lower security/privacy SSL
framework than when not used at all. So TLS extensions should be
explicitly requested and not turned on by default. The security
considerations are described in RFC 4366 section 6.

> - should SNI be disabled at configure time

It should be enabled or disabled at configuration and build time
depending only on other capabilities. If it is a non-SSL build it
makes no sense to enable it. If the SSL library is not
configured/built to support TLS extensions it should be disabled. And
then there's also the case when a dynamic SSL library with TLS
extensions has been used to build lib/curl but at runtime the dynamic
SSL library has been built without TLS extensions.

> - should SNI feature be switchable at runtime

Definitively yes.

> - should it be enabled or disabled by default

All TLS extensions disabled by default.

> - if we disable SNI at runtime, should it be sparate for SNI only, or
> just for all TLS extensions?

Each TLS extension should have its own switch to turn it on. And an
additional switch could turn on all of them.

--tls-ext <string>

-- 
-=[Yang]=-