cURL / Mailing Lists / curl-library / Single Mail


Re: Manual setting of TLS Server Name Indication

From: Peter Sylvester <>
Date: Mon, 09 Aug 2010 15:25:39 +0200

On 08/09/2010 02:17 PM, Matthieu Speder wrote:
> Hi Peter,
> Many thanks for your answer.
> I totally agree that classical usage is to fill with FQDN.
and that is the only one defined.
> Here is the example...
> Imagine one https server with a single dns name ( and you are
> not allowed to create a second entry.
> The server has to accept data POST from users.
> Some of the users need to auth by basic login/pass and others using client
> certificates.
> The request of the client certificate must be initiated by the server during
> TLS handshake.
> So the server needs to know whether to require client cert at the very
> beginning of the transaction.
That has nothing to do with a cert. You can use different ports
for that also. The SNI not used to differentiate between
other security environments in this way.

> The idea is to fill the SNI field with a hint for the server on which way to
> handle the request (similar as when you have two virtual hosts on same http
> server). RFC mentions the possibility for the server to use SNI to "guide
> its selection of an appropriate certificate to return to the client, and/or
> other aspects of security policy" which is exactly what I'm trying to
> achieve here.
That is still tied to the name, and anyway, how does a client
know what to do when you just start from an URL? if you don't
have a DNS, you can still communicate an /etc/hosts.

> So in my example we can imagine :
> - basic auth user sending to, with SNI
> - users with certs still sending to, but with another
> SNI like for instance
how woul a client know about that?
> Using SNI is the simplest way I see to solve the issue (and it is working in
> my environment). Of course other ideas are welcome.
no, a local etc hosts at the client side is also simple.
> Last point is that offering an extra option to have advanced control over
> SNI in libcurl does not break anything anyway, provided of course default
> behavior remains the same.
This is not advanced control IMO.

List admin:
Received on 2010-08-09