Re: virtual hosting in modern browsers

From: Peter Williams <home_pw@msn.com> · Date: Fri, 28 Jan 2011 18:25:33 -0800

What we need to now do is experiment.

I can set sni, now, as user. I can probably force the http host header to be not sni. What happens!?

On Jan 26, 2011, at 6:16 AM, Henry Story <henry.story@bblfish.net> wrote:

> Thanks Dirk and Peter.
> 
> I often get asked this question about how one can do virtual hosting with 
> TLS, and not being able to do that is often seen as a barrier. The last link
> sent by Dirk-Willem does indeed it make it very easy to understand
> 
>> http://journal.paul.querna.org/articles/2005/04/24/tls-server-name-indication/
> 
> That article was written in 2005 when only Opera had implemented it. My guess
> is that by now all browsers do.
> 
> I have updated the FAQ 
>  http://esw.w3.org/Foaf%2Bssl/FAQ#SSL_makes_cheap_hosting_impossible
> 
> Please feel free to add details I have missed
> 
> Henry
> 
> On 26 Jan 2011, at 14:16, Dirk-Willem van Gulik wrote:
> 
>> 
>> On 26 Jan 2011, at 02:54, Peter Williams wrote:
>> 
>>> can any one tell me what are theconditions under which are modern browser populates the SNI extension in the clientHello of TLS?
>>> 
>>> Basically, the idea is that the browser tells the server - in the first TCP datagram - the (virtual) host domain-name it thinks it will shortly be talking to.
>>> 
>>> User types address URL https://virtualhost.com/peter#me;
>> 
>> So on the wire we have
>> 
>>    https - and no port - so we'll do tcp/ip over port 443
>> 
>>    virtualhost.com --> DNS lookup (CNAMEs) resulting in a set final A records.
>> 
>>    /peter is the local URI on the wire
>> 
>>    #me will NOT be shown/sent to the server; it is 'eaten' by the browser.
>> 
>> So what happens is a TCP connection opened to the first (working) IP address (A). The client then does a more elaborate SSL hello - (see http://www.ietf.org/rfc/rfc4366.txt), followed by a whole extended confirming server hello dance, which includes the above 'virtualhost.com'. Or the server aborts at this stage with a unrecognized_name which is generally fatal (so not some HTTP level not-found, misconfigured, etc) when it does not know virtualhost.com (and has a cert, wildcard or not, for it).
>> 
>> This gets you the SSL connection. Then normal http commences - and you get a GET (or put, post, etc) for /peter (so no #me) and a Host: header with virtualhost.com (some servers are a bit weak here - and a naughty client which quickly changes guises may be able to cheat here). And then things are taken from thereon. 
>> 
>> Obviously wildcard certs ride roughshod on this.
>> 
>>> browser uses DNS to determine IP address of virtualhost.com; something tells browser to populate SNI, or not populate SNI. What?
>>> 
>>> Perhaps i nTLS 1.1+ its populated always, providing there exists a DNS hit?
>>> 
>>> Can the "DNS hit" be a local host file rather than a real DNS lookup?
>> 
>> 
>> No - the DNS hit does not come into this at all. And there is no need to do anything server side either; it is purely in the HELO's exchanged on TLS setup - and then purely in the ascii string in the Host: header of HTTP.
>> 
>> If above is confusing - Paul has a nice description on 
>> 
>>    http://journal.paul.querna.org/articles/2005/04/24/tls-server-name-indication/
>> 
>> Thanks,
>> 
>> Dw.
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols@lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> Social Web Architect
> http://bblfish.net/
> 
> 
> 