Re: Please don't re-write TLS (Was: HTTP/2.0 -04 candidate)

It seems like the two dimensions of the problem of virtual hosting are 
alternate names for the same content and multiple sites with different 
content sharing the same server.

On 7/3/2013 2:33 AM, Yoav Nir wrote:
> On Jul 3, 2013, at 3:02 AM, "Ludin, Stephen" <sludin@akamai.com> wrote:
>> Here is an idea to chew on.  It has been discussed before, but if there
>> was a concept of returning multiple certs in the ServerHello which
>> indicate other common names the origin is authorized to serve I tight
>> provide a path forward to serving related content from those domains.
[...]
> This is authorization at the HTTP level. I don't think this should go in TLS just because TLS has a mechanism for showing certificates. Also if you do want it to go in TLS, there's an RFC for that: http://tools.ietf.org/html/rfc5878 . This allows for sending arbitrary authorization information.
>
> Alternatively, you could add this in HTTP as a header or as a new frame type.

If an objective is to develop a protocol for doing something like 
"name-based virtual hosting" with TLS server certificates, there are two 
dimensions to try to capture. One is the analog of aliases for a given 
site name, the other is the distinct virtual-hosted sites being offered.

For the first dimension, the subject alternate name certificate 
extension is a pretty good fit. If I want to say that 
www.chemistry.example.edu, chemistry.example.edu, 
www.alchemy.example.edu, and alchemy.example.edu are, in effect, aliases 
for the same content, then a server certificate with a list of subject 
alternate names, seems pretty much on target.

This second dimension is the sticky problem. Two approaches in use today 
are to put each site and its certificate on a distinct IP address (which 
is what name based virtual hosting was trying to avoid), another is to 
create a single certificate with a long list of subject alternate names 
or a wildcard certificate.

We've got at least one college at my university which routinely creates 
virtual hosts for every department (on port 80), and there is the 
commercial analog where completely different enterprises, with distinct 
content, are virtual hosted on the same server.

Lumping all the sites into one certificate might work for different 
college departments sharing the same information technology staff, but 
it's not going to scale well, or work, for the case of independent 
entities trying to share the same web hosting service.

I suppose you don't want to attack that problem right now (in this draft).

(I am also skeptical that the whole "same origin" model as variously 
constructed for cookies, Flash, JavaScript, etc. really provides much 
security, to them, today, but that's another question.)

Received on Wednesday, 3 July 2013 12:13:07 UTC