Disrupting the Internet in 2015

It’s the time of year when everyone is making predictions and top 10 lists. Even top 10 lists of top 10 lists. Looking back at the past year, some might say that 2014 was the Year of Encryption, and I would tend to agree. From the revelations in the wake of Snowden to the seemingly unending waves of SSL vulnerabilities, encryption has never ceased being top-of-mind. In my view, our hyper-awareness of encryption in the last couple of years will be the catalyst for the two most disrupting events to come in 2015: the ratification by the IETF of both HTTP 2.0 (HTTP/2) and TLS 1.3.

With the drafts of each protocol standard virtually complete, the IETF is set to ratify both in early 2015. These two 2015 events will have repercussions for years to come. Both protocols are major leaps forward from their predecessors (HTTP 1.1 and TLS 1.2, respectively). Prior to 2014, many expected both protocols to take much longer to be ratified. However, to address the persistent vulnerabilities found in SSLv3 and prior versions of TLS, the TLS working group accelerated the ratification of this latest version of TLS. Similarly, the goal of an all-encrypted Internet—to minimize governmental and other instances of eavesdropping—accelerated the ratification of HTTP/2.

HTTP hasn’t seen an update since 2003 and, as such, is long overdue. HTTP/2 competes with and was influenced by the Google protocol SPDY. A key feature of both HTTP/2 and SPDY is that both employ TLS encryption by default for transport. Other key features of HTTP/2 focus on enabling greater efficiency for requests and better native support for rich web applications with longer lived connections, often delivered via AJAX, WebSockets, or other HTTP-push technologies today. However, in the effort to provide both a “faster Internet” and an all-encrypted Internet, HTTP/2 is not only encrypted via TLS by default. It also tightly integrates HTTP with TLS for the first time. The Application Layer Protocol Negotiation (ALPN) enables HTTP/2 to be discovered and supported during the TLS handshake, streamlining the request from the browser.

While HTTP is making the jump from version 1.1 to 2.0 after a decade-long hiatus, TLS seems to be set for an incremental change from version 1.2 to version 1.3. The superficial TLS version increment belies a significant departure from previous versions of TLS. Static RSA and D-H key exchanges will no longer be supported. Compression support is gone. Support for non-AEAD ciphers has been removed. In general, the entire TLS handshake has been reworked to eliminate the vulnerabilities of the past few years. Padding attacks such as POODLE, timing attacks such as Lucky 13, and compression attacks such as CRIME should no longer be possible with TLS 1.3.

So, the stage is set for HTTP/2 and TLS 1.3 to burst on the scene and make the Internet faster and more secure. But what are the challenges?

First, many of our efforts to deploy better versions of TLS have been hampered by browser support for anything above TLS 1.0. Fortunately, browser auto-updates have enabled broad support for new TLS versions in a short period of time. This same auto-updating mechanism will enable rapid client-side support for HTTP/2. With that in mind, we turn our attention to server-side support.

I anticipate large CDN providers such as Akamai to rapidly enable both TLS 1.3 and HTTP/2 on their service platforms. Challenges abound on the web server platforms such as Microsoft IIS, Apache, and NGINX. It is likely that HTTP/2 support will be available shortly after RFC on these server platforms, but just as likely that each will require significant upgrades to support HTTP/2. Other platforms that interpret HTTP, such as ADC and WAF appliances, must also be considered when endeavoring to enable HTTP/2 for our web applications.

The adoption of TLS 1.3 on server platforms has a number of gating factors. The first will be OpenSSL support for the new TLS protocol. As the most widely-used SSL stack, server administrators will need to be upgrading to the appropriate version when it becomes available. Appliance-based solutions will need to upgrade their SSL stacks, as well, and may have dependencies on SSL chip manufacturers such as Cavium and Intel. The ripple effect of upgrading appliances, servers, and even chip firmware to support TLS 1.3 may be the biggest obstacle in enabling broad support for the new TLS protocol. Despite these challenges, I predict there will be pressure from both consumers and executives to adopt and support TLS 1.3 much faster than prior new versions of TLS.

On that note, I would be remiss if I didn’t mention the vital role of SSL Labs in raising awareness about SSL/TLS encryption on the Internet. In the wake of dozens of SSL/TLS vulnerabilities, it has become clear that merely providing SSL encryption is not enough. We must also ensure that we are providing quality SSL encryption by enforcing strong cipher usage, good TLS protocol versions, secure renegotiation, and ancillary features such as HTTP Strict Transport Security (HSTS). Via SSL Labs, we can determine whether the SSL/TLS encryption we offer is up to par and, if not, how to improve. We must also ensure that TLS encryption is not imposing undue overhead on web application performance. I recommend checking out IsTLSfastYet.com for more information on TLS performance optimizations.

Once TLS 1.3 is a released standard, I expect SSL Labs to be the main mechanism to determine proper support. SSL Labs reports will also be the main reason organizations move to upgrade their server-side SSL termination points. SSL Labs already notes TLS 1.3 version intolerance in their scans, and I recommend following Ivan Ristic on Twitter and his blog to stay updated on what will be factored into the server rating criteria in the future.

New TLS and new HTTP, all in 2015. These protocols enable most of the communications on the Internet, and supporting the latest versions is vital to providing the fastest and most secure experience possible. We have our work cut out for us in the new year, but I’m confident that our renewed vigilance around effective encryption will enable us to deploy these new protocols faster than ever before.

[su_box title=”About Brian A. McHenry” style=”noise” box_color=”#0e0d0d”]

Bio: As a Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers, the F5 sales team, and the F5 product teams, providing a hands-on, real-world perspective. Prior to joining F5 in 2008, McHenry, a self-described “IT generalist”, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.

Twitter: @bamchenry[/su_box]