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
Received on 2010-08-09