> Thanks for the answer. I should have read more carefully the rfc.
>
I can even imagine some NAT like device that uses the SNI extension to
redirect the packets to an appropriate machine.
> Now the concern I have is related with the real world interoperability
> state with existing servers that might simply close the connection if
> they don't understand or properly handle client TLS extensions. This
> is a good reason to allow the user to enable or disable at will client
> TLS extensions.
>
Not understanding or not being able to handle properly are two different
things.
What a user should be able to select or deselect needs to be balanced
with the
needs of a protocol, the need of circumvention devices in the
possibility of
errors in implementations, etc.
I don't see a problem allowing to disable SNI by some option.

I have not heard (but I am not listening very hardly) about servers that
badly implement extensions. There are not that many ssl server
implementions out in the wild, and the SNI patch based on openssl
for the most deployed open source implementation was done in our
office. :-)

From 3546:
   The extensions are designed to be
   backwards compatible - meaning that TLS 1.0 clients that support the
   extensions can talk to TLS 1.0 servers that do not support the
   extensions, and vice versa.

read also the second half of section 2.1 of rfc3546
> Any chart or info available somewhere ?
>
> Does OpenSSL retry a connection with TLS extensions disabled if a
> connection attempt with extensions enabled is remotely closed before
> handshake is completed ?
>
No. If the OpenSSL user, i.e. the application wants a feature,
how can OpenSSL decide differently? Well, you want
me to establish a secured connexion.
But since no cipher is available the connexion will be in clear text?
 

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