Re: virtual hosting in modern browsers

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/

Received on Wednesday, 26 January 2011 14:16:59 UTC