I am a security researcher at INRIA Paris in team PROSECCO (http://prosecco.inria.fr)
We have been investigating a new class of attacks against the deployment of TLS on the Web. The main idea behind these attacks is that when two servers host different domains but share the same certificate (which covers both), an attacker that controls the DNS can redirect the first domain to the second server.
If the second server does not reject the unrecognized request meant for the first domain, there is a risk that the two domains may be confused. For instance, if the server treats the request as if it was meant for the second domain, and the adversary controls at least part of this domain, he may be able to completely impersonate the first domain (at the HTTP level, which is much stronger than an XSS attack).
The main issue is the behavior of all HTTP servers when they receive a request with an unrecognized Host header. If there one of the virtual hosts is marked as default in the configuration, it will be used (even if it doesn't match the configured domain). We argue that this behavior is too dangerous when the server is used for HTTPS with a certificate that may cover names that are not served by this server (including wildcard certificates, which may cover unknown domains).
Whether an attack is possible depends on the default virtual host. We found several possible scenarios with different impact levels:
If the second server is controlled by the attacker (who doesn't have the private key of the certificate), it is possible to completely impersonate other domains in the certificate. This may seem like an unlikely scenario, but it does occur in practice for content delivery networks. In particular, we found that the fallback host for all Akamai servers allow proxying to attacker servers. This leads to complete HTTP-level impersonation of many high-profile websites. We show in the attached video how to impersonate and steal secure/httpOnly cookies from Twitter, LinkedIn, PayPal, CNN, Microsoft, Apple... Because of the particular severity of the attack against Akamai we have contacted them directly about the problem.
If the default host of the second server contains a page controlled by the attacker (or vulnerable to an XSS). Then, it can be translated to an Origin hijack/XSS attack on the other domain. Again, this may seem like an unlikely scenario. However, even if the attacker controlled page or XSS is only present on the attacker's account, a DNS attacker can always force his session on the client before sending him to his malicious page. We found several instances of this attack, most notably on websites that allow user to store files on their accounts. We made a proof of concept video against Dropbox, which is attached to this report.
If the default host on the second server redirects unrecognized requests to HTTP, an attacker is able to access any URI that the user tries to access over HTTPS on the first domain. This is by far the most widespread behavior - we found several thousand such servers by sending requests to web servers for hosts covered by their certificate but not served locally. A typical way to exploit this attack is to target OAuth tokens. We made two proofs of concept of this attack: the first against Pinterest and the second against CloudFlare. It is worth mentioning that most often, the HTTP redirection points to the second domain (which the attacker can redirect to his own server by DNS) - even if the first domain is protected by HSTS, the redirection may proceed when the second domain isn't. The case of CloudFlare is interesting because they issue certificates valid for 20+ domains of their customers, and even if they cancel the service, their domain can remain in a CloudFlare certificate for months (or years). Furthermore, CloudFlare always redirects requests for former customers to HTTP - thus honest and well configured websites that are no longer served by CloudFlare can be compromised.
All of the attacks above only assume that the attacker controls the DNS, which is well within the threat model of TLS. There exists a variant for servers configured with SNI-based virtual hosts: a network attacker can downgrade a connection to SSL3 which causes the SNI to be removed. The request will go to the default virtual host with the same potential attacks as above. Because SNI is not widely used, we did not find a real-world example of this variant.
The difficult question is how to prevent this class of attacks. Configuring a default virtual host that only returns an HTTP error does prevent the attacks, but there are thousands of vulnerable servers and it is not reasonable to assume that webmasters will configure their servers correctly.
Instead, I propose a coordinated change in HTTP server behavior. By default, a request received over TLS with an unrecognized Host header should be immediately rejected. There would be an option to enable the previous behavior, but it should precisely document the risks of allowing arbitrary Host values, in particular when they are covered by the TLS certificate.