An extraordinary vulnerability affecting certificate validation in Microsoft Windows was disclosed last week by the NSA. The most dangerous aspect of the flaw allows attackers to impersonate any HTTPS server on the Internet, leading some to characterize it as one of the most critical Windows vulnerabilities ever. Is this overstated? Let’s think about it.
You know that little lock in the browser bar? It’s meaningless. The flaw in the certificate validation mechanism means that an attacker can supply a forged X.509 certificate and trick your computer into thinking it’s authentic. The confidentiality of the data between you and, say, your banking application or web VPN? Gone, assuming that the attacker forging the certificate can insert themselves between you and your destination service (a.k.a. “man in the middle”). I’d say that the problem is definitely not overstated.
As the project to patch every Windows computer on the face of the earth begins, many online apps and services that secure customer network traffic with Transport Layer Security (TLS) are grappling with fact that there’s nothing they can do to ensure that these connections are secure going forward. Unfortunately, the security of these connections depends entirely on whether their customers patch their systems, not whether the service patches its own systems. Let’s hope everyone has their auto-update on.
We at Wickr have been talking about Zero Trust design principles for some time now. In our Zero Trust white paper, we describe how Wickr’s design assumes that nothing can be trusted along the communication path between a sender and receiver. Accordingly, we don’t rely on TLS for message security. In fact, we assume it’s broken.
That’s because, from a Zero Trust perspective, TLS is a terrible choice. Even without an epic Windows vulnerability in the mix, TLS still relies on many hundreds of domain registrars around the world to issue certificates accurately and in good faith. A ton can go wrong with that. Even in a perfect implementation, it secures only a portion of the network path between a message sender and receiver, leaving message content exposed at other critical points along the way.
I’m kind of a worrywart when vulnerabilities are disclosed. I always think of the time before it went public, when someone somewhere may have been using it against who knows who to gain who knows what sort of advantage. I think of the victory that attacker would feel when exploiting this particular vulnerability to obtain data related to one of the thousands of online services out there that are considered “secure” simply because their service address begins with https://. Then I think of the disappointment that attacker would feel when exploiting it only to find that their victim’s Wickr communications are still secure. That disappointment makes me smile.