When it comes to encryption, there are usually two perspectives in any organization outside of IT or infosec. Those who are concerned with compliance/SSL Labs/green padlocks, and those who are mostly unaware of HTTPS encryption. Increasingly, consumers and businesses alike are choosing selecting services and partners based on HTTPS encryption. More importantly, tools like SSL Labs grading and more aggressive, detailed browser warnings and restrictions have made it very simple to determine whether a site or service employs strong encryption.
We’re getting ahead of ourselves, though. The question we have to ask is:
Why have browsers become more restrictive? Why are SSL Labs grades so important?
Despite the doom-saying of many in the information security industry, the overall security posture of the Internet is continuously improving. Network-layer security is pretty well understood, with very advanced firewalls easy to deploy and manage. As a result, attackers move on to exploit weaker links via social engineering, endpoint malware, and application-layer vulnerabilities. One of the tools we use to make application-layer attacks more difficult is HTTPS encryption. Naturally, the encryption itself has become a target of attacks.
Over the past 2 to 3 years, vulnerabilities in HTTPS encryption have been seemingly countless. Heartbleed, BEAST, POODLE, FREAK, LogJam, WeakDH, and DROWN are just a few in the litany of vulnerabilities and attacks that have been published over that short span. In most cases, these attacks or vulnerabilities could be mitigated by strengthening the cipher suite used by the server terminating the HTTPS encryption.
SSL Labs was launched around 2009, but became more prevalently referenced and used among those I talk to in 2012. Not coincidentally, the high-profile SSL vulnerabilities BEAST & CRIME were published in 2011. Since SSL Labs began publishing the SSL Pulse reports in April 2012, the number of sites achieving an “A” grade has risen from 11% to 40% in the most recent survey dated July 2016. Excellent evidence that one of the foundations of Internet security has been steadily and significantly improving.
Browser such as Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Internet Explorer/Edge increasingly seek to offer consumers better security as a competitive edge. Among the many browser security features are checking HTTPS connections and displaying warnings to the end user. These certificate, encryption, and protocol warnings have become increasingly stringent, and have a direct and immediate impact on consumer trust for any sites they visit. The aforementioned SSL Labs is the best measure of how any given web site will be displayed in the browser.
While compliance does not always equal security, the latest PCI Digital Security Standard (DSS) does much to drive widespread improvement the encryption used in HTTPS-based connections. In 2015, PCI DSS v3.1 was published, mandating that all HTTPS connections with credit card data implement Transport Layer Security (TLS) version 1.1 or better as the protocol for encryption. Although the completion date for migrating from SSLv3 and TLS 1.0 to TLS 1.1+ has been extended to 2018, most organizations are working hard to ensure all components of their web application comply with this new standard, end-to-end. Not coincidentally, the SSL Labs grading criteria caps the overall grade to C if TLS 1.2 is not supported. Where PCI DSS v3.1 is concerned, it pays to be a bit of an over-achiever.
The TLS protocol version is important, since the protocol has impact on the available cipher suites. Of greatest importance to the privacy of an HTTPS connection is the use of Perfect Forward Secrecy (PFS) ciphers. To simplify how PFS affects privacy, consider the now-infamous Heartbleed vulnerability. The biggest fear with an exploit of Heartbleed was that the private key used to encrypt all HTTPS transactions could be dumped from the server’s memory. With possession of the private key, an attacker could now decrypt any previously recorded encrypted transactions since that private key went into use. PFS ciphers would mitigate that impact, by using ephemeral or per-session private keys.
By enforcing the use of TLS 1.2, better and stronger ciphers are available and old vulnerabilities like BEAST and Heartbleed are irrelevant. However, beware that some older browsers or other client types may not support the latest ciphers and protocols. In some cases, this compatibility limitation is good since it ensures that old, insecure browsers can’t be used. In other cases, it may impact too large or critical a group of end users. By analyzing browser and client types available in many web analytics tools, it is possible to project the potential impact of enforcing more modern cipher and protocol usage.
Looking forward, we know that Apple introduced App Transport Security (ATS) in iOS 9, and will begin enforcing the use of ATS by app developers more strictly in iOS 10, due out in Fall 2016. The IETF is also working hard on the next version of TLS, v1.3. Though there are still some disagreements over the final specifications of TLS 1.3, the exclusive use of PFS ciphers is certain to be in the final draft, whenever it is ratified. In addition to these changes, the HTTP/2 standard is seeing very rapid adoption. By default, HTTP/2 employs only HTTPS and only PFS ciphers. Despite these rather strict encryption requirements, adoption is growing due to the greater efficiency and speed of HTTP/2 over the predecessor HTTP/1.0 and HTTP/1.1 protocol standards. Even absent HTTP/2, there are many steps to take to ensure that HTTPS doesn’t slow down page load times. After all, performance and availability drive the business, and will trump security every time.
In summary, security has become a competitive advantage for businesses. Tools such as SSL Labs and browser warnings have increased visibility and awareness of how HTTPS is implemented, both good and bad, regardless of knowledge of cryptography. On the road to achieving this competitive advantage via HTTPS encryption, businesses must work closely with all aspects of the technology teams – from information security to application development to infrastructure and operations – to ensure that HTTPS does not impact performance or availability of various e-commerce systems.
As a Senior Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers and F5 product teams, providing a hands-on, real-world perspective. He is a regular contributor on InformationSecurityBuzz.com, a co-founder of BSidesNYC, and a speaker at AppSecUSA, BC Aware Day, GoSec Montreal, and the Central Ohio Infosec Summit, among others. 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.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.