You may have heard of the “Poodle” vulnerability in SSL, which allows the plaintext of secure connections to be calculated by a network attacker.

This vulnerability was discovered recently by Google engineers; here’s how it works:

• Secure Internet connections used to be implemented with SSL 3.0, which is actually a pretty old protocol now. (About 18 years old, in fact, which means it dates back to the Netscape era 🙂

• Over the years, SSL 3.0 was implemented by everyone who produced Web servers: e.g. Microsoft, Netscape, Apache, etc.

• SSL 3.0 has since been supplanted with Transport Layer Security (TLS), which also comes in several flavors — TLS v1, v1.1 and v.1.2

• And SSL was around for such a long time, everyone knew it worked. With TLS, however, bugs are sometimes found in different Web servers, depending upon who is producing (and maintaining) a particular brand of Web server.

• In order to get around potential problems with the way a particular Web server had implemented TLS, browser clients (i.e. software that runs in a browser, like Kerika does) will also, very often, try to connect to the Web server using with SSL 3.0 as a fallback protocol.

Well, the good folks at Google found that SSL has a very fundamental vulnerability in it, that’s inherent in the protocol and cannot be patched: in an example attack called Padding Oracle On Downgraded Legacy Encryption (POODLE), an attacker can steal “secure” HTTP cookies or other bearer tokens such as HTTP Authorization header contents.

This problem is basically unfixable with SSL 3.0 because it uses RC4 ciphers for encryption, and RC4 is pretty darn old: it dates back to 1987!

(And, yet, according to Microsoft, even last year over 40% of Web connections were using RC4.)

The only way to secure against this vulnerability is to not allow SSL 3.0 as a fallback method for connecting to your Web server.

And that’s what Kerika does: we only support TLS connections.

Doing our bit to keep the Internet safe… 🙂