There's a critical vulnerability in some versions of the widely used OpenSSL code library that in some cases allows attackers to impersonate cryptographically protected websites, e-mail servers, and virtual private networks, according to an advisory issued early Thursday morning.

The bug allows attackers to force vulnerable end-user applications into treating an invalid certificate as a legitimate transport layer security (TLS) or secure sockets layer (SSL) credential. As a result, adversaries with the ability to monitor a connection between the end user and trusted server could intercept or even modify data passing between them. The vulnerability resides in OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n, and 1.0.1o. The flaw appears to have been added earlier this year, based on this Github contribution dated January 27. It wasn't introduced into the actual OpenSSL versions until last month, however.

The flaw has the potential to be extremely serious because in certain cases it makes it trivial to bypass the most popular—and in many cases, the only—form of encryption and cryptographic authentication available for websites, e-mail servers, and virtual private networks. The bug allows attackers to bypass certain checks that are supposed to be carried out when an end-user app is establishing an encrypted session with a server. As a result, the attacker can make an invalid certificate appear as if it belongs to a trusted certificate authority and issue forged certificates for any website.

"The advisory makes it look pretty bad," Matt Green, a professor specializing in cryptography at Johns Hopkins University, told Ars. "If you can look like a CA, then you can issue a certificate for any site."

Silver lining

Fortunately, the flaw can be exploited only in limited cases, specifically only when browsers or other types of end-user applications use a vulnerable version of OpenSSL for certificate verification. By default, Google Chrome, Mozilla Firefox, Microsoft Internet explorer, and Apple iOS use Boring SSL, Network Security Services (and more recently libPKIX), SChannel, and Secure Transport respectively for such validation. There's no indication that any of those alternate code libraries contain the same flaw, meaning the vulnerability most likely can't be exploited against people using those programs or operating system. BoringSSL developers have confirmed it's not affected. Android handsets, meanwhile, use OpenSSL and BoringSSL depending on the version, but according to Google cryptography engineer Adam Langley, all versions remain unaffected.

Still, individual apps often use their own code for verifying certificates. That means certain apps may still be vulnerable even when running on an operating system that by default uses an unaffected crypto library. It will take days or weeks for vulnerable apps to be identified and fixed. In the meantime, readers should rely on browsers whenever possible until they receive verification that e-mail, VPN, and other types of apps are safe.

As critical as the flaw is, its effects are greatly limited because it was discovered before it made its way into mainstream applications. That's a testament to recent industrywide efforts to secure the widely used code base. The catastrophic Heartbleed vulnerability, by contrast, resided in production versions of OpenSSL for more than two years. The bug reported Thursday was identified by Langley, the Google cryptography engineer, and David Benjamin, a developer with the BoringSSL project. This post will be updated as more details become available.