DNS Forgeries Enable Attacks On Secure Web Sites

There seems to be a lot of confusion about the relationship between DNS and SSL. Even a slip of the virtual pen, a mistake I recently made, only adds to the problem. The recent DNS forgery issue that Kaminsky talked about in his Black Hat session doesn't break SSL in any way. However, DNS forgeries enable attacks which subvert poorly written applications that use SSL to encrypt data between a client and a server.One function of DNS is to resolve host names into IP addresses. It's how we can type in http://www.example.com and reach a Web page. The "www" is the host name, "example" is the domain name, and "com" is the top level domain (TLD). The "www" is not significant. We could just as easily name our Web server "mail.example.com". Doing so might be confusing, but using "www" to denote a Web server is a common practice. In fact, having both "example.com" and "www.example.com" point to the same Web server is considered a good thing to do.

Just like any network service, SSL, or more properly, TLS, for Transport Layer Security, an IETF standard, uses DNS to resolve domain name IP addresses so that client knows which server to connect to. TLS doesn't ensure that the IP address returned from DNS is correct. Neither TLS, nor any network service, cares what IP address is associated with a domain name as long as the service can make the connection to the designated IP address and port. TLS uses TCP port 443 by convention, but TLS can run on any port, like port 80, commonly used for HTTP, or port 25, which is commonly used for SMTP mail. When you type in "https://www.example.com," TCP port 443 is implied by the HTTPS. If you wanted to use TLS on port 80 or 25, you simply add the port number like "https://www.example.com:80" and "https://www.example.com:25," respectively.

Once the TCP connection is established, the TLS client tells the TLS server that it wants to start a TLS session and the cipher suites the client wants to use. The server picks a cipher suite and sends the client the details. Then, the server sends it's digital certificate to the client. If the certificate checks out OK (more on that later), the client and the server do some more stuff and complete the SSL negotiation.

On a side note, the client and the server have been talking to each other's IP addresses. Domain names haven't been a factor except for the client to determine the server's IP address. This is why you normally can't have multiple virtual HTTP hosts sharing the same IP address using SSL. The Web server doesn't yet know what Web server you want to access. That is specified in the HTTP HOST: header. Since SSL hasn't been established over this TCP session, no HTTP traffic has passed, either, thus no host header. RFC 4366 does define an extension to TLS to send a host header during TLS negotiation. Both the Web server and the browser have to support TLS extensions. The TLS test site can test your browser for you. Opera 8 and Firefox 2 send the extension. IE7 supports the extension only on Vista.

When the client, say a Web browser, receives the server's certificate, it wants to check to make sure the certificate is valid, such as making sure the certificate is within the validity period and trusted by ensuring either the certificate is in the local browser store or that is was signed by a CA that is in the local browser store. None of those checks need to use DNS. Finally, the browser checks to see if the domain name in the request matches the common name defined in the certificate. The hostname and the common name must match exactly or else a dialog box pops up for a domain name mismatch. No look-up is made on the DNS name, it's a simple match.

The browser asked for www.example.com and the digital certificate's common name should be www.example.com. That is how digital certificates are used to identify and authenticate the Web server to the Web browser. Of course, using a digital certificate is predicated on the fact that the signing CA has properly verified that the digital certificate was issued to the right organization by an authorized person and that the Web servers' signing key hasn't been compromised.

I am pointedly ignoring the use of wildcard certificates, which can match multiple sub-domains. For example, a digital certificate that has *.example.com will match on example.com, www.example.com, mail.example.com, aaaaaaa.example.com, etc. Avoid them.

In Kaminsky's presentation, the problems he discusses with SSL and DNS are largely due to problems (slides 64 to 79) in how applications are written, such as Web apps mixing protected and unprotected content on the same page, potential issues of overwriting secure cookies, problems with SSL VPN clients which are made from ActiveX, Java, or Flash, and hi-jacking logins. SSL isn't broken or even weakened by SSL forgeries, but the applications that use SSL are written so that an attacker can modify traffic or even hide the fact that SSL is being used from the server.