curl-library
Re: [PATCH] support for server name indication (RFC 4366)
Date: Thu, 14 Feb 2008 18:16:15 +0100
>
> Now I'm ok with TLS extensions active as default, as long as there is
> an option to disable all TLS extensions at once and simply use TLS 1.0
> and when other extensions were introduced it would be nice to have
> options to disable each TLS extension individually.
>
We are talking about the SNI extension, not about any others.
In the openssl s_client command, there is a servername parameter that
allows
to put whatever string you want into the servername.
The reason for this is that one might try to connect directly to the IP
address
and still set the servername, i.e. to bypass the DNS.
openssl s_client is a debugging tool.
One can also say that the SNI extension does not really need any additional
input parameter at the curl level, the hostname can be derived from the
URL.
If not, then such a server is eally heavily misconfigured, no DNS,
or whatever I am not sure that curl should support such hosts
that can only be reached by one IP address and have multiple hosts
and no dns. Well... hm..
A question is whether it hurts to set the SNI extension by default. As
indicated in the RFC, it seems that there are no TLS server in the wild
that are heavily broken at that point, maybe an option --nosni would
be sufficient; --nosni would in fact also be active if ssl2 is not
disabled. I think starting disabling ssl2 by default is also a good thing
today.
-- 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.
- application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature