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 (app.haxx.se) 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.
So?
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 https://app.haxx.se, with SNI app.haxx.se
- users with certs still sending to https://app.haxx.se, but with another
SNI like for instance app-ssl.haxx.se
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: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Reply via email to