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

Indeed :-)
> 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.
>
What to do as the default, that's the point I think.
>
>> 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.
>
Not really, if the default host is the one you connect to.
> 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.
>
Where is the difference of having different IP addresses served on the same
host? How can you detect the difference (if you are not on the same LAN)?
> 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 ?
>
The SNI does not tell anything about virtual host, SNI allows to select
an appropriate certficate.
> 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 ?
>
I don't think that there is anyhing in the SSL handshake that allows to
detect this,
you probably want to make the decision before sending even the GET/POST URL.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.