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 + name based virtual hosting
Date Fri, 17 Dec 2004 18:21:09 GMT
At 11:23 AM 12/17/2004, Enrico Weigelt wrote:

>hmm, is it somehow possible to work with multiple cert on the 
>same socket ? does the SSL handshake leave any chance that probably
>more then one cert can be tried, until someone matches ? 

No.  That isn't in the spec, and would be horribly inefficient.

>where're the differences between SSL and TLS handshake ?

Explicit SSL (https: e.g. port 443) demands the client and server 
handshake an ssl tunnel, totally independent of the http protocol.
It's a bunch of ssl handshake bytes, until the connection has been
established and the http conversation can begin.

This is exactly the same handshake you would see on an ldaps:
port 636 connection, or a pop3s connection over port 995.  The
protocol underneath doesn't matter.

Implicit, or StartSSL (StartTLS) protocol means that a protocol
specific request to begin an SSL/TLS handshake.  This is how you
can have an ldap: port 389 connection turn into an encrypted
conversation.  It isn't supported by Netscape/Sun/Mozilla LDAP,
but is supported by modern OpenLDAP tools.

Just as StartTLS for LDAP isn't widely supported yet, neither
is the Connection-upgrade header.  Our httpd-2.1 server has
this support, but no 'browers' that I know of support it.

http://httpd.apache.org/docs-2.1/mod/mod_ssl.html#sslengine

There are remote printer devices which do support this feature,
so there is even talk of introducing the feature into httpd 2.0.
In any case, the browser community has an issue, because how do
you assure a user that a connection to http://foo.com/buy.html
is secure(d) using connection-upgrade?

http://www.ietf.org/rfc/rfc2817.txt

spells out methods that the server can -insist- that an upgraded
connection is used, and the client can instigate an upgraded
connection as well even if the server doesn't require it.

But under no conditions is https:// valid for an upgraded
connection.  The connection never left port 80.  The scheme
http:// describes a connection to (default) port 80 started 
as clear text, while the https:// scheme describes an explicit 
SSL connection to (default) port 443.  Upgrade is an addendum
to the http:// scheme.

If the server demanded an upgrade, the GUI issue is simple, just
show the lock icon.  The http:// is still not very reassuring,
but everyone is used to looking at the little locked icon.

But how does a user demand a secured connection when useful
but not required, and not choose one when it's useless?  Is there
some domain list stored in the user's browser to insist on which
sites will be forced to upgrade?  Do they get a clicky button 
to toggle the upgrade?  These aren't trivial questions, which 
is why this four year old mechanism has been ignored for so long.

Long and short of it, unless you use a single wildcard certificate
matching all of your domains, you can't host them on a single
listening address/port with https.

Bill


Mime
View raw message