Understanding the interface between TLS and applications is critical to the security of most practical use cases for TLS. In particular, the combination of HTTP with TLS, used by millions of websites, offers interesting and unexpected capabilities to the attacker, such as the ability to trigger various adaptive chosen-plaintext attacks, or trigger arbitrary many instances of the protocol (with some control over the data exchanged). These capabilities have been exploited by important attacks such as BEAST (which first demonstrated the exploitability of a known vulnerability of CBC chaining in TLS, pointed out by Rogaway in 2002), and CRIME (which demonstrated that compress-and-encrypt is trivially unsafe under adaptive chosen plaintext attacks, which are very widespread in HTTPS).
The interesting pattern of these attacks is that the attacker can break the security goals of the application (e.g. the same-origin policy) or of TLS (e.g. secrecy, authentication) by operating jointly at the transport and application layers. We have found several new attacks that follow this pattern: cookie cutter relies on unsafe side-effects from partial HTTP messages (recall that TLS only enforces prefix integrity until the connection closure altert is received); virtual host confusion and SPDY connection sharing rely on mismatches between the transport-layer and application-layer notions of identity (e.g. a certificate may be used by different HTTP principals, which can be confused at the transport layer).
Because of the popularity of cloud hosting and content delivery networks, it is increasingly common for webservers to serve several websites on the same IP address, and sometimes, using the same certificate. This is potentilly dangerous is a server offers TLS credentials that apply to many HTTP origins (e.g. a wildcard certificate, or a TLS session cache shared with other servers), but actually only offers contents that apply to a subset of them.
As a simple example, imagine a webserver that is configured to serve requests from dl-web.dropbox.com, but it uses a certificate for *.dropbox.com. What should the webserver do if it receives a request for www.dropbox.com? At the transport layer, the connection is successfully established; however, most web servers will still process the request through the default virtual host (which is likely to be dl-web.dropbox.com). Therefore, this fallback mechanism enables an attacker to load a page from some domain under the origin of another domain related at the transport layer (in this case, the wildcard certificate). However, if these two domains have different security characteristics (e.g. one contains untrusted user contents), this can lead to an XSS attack.
More details about this class of attacks can be found in the virtual host confusion paper from WWW'15, or in the slides from the Black Hat 2014 briefing.
As an optimization, SPDY and HTTP/2 propose to reuse an existing connection to send a request to a website when there exist an active TLS session that was established with a certificate that would also have been valid for the new request. This optimization becomes highly dangerous when a certificate is shared between mutually untrusting websites, in particular if they rely on specific transport layer features (e.g. client authentication, or binding of session cookies).
There exist a simple but highly effective attack against connection sharing when a user accepts to use any untrusted certificate: a network attacker is then able to insert arbitrary many extra domains in the certificate, and because of connection sharing, the browser will reuse the connection to the attacker for requests to these domains. This attack was present in Chrome and could also be used to bypass the pinning policies (pre-loaded, and HSTS), which can be exploited by an attacker with the ability to obtain signed malicious certificates. For more details, refer to the virtual host confusion paper.
