Even their names inspire fear. Heartbleed. Shellshock. Granted, the third member of 2014’s critical vulnerability triumvirate — POODLE — sounds toothless by comparison, but the cybersecurity professionals impacted by any or all of these large-scale attacks know otherwise, and probably have the scars to prove it.
At Sage Data Security’s 2015 Cybercrime Symposium, Akamai CSO Andy Ellis called out the three CVs in his presentation — aptly titled The Long Road to a Secure Web — but reminded attendees these were but a few among multitudes. “Over the last 18 months, we’ve watched as the Internet has been broken repeatedly,” he said.
Each of the CVs that Ellis cited exploited a different server-side flaw, causing an astounding amount of damage to an astounding number of businesses. What’s more, two of the flaws used to breach defenses involved industry-standard security protocols developed to encrypt and protect data flowing between user devices and websites.
Given the sheer size and scope of these attacks, it’s not surprising that the security industry has been asking itself some serious questions. In this case, one might be: “How far have we traveled on this long road, and what will the destination look like?”
“We’d like to get to HTTPS Everywhere,’” said Ellis. “But today we’re nowhere near that, and we’re not going to be for a while.” However, he added, “Maybe there’s a path for getting there.”
Led by browser developers who’ve basically orchestrated the move, stakeholders have made big strides forward in the past 18 months, according to Ellis. Also flexing its considerable muscle is Facebook, which now requires embedded traffic to come in over HTTPS. That’s driving social media ad creators and app developers to adopt it.
The Journey So Far
Securing an ecosystem as intricate as the web will be a painstaking, iterative process. It will likely proceed in fits and starts, and require industry partners to continuously chase a moving target. Here are a few building blocks — as well as some roadblocks — that will be in play in their search for the secure web:
- HTTP. The standard protocol for transmitting web traffic, HTTP runs at the application layer of the TCP/IP stack, and isn’t encrypted.
- TLS. TLS picked up where its predecessor, SSL, left off. The protocol secures communications between browsers and web servers. It encrypts data, ensures data integrity, and helps authenticate connected entities encryption. TLS sits beneath HTTP in the TCP/IP stack’s application layer. While many websites continue to use SSL, it’s no longer a trusted option for securing communications.
- HTTPS, aka HTTP over TLS. Many mistakenly conflate HTTPS with TLS, but, said Ellis, they’re not synonymous. HTTP, layered on TLS, combine to become the HTTPS protocol. It uses HTTP to secure communications across networks. Parties interact over a connection that leverages TLS encryption.
- SNI. Server Name Indication ensures that a browser connecting to a server requests its certificate. “Unfortunately, SNI didn’t not show up until point versions of TLS were released,” said Ellis. “So, any browser that doesn’t support modern TLS can't talk SNI.”
- Certificate Authorities (CAs). Who certifies the validity of a certificate? That task falls to CAs, third parties whose job it is to issue certificates. As part of this process, they’re charged with verifying the identity of the person or entity requesting the certificate. However, any public or private entity can own a certificate authority, and the quality of oversight varies greatly. In response to growing demand for visibility into their practices, CA owners must now comply with “certificate transparency” policies so that interested parties can review any certificate the CA issues.
- HPKP. HTTP public key pinning improves certificate authority oversight through preemptive measures. When a client device attempts to access a website, HPKP passes host and response headers to the web server and lets it determine which certificates apply.
What’s the Hold-up?
Among the challenges facing the HTTPS Everywhere movement, and hampering widespread adoption of SNI, are all the legacy systems still in operation in various corners of most organizations — Windows XP, Windows Server 2003, IE6 and various applications that didn’t upgrade to new versions, despite end-of-support deadlines.
“It’s a problem, because web servers can’t distinguish between browsers that don’t talk SNI and those that do in time to decide whether to connect,” said Ellis. “We’re stuck in a situation where the last clients to retire are holding back the clients moving forward.”
The need for organizations to migrate off Windows XP when it hit its EOS deadline spurred a 5% increase in SNI-enabled client deployments. Today, about 90% of clients in operation support SNI.
Ironically, Heartbleed and other CVs played a part in advancing cybersecurity efforts. “Heartbleed, Shellshock, and Poodle made organizations realize that they had to stop supporting ancient systems,” Ellis said. “Today, the minute old protocols like SSLB2 reach their EOS date, we'll kick them off the Internet.”
Such actions will have the backing of various protocols as new versions emerge. That outdated IT model — where organizations continue to allow legacy clients that no longer receive security updates to run alongside modern systems — is going away, said Ellis.
“Once TLS 1.3 launches, we’ll be operating in a world where you can deploy clients that support TLS 1.3, or you can support your ancient legacy clients, but you won’t be able to do both,” he said.
This is the 9th and final article in our weekly series presenting key takeaways from Sage Data Security’s 2015 CyberCrime Symposium, held November 5-6, 2015. If you missed the filled-to-capacity event, “Collaboration & Information-Sharing,” you can read the entire series here.