Just to make my position more clear _at_this_ moment_...

I'm _not_ against TLS extensions support/inclusion in libcurl or curl.
I'm _only_ against having TLS extensions active by default at runtime.

2008/2/13, Peter Sylvester wrote:

> Why must an application permit end users to turn on/off certain features?

Interesting question for curl, a tool which currently supports more
than 120 comnnand line options...

Give the user the ability to shoot himself in the feet ? ;-)
After all there's even an --insecure option. But certainly it is not
active by default.

> In this particular case: The security risk is what in this case?
>
> If a single server hosts several domains, then clearly it is
> necessary for the owners of each domain to ensure that this satisfies
> their security needs. Apart from this, server_name does not appear
> to introduce significant security issues.
>
> The SNI extension is an addressing hack above the TCP layer,
> with a similar purpose as the Host: header since the mapping of
> host name to IP address/port is not an injection.

The use of the 'Server Name Indication' TLS extension as the default
option would make lib/curl user loose the ability to actually know if
it is connecting to a virtual host or a 'real' one.

Since virtual hosts might pose unforeseen risks it would be nice to
let the user decide if they also want to trust the hosting company,
and its ability to safely run a 'real' host with more than one,
sometimes hundreds, virtual server homed at a single address.

And here are some questions that I really want someone would answer...

Once that a TLS with SNI connection is established, could it be
possible to know if the server is actually a virtual host or not ?
Would libcurl have a mechanism to fetch this info ? Would it be
possible at least to warn the curl tool user when it is a virtual host
and maybe even ask permission to continue ?

-- 
-=[Yang]=-