With yet another data breach in the news, and the focus on digital security at the forefront of most people’s minds, I thought it would be a good time to review the history of HTTP, and the role it plays in current (and future) security measures.
A brief history of HTTP, SSL and TLS
It’s a safe bet that when Tim Berners-Lee was working on HTTP in the 1980’s, he couldn’t have anticipated the hand his new protocol would have in creating and shaping the digital world we all know today. A digital world where an online presence and the ability to do business over the web is not just a “nice-to-have” for most organizations, it’s an absolute necessity.
As amazing as HTTP is, it’s a protocol that transmits data in plain text without encryption, that data can easily be captured and exploited using ‘man in the middle’ attacks. Credential and credit card theft really were trivial in those early days! What follows is a brief overview of HTTP encryption from its first inception to today.
It was Netscape who first recognized the need for HTTP encryption to protect the emerging e-commerce sector in 1994 when they released the SSLv2 cryptographic protocol. This led to the extension of the HTTP protocol into the now widely recognised HTTPS or HTTP Secure protocol.
SSLv2 turned out to be vulnerable to a few nasty security bugs and was promptly replaced by SSLv3 as part of RFC6106 in late 1995. It’s worth mentioning that Microsoft released their own version of encryption known as PCT which actually fixed some of the holes in SSLv2 but never gained popularity outside of their own product suite.
In 1999 and after three years of discussion, the Internet Engineering Task Force (IETF) formalized Netscape’s SSLv3 with some revision into a standard known as Transport Layer Security (TLS) 1.0 under RFC2246. Interestingly, the name was changed from SSL to TLS to maintain the appearance of the IETF’s impartiality so it wouldn’t look like they were endorsing Netscape’s protocol.
2006 saw TLS 1.1 released which added extra protection against certain cipher block chaining attacks amongst other changes. The changes made to the protocol also mitigate the BEAST attack but no-one quite appreciated the significance of that at the time!
In 2008, TLS 1.2 was released under RFC5246. This version adds a new feature called authenticated encryption which removes the need for streaming and block ciphers thereby removing the threat posed by attacks against cipher block chaining.
2008 was also a rough year for certificate authorities where a flaw on the StartCom website saw them issue domain certificates without owner validation and CertStar didn’t even bother checking domain ownership in the first place! The venerable MD5 protocol was also deemed insecure and obsolete following weaknesses in the protocol being exploited to trick RapidSSL into handing over a CA certificate to a group of researchers allowing them to issue trusted certificates for any domain in the world!
A Firefox browser addon called Firesheep become available in 2010 which made the hijacking of unencrypted session cookies from sites such as Facebook and Twitter extremely trivial, allowing sessions to be taken over. For the first time, some online businesses look to move all of their website traffic to be encrypted by HTTPS by default.
In 2011, SSLv2 was made formally obsolete by the IETF over ten years after it was recognized as being insecure. Worryingly, 54% of webservers still supported SSLv2. The BEAST attack later in the year which targeted predictable initialization vectors in TLS 1.0, caused many businesses a significant headache. Even though BEAST had been addressed in TLS 1.1 released five years earlier, very few organizations had moved to TLS 1.1 leaving the vast majority of worldwide HTTPS traffic vulnerable to decryption.
2013 saw Edward Snowden release thousands of classified NSA documents which showed the extent that intelligence agencies around the world were monitoring plaintext communication. Mainstream browsers including Chrome, Safari and Internet Explorer all added support for TLS 1.2. Firefox followed in early 2014.
Perceptions about encryption and vulnerabilities in various ciphers used by HTTPS really began to change in 2014 following a number of high-profile attacks and exploits being discovered including BERserk, POODLE and POODLE TLS. Certain Distributed Denial of Service mitigation providers started issuing free certificates to their users to protect websites.
The RC4 cipher suite and SSLv3 were formally prohibited by the IETF in 2015. Let’s Encrypt, an initiative to provide free certificates for web servers, kicks off.
In 2016, several major changes were made to the Chrome browser to prevent the now defunct RC4 and SSLv3 from being used. Chrome also started to block the fallback of connections using TLS to older, non-secure versions. Perhaps more importantly, more than 50% of web pages being loaded by Mozilla are now delivered via HTTPS!
2018 finally saw the ratification of TLS 1.3 as part of RFC 8446, ten years after the previous version TLS 1.3. TLS 1.3 introduces speed benefits as only one round trip is required to complete the TLS handshake. It also removes the obsolete and insecure features from TLS 1.2 including SHA-1, RC4, DES, 3DES and MD5 amongst others.
The future …
For the future, the CA Security Council predicts that by the end of 2019 and nearly 30 years since the launch of the HTTP protocol, nearly all HTTP traffic will be encrypted using secure HTTPS protocols hopefully providing encrypted security for business and consumer alike!
So although the future heralds a time when just about everything will use HTTPS, this can only be one tool in your defense arsenal. For more information on how activereach can help you improve your overall security posture contact us on 0845 625 9025.