httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: SSL enabled name virtual hosts
Date Mon, 06 Mar 2006 07:46:57 GMT
Daniel Rogers wrote:
> 
> However, this seems like an artifact of the config file data data
> organization and/or an apache implementation limitation, rather than a
> limitation on the protocol itself.

I would just ignore the troll, but you have put the time into trying to
think this through, so we repeat...

Client                    Server
request handshake     -->  acknowledge handshake
           negotiate keys and credentials
connection secure    <--   complete handshake

                  now encrypted...

send headers (Host:)  -->  read headers, choose a virtual host
read response        <--  prepare response

The client and server agreed upon a certificate before Host: was seen.
No problem, right?  Only issue is for the client, it thinks that example.com
isn't example.net as recorded in the common name.  We can't vary on Host:
before we see Host:, and we won't see Host: till handshake is complete.

Stop bitching about a 10 year old spec.  It's trivial, use a modern browser
(beyond today - none exist yet) that can do Connection-Upgrade and agree
about the text of the headers before the ssl handshake is performed.  The
browser people haven't caught up, because it's a non-trivial problem to
represent that the agreed-upon connection is secure to the user, or that
a secure connection is available to be toggled, or whatever.  These aren't
https:// requests, they are http:// with extra semantics.  Modern clients
such as remote printing over http and neon/curl libraries already support
it now, IIUC.  As does httpd 2.2.


Mime
View raw message