https:\Grump.
Oct. 1st, 2004 11:41 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
swestrupI 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.
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.
no subject
Date: 2004-10-02 09:56 am (UTC)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.