About once a week, we have a reader complain about a bad certificate for "incidents.org". Many years ago, this site was known as "incidents.org", not "isc.sans.org" or "dshield.org". As a result, you may still come across a reference to "https://www.incidents.org". The domain still points to the same IP address as isc.sans.org, but our SSL certificate is issued for "sans.org", not "incidents.org", which causes the bad certificate warnings.

This is a common issue: It is trivial to use "Name Based Virtual Hosting" for regular web sites. The browser will send a "Host" header indicating which host it would like to connect to. This host header is mandatory ever since HTTP/1.1. But for https, this doesn't work. The host header is now encrypted, and in order to decrypt it, the server needs the correct key... if the key is different for each host, then you got a catch 22. As a result, each https host needs a dedicated IP (or port, but that's ugly).

In order to solve this problem, the Internet gods brought us RFC 4366 and "TLS Extensions" . Or as the RFC will tell us right in the beginning:

Allow TLS clients to provide to the TLS server the name of the server they are contacting. This functionality is desirable in order to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. [1]

More and more browsers and web servers start to support RFC 4366. With this, we solve another problem (at least partially): Monitoring https traffic. It was always possible to log the IP address. But with RFC 4366, the host name is now transmitted in the clear, as the following fragment of a packet capture shows:

In this case, I connected to "secure.dshield.org". Wireshark will recognize the extension (so does tshark). The following display filter will select all packets with the "sever_name" ssl extension: ssl.handshake.extension.type == 0x0000 .

Now you may ask: Is this a problem? Well, if you want to keep the host name secret, then it is. But without it, there is a one-to-one relationship between hostname and IP address, so not much is lost, and the host name is revealed in clear text in the server's certificate. Is there the possibility of a known plain text attack? Maybe... (e.g. we know there has to be a "Host: ..." header with known content). But I am not enough of a crypto geek to know. From my perspective, there is plenty of known plain text in https traffic.

But there is also an opportunity here. Maybe a tool to log the hostname. Or a tool that compares the certificate coming back to the host name requests and alerts of a mismatch.

Of course, once I get around to it, incidents.org may get its own, valid, SSL certificate.