The World Wide Web (WWW) has come a long way during the last decade. By contrast, the HTTP protocol, which provides the communication application layer, has remained pretty much stable throughout that period.
Changes to HTTP’s specifications last occurred in 1999 when HTTP version 1.1 RFC was finalized by the by the Internet Engineering Task Force (IETF).
All this is going to change soon, as the IETF has chartered a working group with the task of updating HTTP to make it more suitable to the 21st Century Web. The main, though not the only, candidate for the task, is the SPDY (pronounced speedy) network protocol. One of SPDY’s main characteristics is its usage of the SSL encryption protocol. Therefore, if SPDY becomes HTTP 2.0 and completely supersedes its predecessor, then all of the web’s traffic will become SSL encrypted. While that may seem to be some good news for web users’ data privacy and integrity at first glance, a more thorough analysis reveals that it may give rise to some new challenges.
When SPDY met SSL
The SPDY network protocol achieves reduced latency through HTTP headers compression, request streams multiplexing and prioritization. SPDY is implemented as a session layer underneath the HTTP layer.
Although not currently a standard protocol, SPDY has already been adopted by some prominent members of all parties involved: clients (Chrome, Firefox), servers (Apache, Nginx) and web applications (Google, Twitter).
The link between encryption and efficiency does not seem to be natural. If anything, encryption increases the latency of the data transfer. So how it became the cornerstone of a protocol that aims to decrease latency?
The answer lies in the IETF’s requirement for HTTP 2.0 protocol’s “ability to be deployed on today’s Internet.” One of the main technical corollaries of this requirement is that no new TCP ports will be needed to be open, as currently firewalls aren’t reliably open to ports other than 80 (HTTP) and 443 (HTTPS). Since port 80 is often inspected and manipulated by transparent proxies, changing the messages to SPDY format will cause these proxies to fail and consequently break today’s internet. Therefore, the only viable possibility left is to implement SPDY on port 443 which means SPDY has to be encrypted by SSL.
Not in front of the kids!
SPDY and SSL’s union is not a “marriage of true love”, a match created by an original design decision. Rather, it is more of a “marriage of convenience”, a byproduct of practical limitations that created an odd couple. What drives the division? There are conflicting interests as the SSL side would like everything to as secure as possible while SPDY side would like everything to as efficient as possible. In this state of affairs, it’s very understandable why their offspring, the SPDY protocol stack, will inevitably disappoint at least one of its parents.
In other words, sites that didn’t own SSL certificate previously to SPDY will want one now for performance reasons only. Therefore they will want to obtain the SSL certificate as rapidly as possible, and make the SSL as weak as possible, making the following scenarios very likely:
• Lax certificate issuance procedures: SPDY will create a demand for certificates and apply pressure on the CAs (Certificate Authorities) to issue certificates in a more rapid process which bound to be less secured. And with current PKI (Public Key Infrastructure) all certificates are born equal (with some exceptions such as EV SSL) regardless of the process they were issued and there’s no real way to tell them apart.
• The return of weak SSL ciphers: Weak SSL ciphers that were virtually extinct might be resurrected and re-enabled on servers and browsers, as they would be needed for high performance SPDY deployment. Currently SSL ciphers settings are global and changing it for SPDY will impact the original SSL deployments and make them less secure.
• HTTP referer header information leakage: HTTP considered URLs served over HTTPS to be more private and didn’t allow the inclusion of HTTPS URL as a “HTTP referer header” when navigating from HTTPS to HTTP site. When everything becomes HTTPS, the “HTTP referer header” will be present always.
Just to show that we are not merely crying wolf, in a recent presentation, one of Google’s SPDY developers suggested that system administrators should use “wildcard certificates” (a certificate for multiple domains), to enable better SPDY performance results. From the security point of view, the practice of having wildcard certificates is considered to be less secure. As stated by a security expert, “wildcard certificates a weaker, less trustworthy solution than individual certificates.”
As with all marital conflicts, ignoring the issues will not make them go away. We suggest SPDY and SSL will get some relationship counseling to sort things out, sooner rather than later.
