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 >Hosting.
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 >used. 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. Yes. >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] ftp://ftp.rfc-editor.org/in-notes/rfc2817.txt 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. http://httpd.apache.org/docs-2.1/mod/mod_ssl.html#sslengine 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 >transferred. 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 :) Bill
