Re: [foaf-protocols] virtual hosting in modern browsers

What do servers do?

I want to infer - on a sni-empowered tls channel - that sni@tls => hostheader@http 

Is it true, in general (because servers refuse to deliver http requests unless sni == hostheader (while also doing what sni also implies in the ssl handshake).


On Jan 26, 2011, at 6:46 AM, László Török <ltorokjr@gmail.com> wrote:

> > 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.
> Fyi, they do.
> See also http://en.wikipedia.org/wiki/Server_Name_Indication
> 
> Regards,
> 
> Laszlo
>  
> 
> 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/
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols@lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols