Nick Sullivan

Transport Layer Security (TLS) 1.3 is almost here. The protocol that protects most of the Internet secure connections is getting the biggest ever revamp, and is losing a round-trip. We will explore differences between TLS 1.3 and previous versions in detail, focusing on the security improvements of the new protocol as well as some of the challenges we face around securely implementing new features such as 0-RTT resumption. At Cloudflare we will be the first to deploy TLS 1.3 on a wide scale, and we’ll be able to discuss the insights we gained while implementing and deploying this protocol.

Version 1.3 is the latest Transport Layer Security (TLS) protocol, which allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. TLS is the S in HTTPS. A lot has changed between 1.2 (2008) and 1.3. At the a high level, 1.3 saves a round-trip, making most connections much faster to establish. We'll see how the 1.2 handshake worked, and what had to change to enable 1-RTT handshakes. But even more importantly, the 1.3 design shifted towards putting robustness first. Anything that is not strictly necessary to the main function of TLS was removed (compression, renegotiation); choices of suboptimal security aren't offered at all (static RSA, CBC, RC4, SHA1, MD5); secure, easy to implement designs are introduced or privileged (RSA-PSS, AEAD implicit nonces, full handshake signatures, Curve25519, resumption forward secrecy). We will go into the why and how of all of these. But two major trade-offs had to be made: first, 1-RTT handshakes inherently prevent the introduction of encrypted domain names (SNI). We'll see why and what can replace them to provide similar privacy. Most interestingly, 1.3 comes with 0-RTT resumption. The catch there is that the protocol itself provides no complete protection against replay attacks. We'll unpack the problem, see what mitigations are available, what the risks and attacks are and how that requires careful API design and deployment. Finally, deployment hasn't been entirely smooth. Many servers out there turned out to be intolerant to 1.3 clients. We'll see what this causes, how it was worked around, and how downgrade protection provides defense in depth. TLS 1.3 is not in the distant future. The draft is almost finalized, and at Cloudflare we developed an open source stack in Go and support the protocol in beta for all websites. Chrome Canary and Firefox Nightly implement 1.3 clients.

Other people: Filippo Valsorda

Legend has it, the first iteration of the Secure Sockets Layer (SSL) protocol was broken in ten minutes by Phillip Hallam-Baker and Alan Schiffman during a presentation by Marc Andreesen at MIT in 1994. In the following two decades the protocol has been improved and the implementations have been strengthened, but not without a steady stream of implementation vulnerabilities and protocol design errors. From the ciphersuite rollback attack to LogJam, SSL/TLS has seen a diverse set of problems. In this talk we’ll discuss the pitfalls in designing and implementing a cryptographic protocol and lessons learned from TLS up to version 1.2.

Legend has it, the first iteration of the Secure Sockets Layer (SSL) protocol was broken in ten minutes by Phillip Hallam-Baker and Alan Schiffman during a presentation by Marc Andreesen at MIT in 1994. In the following two decades the protocol has been improved and the implementations have been strengthened, but not without a steady stream of implementation vulnerabilities and protocol design errors. From the ciphersuite rollback attack to LogJam, SSL/TLS has seen a diverse set of problems. From the HMAC-then-Encrypt vs Encrypt-then-HMAC debate to the preference for Cipher Block Chaining (CBC) modes, the 90s was an innocent time in secure protocol design. Daniel Bleichenbacher had not yet started his assault on RSA and the types of side-channel attacks that enabled BEAST and POODLE had not yet been discovered. Over the next two decades, not only were weaknesses revealed in the protocol, but implementation flaws were found in even the most widely deployed SSL/TLS libraries. By following the security-relevant changes in SSL/TLS over the years we can paint a picture of the hard lessons learned by the cryptographic community over the history of this protocol all and how we can prevent ourselves from repeating the mistakes of the past.

Two weeks after the Heartbleed bug was announced, CloudFlare patched the Heartbleed bug, created a challenge to prove the bug could be used to find private keys (uncovering a second bug in OpenSSL) and turned its entire network into a giant honeypot. This session will discuss the specific steps taken to prevent early disclosure, creating and scaling the first public vulnerability test, how the CloudFlare Heartbleed challenge showed that you can reveal private SSL keys (how a second bug in OpenSSL made this possible) the incredible impact of revoking over 100,000 certificates in a single day, and the results of our honeypot revealing the proportion of attack traffic versus research traffic.

CloudFlare was notified about Heartbleed as soon as it was discovered--ahead its public announcement--and took extreme precaution to not reveal anything about the bug. This required communicating only over secure channels, restricting the visibility of the branch from which we built the workaround, and using secure software deployment methods. After the patch was announced, there was a rush to reverse engineer the bug and create an exploit. The cloudFlare team immediately started working proof of concept, and hosted it on a website allowing others to scan for vulnerable sites. Within minutes, the original site was flooded with requests. CloudFlare’s Nick Sullivan will share this process and the feats pulled off to make sure the site could scale and provide accurate results. He will go into the numbers and technical details of the PoC and speak about its bugs and how they were found. Statistics and anonymized raw data of the 70+ millions of results will be provided, giving an overview of the patching process over time. It was clear soon after the bug was revealed that the number of servers affected by this bug was massive. What wasn’t clear was the scope of data that was vulnerable to attack. In order to determine the risk to private keys from this vulnerability, his team launched the CloudFlare Heartbleed Challenge. They set up a site that was vulnerable to the attack, added logging and created a webpage to submit a signed proof of key ownership. In less than a day, there were several successful submissions. Nick will go over the naive (but successful) strategy used to extract keys and the more advanced technique based on Coppersmith’s Method. Finally he will discuss the *second* OpenSSL bug we discovered that allowed the private key to be extracted via Heartbleed. After the exploits were in the wild, his team added logging to see who was trying to exploit this bug. Nick will reveal the results of this analysis and cross-reference the results with the IPs of the test site. These numbers give new insight into how many people were attempting to maliciously exploit this flaw versus research done to probe vulnerable sites. Once the dust settled and the team worked out the details with our CA, we revoked over 80,000 of CloudFlare’s SSL certificates. This turned into an internet scaling nightmare, resulting in a constant flood of more than 40 gigabits per second of traffic to serve overgrown certificate revocation lists. Since CloudFlare provides caching for its CA, the team bore the brunt of this traffic. Their revocation lists would have DDoSed most sites (and some certificate authorities) off the internet. Nick will talk about caching CRLs, and how the revocation system was not designed for this scale of internet flaw. In conclusion we he will summarize the many ways this coding error revealed some of the deeper flaws in the internet, and discuss ways we can move forward. Nick will share actionable advice and the security strategies used by cloud service companies on how to monitor the way companies store keys internally. Attendees will leave with actionable advice on how to better secure their own systems against the next Heartbleed and the security strategies used by cloud service companies on how to monitor the way companies store keys internally.