This is a problem affecting any server trying to do what's called
"name virtual hosting" with TLS. "Name virtual hosting" is of course
when one server has multiple names --- different DNS hostnames that
map to the same IP address, and reach the same physical server,
which then wants to adopt different identities to match the hostname
the client looked up.

The problem is that nothing in the network informs the server of
what domain name (if any!) the client looked up to get its IP
address, before connecting to the server.

There is at this point one major protocol where name virtual hosting
works invisibly to clients: that's HTTP. That works because the
server is silent when you connect to it; it doesn't say anything
until the entire request has been placed by the client, and that
request includes the hostname that the client is interested in[1].

But TLS (nee SSL) changes things. As long as clients check server
certificates, name virtual hosting doesn't work with any current
application of TLS that I know of. Clients examine the CN (Common
Name) field --- there's only one, and it has a single value --- in
the cert --- only one allowed --- that the server offers. TLS is
designed to make name vhosting impossible. If HTTP had some way to
pick up the Host: header from the client before turning TLS on, it
would be possible, but that's not how it's set up.

SMTP at first blush looks like it might possibly be a better
candidate, since unlike e.g. HTTPS it's not a pure encapsulation of
the whole SMTP dialogue; instead, the dialogue starts off in plain
text then uses STARTTLS[2] to switch to TLS encryption. Sadly,
however, there's still no way in the protocol for the client to
inform the server of what hostname it had looked up to reach that
server before starting up TLS; the server has no way to tell which
cert to offer. So as always TLS is incompatible with name virtual
hosting, as long as clients are checking server certs.

Does anyone know for sure if server cert checking is common in SMTP
STARTTLS implementations? If not, then this might not actually be an
issue.

-Bennett

[1] Some dispute this; including the Host: header wasn't included in
    the HTTP/1.0 standard, it's in the HTTP/1.1 standard, and many
    clients make requests asking HTTP/1.0. The thing is, they ask
    HTTP/1.0, because they don't implement all of HTTP/1.1, but all
    clients in use today include the Host: header in queries. Name
    virtual hosting is safe and proper for normal HTTP.

[2] RFC 2487 <URL:http://www.ietf.org/rfc/rfc2487.txt>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8+20AHZWg9mCTffwRAuFNAJ96XvWvy5q1UWWGG4T8PFj/y7KfogCbB8aw
4HUGbB8K/AyfD2t/KiNC34Q=
=aIT+
-----END PGP SIGNATURE-----

-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]