On Mon, 2006-03-06 at 10:25 +0100, Boyle Owen wrote:
> > -----Original Message-----
> > From: Daniel Rogers [mailto:[EMAIL PROTECTED]
> > Sent: Montag, 6. März 2006 03:17
> > To: dev@httpd.apache.org
> > Subject: SSL enabled name virtual hosts
> >
> >
> > I am not convinced by the argument that name based SSL virtual hosting
> > is impossible.
>
> It's not only an argument, it's a demonstrable fact.
>
> I did read your posting and you clearly do understand a good deal about
> HTTP but there are a couple of key points that are leading you to
> wrongthink:
>
> - Using an extra port (444, etc) immediately gives you access to multiple
> SSL VHs. But they are then port-based VHs, not name-based. SSL VHs have
> to be distinct at the TCP/IP layer, so changing ports achieves that.
> NBVHs are degenerate at TCP/IP and only distinct at HTTP. But using an
> extra port is not a professional solution - anything other than port 80
> and 443 will not wash on the commercial internet.
I don't think you understand what I did. Let me explain with some
apache configuration snippets:
<VirtualHost _default_:443>
DocumentRoot "/var/www/html-secure"
AliasMatch .* /var/www/html-secure/index.php
SSLEngine on
/SSL options/
</VirtualHost>
Listen 444
Listen 80
NameVirtualHost *:444
NameVirtualHost *:80
<VirtualHost *:80 *:444>
/virt host options/
ServerName example.com
</VirtualHost>
<VirtualHost *:80 *:444>
/virt host options/
ServerName example2.net
</VirtualHost>
Contents of index.php:
Request.php is based on the pear module HTTP_Request, modified so
that the header names are stored without being converted to lower case.
This is not a complete implementation. It only works for GET and HEAD
requests. And redirects are not filtered.
<?
require_once "Request.php";
$req =& new HTTP_Request('http://' . $_SERVER["HTTP_HOST"] . ":444" .
$_SERVER["REQUEST_URI"]);$req->setMethod($_SERVER["REQUEST_METHOD"]);
$req->sendRequest();
$code = $req->getResponseCode();
header(HTTPStatus($code));
foreach ($req->getResponseHeader() as $name => $value) {
header($name . ": " . $value, true);
}
if ($_SERVER["REQUEST_METHOD"] != "HEAD") {
echo $req->getResponseBody();
}
/**
* HTTP Protocol defined status codes
* snipped from the user comments in the php manual
* @param int $num
*/
function HTTPStatus($num) {
static $http = array (
100 => "HTTP/1.1 100 Continue",
101 => "HTTP/1.1 101 Switching Protocols",
200 => "HTTP/1.1 200 OK",
201 => "HTTP/1.1 201 Created",
202 => "HTTP/1.1 202 Accepted",
203 => "HTTP/1.1 203 Non-Authoritative Information",
... the rest of the status codes ...
return $http[$num];
}
?>
My SSL virtual hosts are, effectively, Name based, not port based (there
are only two ports involved 443, and 444 for unlimited virutal hosts).
All ssl virtual hosts are on port 444, and their name is used to
distinguish them.
The end user sees only port 443. No worries about weird port numbers.
> - You're right that since apache can't see the host header, it uses the
> cert from the default VH to establish the SSL session. Thereafter,
> it *can* see the host header and so can route the requests successfully.
> This give a lot of people the illusion that SSL-NBVH is possible. The
> big problem is that you don't get authentication because the default cert,
> generally, will not match the requested site. For professional SSL,
> authentication is every bit as essential as encryption so this won't do.
>
> - Using SubjectAltName to allow for an "all-purpose" certificate sounds
> like a good idea and would be fine in a research environment where you
> are making your own certs. But I don't think it would be very practical
> in a commercial situation. If you are a web-hosting company, are you
> really going to get a new certificate every time a site wants an SSL VH?
> Who sells these certs? How expensive are they?
I'll answer these two points together. subjectAltName doesn't have to
allow an "all purpose" certificate. It can be on a single host, or an
enumerated set of hosts. I don't think the argument you present, that
it's not worth implementing a feature because noone sells a certificate
that would work with it, holds water. What motivation does any
certificate seller have to even offer a licensing scheme that works with
a feature no one can use because it doesn't exist.
These companies are not stupid. If customers repeatedly came to
Verisign (or any other certificate company) and said:
<begin imaginary conversation>
Me: Verisign, I need a multi-host certificate. I am willing to pay the
same price as multiple certificates for multiple hosts, but I need you
to make me a single certificate for all those hosts.
Verisign: Why should we?
Me: Because apache has a new feature to allow name based SSL virtual
hosts, but only if those hosts are specified in a subjectAltName
Verisign: And if we don't?
Me: I'll keep asking someone else until someone says yes. Also, there
are about to be 1000 more like me.
Verisign: Well, we talked about it and we think it will cost you 5
percent more this way (bwa ha ha)!
Me: Great! I'm a hosting company and can now offer an incredible
feature to our clients, besides I just passed the cost of the
cert into our clients with a markup for ourselves, of course!
<end imaginary conversation>
In short, if there is demand for a multi host certificates, I am sure
Verisign and every other hosting company on the planet is clever enough
to figure out a pricing structure that will allow them to sell
certificates for that feature and make as much, if not more, money.
Because, you'll notice, allowing named based virtual ssl hosts actually
increases the number of certificate licenses that someone is willing to
buy. There may be fewer files to transfer, but verisign doesn't really
base it's pricing on files, they price their licenses on a per host
basis, and nothing in this virtual host model prevents that. Besides,
as David Burry already pointed out, people can already buy wildcard
certs today. Right now. And a wildcard cert plus name based virutal
ssl hosting, if implemented in apache, as I discussed in my previous
email, would work, with authentication, and normal port numbers.
> As has been pointed out, the problem is already solved at the technical
> level by upgrading to TLS within HTTP/1.1 (rfc 2817). The real problem
> is waiting for browsers to support it...
But browsers support SSL name based virtual hosts as I descrbed it
today! Instant backwards compatibility! Every browser that currently
understands SSL will work. So, we are waiting for browsers to support
it. . . .
This means we are waiting for Microsoft to support it. Since everyone
else will have already done it, or will follow behind quickly.
Then we are waiting for the current generation of browsers to almost
disappear from the net. (since no one is going to host a secure commerce
site that only works with the newest, shinnieist browser)
So we are going to wait, what, 3 years, or 5 years AFTER microsoft
implements this feature in their latest browser (which may never
happen), while everyone upgrades to Vista, or Vista Next and todays IE,
which doesn't support this method drops to less than 10 percent market
share?
So to sum up:
Your two arguments, in short, are, no one sells certificates for that
feature, and there is a technical solution already. Well, the feature
doesn't exist (even though it could, I MADE IT WORK. IT WORKS FOR ME.),
so why sell certificates for it, and the technical solution is not
compatible with current browser so it is _years_ away.
Also, I don't appreciate being called a troll. I am trying to make
reasoned articulate arguments. I haven't insulted anyone, and I am
really making an effort to understand the arguments people are
presenting me.
--
Daniel
[EMAIL PROTECTED]
