Traditionally http over ssl/tls has problems with name-based virtual hosts. There are several ssl certificates each of which is binded to one of the virtual hosts. Because the http requests sent over ssl/tls are encrypted, the server can not figure out which certificate to be used for the client-server hand-shake. For IP-based virtual hosts, this is not an issue as each certificate can be bind to an unique IP.
Mostly http over ssl/tls is implemented with a different port (443/tcp), rather than the standard http port (80/tcp). The conection is encrypted from the beginning. For this we even use a different URL prefix, i.e., https instead of http. This situation is similir to smtps for smtp over ssl and smtp the plain connection. However, smtps is now obslete and the stardard way for excrypted smtp connection is to upgrade a non-ecrypted smtp session to over tls. This way, both plain and encrypted smtp connections can be listened on the same port (25/tcp).
There is an internet standard to defaine how to similiarly upgade a plain http session to over tls. See RFC2817.
If this is implemented, the above-emtioned problem for name-based virtual hosts over ssl/tls will be naturally solved. Because the requested server name is in the plain-text http header, the encryption will be started after the connection is established.
Unfortunately this RFC isn’t widely implemented. The number 1 http server, apache implemented it in v2.1; the first stable version supporting this is v2.2, which was released in December 2005. I don’t care about IIS, but like many other cases (jpg2000, alpha rendering in png and CSS2 immediately come into my mind), Micro$oft holds technology advance again because of its dominant market share at the client side: IE doesn’t support it. Even my beloved mozilla firefox doesn’t support this feature (They planed to support RFC2817 in v3, see their roadmap).
There is another way around this issue: the server name indication (SNI) extension for TLS. This is one of various extenstions specified in another internet standard, see RFC3546.
The TLS SNI extension will also allow a client to tell the server which server is contacting, in the extended client hello. The traffic is always encrypted from the beginning as the https protocol is used, but the server understands which virtual hosts to be served after ssl handshaking.
It was note that Firefox 2 has already support RFC 3546. Check here. Also starting with IE 7, Micro$oft supports the TLS SNI extension.
On the server side, although apache v2.2 has native support for RFC 2817, the third-party module, mod_gnutls, has to be used for RFC3546 support. This module adds RFC3546 support to both apache v2.0 and apache v2.2.
Therefore for now, we’ll have to use apache (v2.0 or v2.2) plus mod_gnutls on the server side, and mozila firefox v2 or M$ IE 7 on the client side, for an SNI-enabled name-based virtual hosts over tls. After firefox v3 is released, we can use apache v2.2 with firefox v3, and enjoy plain and encrypted http connections on the same port! Can’t wait for that day.
No comments:
Post a Comment