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

A nice contribution from Dirk-Willem van Gulik, on the foaf-protocols list. Hopefully Dirk will
be able to join the WebID XG.

Henry

On 29 Jan 2011, at 13:49, Dirk-Willem van Gulik wrote:

> Lets try to reset this a bit. I think we have a couple of related though somewhat orthogonal issues:
> 
> 1)	We want to do mass virtual hosting on SSL - but not the cost of many IP addresses and config hassle.
> 2)	Is the use of SNI fine for foaf-protocols from a technical/security perspective
> 3)	Is the cost of SNI for the server managers low enough ?
> 4)	Is it supported by enough browsers.
> 5)	What if not ?
> 
> To go through these:
> 
> 1)	We want to do mass virtual hosting on SSL - but not the cost of many IP addresses and config hassle.
> 
> In HTTPs - If you want the server to authenticate and have a PKI style trust established you need to have a server side certificate which matches the hostname or IP (but strangely not the port). Thus nomal SSL thus requires a unique TCP endpoint per server (cert). And as we do not like funny port numbers (e.g. anything but default port 443) we would need an IP address per host-part in the FQDN.
> 
> Now IP addresses are not 'free' or in endless demand as they carry quite a bit of organizational/governance/communication overhead and coordination. 
> 
> There are various fiddles possible - and one of those is SNI - which was designed with just this issue in mind.
> 
> 2)	Is the use of SNI fine ?
> 
> So in normal SSL an eavesdropper cannot see more than just the source & destination IP/port pairs. In SNI a little more is indirectly exposed - namely the FQDN. Does that matter for us ?
> 
> I think not - for the following reasons:
> 
> -	In normal SSL there is a 1:1 mapping between FQDN and IP address; observation of the latter basically means the first is within practical reach. SNI does not make this (much) worse.
> 
> -	Given that the information in the foaf file is essentially public and the next steps of Alice as well - I do not think there is any real leakage.
> 
> However there are two things that worry me:
> 
> -	Someone just in front of the server, bob, gathering bulk data on a sever which host so many shallow domains that you effectively can distinguish users. Especially when we go into a world where lots of people include bits of other people in little panels (e.g. facebook today).
> 
> -	Any cases of chaining.
> 
> So I think it would be useful to think those through.
> 
> 3)	Is the cost of SNI for the server managers low enough ?
> 
> From the config snippets posted on this list - we know that the cost for at least one web server (and the largest one in the market to boot) is basically the same as for a normal name based plain text virtual host - with just the mngt of a cert file 'extra'.
> 
> That is pretty much as low as one can theoretically go. So I think we're good here.
> 
> 4)	Is it supported by enough browsers.
> 
> Of the normal desktop browsers - all the main ones (IE7, Firefox2+, Opera8+,Chrome6+,Safari2+ are fine - covering probably at least 90% or more of the market (any one care to do some decent numbers?) On the mobile and speciality market things are not so good - though opera mobile, safari mobile and windows 7 mobile are all fine - and that is again the majority of the market. The worst ones missing are IE/Safari on XP and some/all? Android.
> 
> 5)	What if not ?
> 
> Depending on the FQDN structure there are various fallback options using a wildcard - and in some cases (e.g. alice.domain.com, bob.domain.com, etc) those can be very clean and seamless with a bit of thought and a wildcard certificate. In other cases they are not - and will cause a warning.  But given the user base these serve - that may not be some issue.
> 
> Does that help ?
> 
> 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 Saturday, 29 January 2011 23:03:07 UTC