https:\Grump.

[swestrup]

I spent the day looking into the whole virtual-name-hosting of https. What everyone has been saying is indeed true. It can't be done. There simply isn't a way permitted by the protocol to define a multiplex https port.

The reason for this is that the first thing that happens during the protocol is that the client asks 'Who are you?', and the server must respond with a certificate that contains its domain address. Since a multiplex port has no way of determining which domain its being asked to respond as, there's nothing it can reply that is safe.

So, it looks like my server is only going to get ONE https domain for now. The current version of http+tls, (which replaces https) solves that problem neatly, but no one has bothered to implement it yet.

Comments

[sps.livejournal.com]

No port override?

[pphaneuf.livejournal.com]

Yes, you could have one certificate per port, but that's annoying and not quite completely "virtual"...

The predecessor to HTTPS, SHTTP, had this working right!

Isn't TLS the same thing as SSL almost? I wonder how the new protocol is different to allow this (got an RFC for me?)... :-)

[sps.livejournal.com]

Please don't imagine you hear me defending any part of current web technology (other than IPv6, which I'm willing to work with).

[swestrup]

pphaneuf is right, I was looking for a fully virtualizable solution. We can use port overrides, of course, they're just a pain.

The new HTTP/TLS protocol is defined in RFC2817 and uses the new HTTP/1.1 UPGRADE facility for either end of the connection to request (or demand) switching the channel to encrypted mode, after the link has already been established, and all name-based dispatch has been resolved.