How an SSL Flaw May Affect Your Device or Application
Guest post by Ginger Chien, Device Architect; AT&T Mobility Subscriber Engineering
This is the first of a two-part series on secure transport protocol issues that will appear on this blog. This first post addresses the SSL (Secure Sockets Layer) protocol and how mitigations of a recently discovered flaw may affect your device or application.
Secure transport of personal, financial, location, and other sensitive data to and from a trusted endpoint is an essential feature of many applications. Today, SSL and TLS (Transport Layer Security) are the most common protocols. However, as with many technologies, security protocols are under constant attack and, on a fairly regular basis, exploits are found that require patching and on occasion fundamental flaws are discovered that call for outright deprecation. This blog addresses some large and imminent technology shifts that you may want to plan for to avoid orphaning devices if those shifts occur.
First, let me scope the topics in this blog and the follow-up blog. This blog talks about SSL and TLS, the predecessor and successor secure transport protocols. These are cryptographic protocols that encrypt data for privacy and use certificates to authenticate the other endpoint.
In the second blog, I will talk in depth about the evolving secure hash algorithms that protect certificate signatures. Both of these topics are important, and failure in the operation of either the overarching secure transport protocols or the contained certificates will result in your secure protocol being unusable.
SSL and TLS Background
The terms SSL and TLS both refer to secure transport protocols, but for historical reasons SSL is often used in reference to both and is sometimes misapplied (as in “SSL certificates,” where the certificates themselves have no direct relationship to SSL at all because they can be used with protocols other than SSL). SSL/TLS are the most widely used security protocols over the Internet and they allow the endpoints of a secure connection to negotiate encryption ciphers for privacy and to authenticate the identity of the other end using public key infrastructure (PKI) technology and X.509 certificates.
SSL is an old protocol with the original versions created by Netscape in the mid-1990s. Netscape released SSL 3.0 in 1996 to address flaws in the early versions and until recently, SSL 3.0 has been widely supported. A fundamentally improved protocol called TLS 1.0 was released in 1999 to provide stronger negotiable alternatives to SSL. Subsequent versions through TLS 1.2 (2008) are available in most protocol stacks.
In any secure socket or HTTPS connection, the endpoints advertise their supported SSL or TLS protocol versions and follow some rules to agree on a mutually agreeable strongest version. As a developer you are generally unaware of what protocol is agreed upon … it either connects or it doesn’t connect (you have an intersection of protocol versions or you don’t). When it connects, you also generally don’t question the wisdom of the supported range of protocols and versions on the client and server endpoints.
Up until recently, SSL 3.0 was commonly supported and at least some versions of TLS were supported in nearly all protocol stacks as well. However, SSL 3.0 has suffered a serious blow.
In October 2014, Google researchers revealed the POODLE attack (footnote 1). The “Padding Oracle On Downgraded Legacy Encryption” attack is a man-in-the-middle attack that interferes with SSL and TLS negotiation. By forcing renegotiations that repeatedly send the same secret such as a password encrypted in different ways using weak SSL 3.0 encryption, the different patterns eventually allow the secret to be extracted. Protecting against this attack involves some pretty strong remedies:
- Disabling SSL 3.0 entirely on one or both endpoints.
- Disabling the vulnerable CBC-mode ciphers.
- Activating the TLS_FALLBACK_SCSV option in the stack, which prevents it from trying a lower protocol version when a preferred higher version is advertised by the other endpoint.
As a typical application developer, you may have little control over any of these options. If you are developing deeply embedded software for a carrier or OEM, or if you are engineering an entire IoT device, you may have more control. In either case, there are fewer reasons to continue to use SSL 3.0.
If There’s One Thing That’s Constant, It’s Change
In terms of security strength, you can think of the progression of existing protocol versions this way, where each higher protocol and version adds new features and resolves weaknesses of the previous versions:
SSL 2.0 — SSL 3.0 — TLS 1.0 — TLS 1.1 — TLS 1.2
In any recent protocol stack, SSL 2.0 should never have been supported, and an average protocol stack might have supported:
SSL 3.0 — TLS 1.0 — TLS 1.1
As of today, mitigation of SSL 3.0 is in progress and you may see this offer from an endpoint that’s more up to date:
TLS 1.0 — TLS 1.1 — TLS 1.2
And in a few years, a new version of TLS is likely, and TLS 1.0 might be found to have a flaw that causes it to be deprecated, and you may encounter stacks that look like this:
TLS 1.1 — TLS 1.2 — TLS 1.3
As a general rule, you do not want a client-side stack that only supports SSL 3.0, especially if your application is trying to connect to random servers whose configurations you can’t control. You might be able to get away with SSL 3.0 if your security teams don’t object and if you have full control over your server. You are in the best position to understand the needs of your application and security team, but I would suggest that, at a minimum, you explore the implementation of a modern and upgradeable protocol stack to help minimize exposure.
Am I Safe if I’m Running on a Modern Device?
It depends on how your application or client accesses the protocol stack. If you are using native platform services on a smartphone, you probably have a stack that is current, full-featured, and updateable with security patches.
If you have a very customized or deliberately compartmentalized application, it may have its own private stack implementation that may have support for fewer SSL and TLS protocol versions or may support fewer options. The robustness over time and in the face of threats of such a solution depends on what that application needs to talk to and the threat environment through which the data passes.
In Summary: What to Consider
Consider the servers or far end systems to which your device or application connects. Given the changes underway to SSL 3.0 implementations, can you predict what you will be connecting to?
Consider the implementation of your device or application protocol stack. Is it modern and full-featured? Or is it built using an old protocol stack code base that has limited SSL and TLS version support?
In the end, it comes down to whether or not you can guarantee an intersection of protocol versions between your device/application and the far end systems. Ideally, you want that intersection to include the latest and greatest TLS 1.2 and at least for the time being, TLS 1.1 and TLS 1.0 as well for maximum compatibility. Supporting at least one standby protocol version gives you the best chance of continued and uninterrupted connectivity if a server disables a version on its side due to a new security flaw. And SSL 3.0 should be disabled or avoided unless you can really justify its need.
And finally, consider whether your device/application supports software upgrades of the protocol stack…because, you know, things change.
In the next article, I’ll dig deeper into the subject of certificates. We’re looking at some similarly disruptive changes in the coming year or so with the retirement of the SHA-1 hash algorithm that is used in virtually all certificates today.