httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: http TLS Upgrade (was RFC for a Perchild-like-MPM)
Date Thu, 10 Feb 2005 19:52:00 GMT
At 07:24 AM 2/10/2005, "Leif W" wrote:

>Hi.  I hang out mostly on the users list, but have played with basic
>HTTPS configuration (using SSL or TLS).  As I understand, HTTPS works
>fine with any VirtualHost, so long as it is based on a unique ip:port
>combination.  That is the current alternative to name-based virtual
>hosting.  It doesn't necessarily mean you need a unique ip address, if
>you're willing or able to use non-standard ports.  Otherwise it does
>require unique ip addresses and port 443.  That is IP Based Virtual

Yes - that's an accurate summary.

>I guess it is somewhat of a misnomer.  It should be Socket
>Based Virtual Hosting, but IPBVH implies that only default ports are

Oh no, IP based vhosts don't imply any such thing.  Plenty of folks
use port 80 for public services, port 8080 for private (dav or what
ever other) services, and this is before you introduce SSL.

Socket Based?  That implies inetd hosting, where the server is given
a socket from an external socket management app (e.g. inetd.)  Beware
that's a much more confusing term for this case.

>If you must use a single ip:port combination for HTTPS, then it's
>not possible, due to the point at which the SSL/TLS layers takes over to
>ensure the ultimate security of the connection.


>I'm not an expert with SSL or TLS, but my intuitive response would be to
>modify the HTTPS protocol to establish an unsecured connection, send the
>host header (ignore anything else) to pick the right certificate, and
>then use that to secure the connection.

This is brought up ever three months by another user, and we point
each of you here;

  "Upgrading to TLS Within HTTP/1.1"  [May, 2000]

and point out that, obviously, great minds think alike, but that
there are real-world obstacles to adopting this protocol for user
browser clients.  There are, of course, no obstacles for the use
of this mechanism for automation, which is why it's ideal for
things such as securing http based print servers (which Novell and
others already do) and potentially things such as Subversion.

Therefore this handshaking mechanism is already supported in
httpd-2.1 (to become httpd-2.2 general release.)  Rather than
the SSLEngine On|Off directive, you can add to this mix a new
SSLEngine optional flavor.

The bottom line, however... let's suggest that tomorrow you offer
a patch to Firefox, and it's adopted next week.  Sometime a few
months from now, it goes out in a new release.  Then someone
backports to Mozilla, say about 12 weeks later.

This protocol is not https:// because that scheme designates 
a connection to a pipeline entirely encrypted within SSL/TLS.
But if the user types http:// - how do they say "but make it
secure!!!"?  The protocol is http://, you have to find a GUI
means of demanding security.  [Perhaps, the lock 'icon' becomes
a lock 'button' - which the user can toggle domain by domain.
Such are the issues that browser writes must struggle with.]

With 2% of the browsers supporting it, say that Microsoft gets
behind it, and spends 2 months in their security group discussing
how it can be less misleading in everyday use.  Now if they decide
that the next version gets the patch, and it's pushed out with all
new Win2003 SP3 installs, it's still 18 months from seeing any
significant uptake.

It will be, basically, 5 years for this to actually have the
impact that you ask for - to be able to fold 50 SSL hosts into
a single IP address for mass vhosting.  It is a very, very long
time away before you can turn away users of circa 2005 browsers.

>But my intuition also tells me that this would probably open up 
>some avenues for attacks which might seriously degrade the 
>effectiveness as compared to securing a connection from the 
>outset, or otherwise add many levels of complexity and possibly
>inefficiency to ensure the connection is secured after some data was

Actually, because both client and server advertise and can each
determine if encryption is desirable, it's a reasonable approach.
Because the client, from the outset, can use an OPTIONS method
to secure the connection for all future headers, there is quite
a bit of security.  

As far as degradation, handshaking and crypting SSL are far more
painful CPU wise than any header processing you can invent (short
of computing MD5 sums on the fly for huge download bodies.)  The
fact that you can end up mixing encrypted and non-encrypted bodies
based on sensitivity is actually a performance advantage, if the
data that is not sensitive is not encrypted.

>Until I find the time to educate myself about the HTTPS, SSL and
>TLS protocols, and practice using something like OpenSSL and the Apache
>2.x module programming, then I personally can't explore the feasability
>or implementation of such things.  But hopefully someone else beats me
>to it.

It's there for your use today ... by the time you hack the feature
in a modern browser, httpd 2.2 or later should enjoy widespread
adoption :)


View raw message