Attack of the POODLEs

Three weeks ago a group of researchers from Google announced an attack against the SSL v3 protocol (the ancestor of the TLS 1.x protocol) called POODLE (a stylish abbreviation of “Padding Oracle On Downgraded Legacy Encryption”). This attack is similar to the BEAST attack that was revealed a few years ago, and one of the researchers that found the POODLE attack was part of the team that found BEAST.

POODLE is able to quickly discover the content of a HTTPS request, such as a session cookie, but only if the connection is using the SSL v3 protocol, a version of SSL/TLS that became obsolete with the introduction of TLS 1.0 in 1999. As almost all (>99%) secure web servers now support at least TLS 1.0 (which is not vulnerable to the attack, provided the server is correctly implemented), it might sound like this attack is not very useful. Unfortunately, that is not so. (more…)

What is tls-testing.tlsprober.net?

Executive summary: The TLS Prober is a tool that gathers information and statistics about the state of the SSL/TLS protocol security features and vulnerabilities across the internet. It does nothing that will harm your server.

The TLS Prober is a tool I developed while I worked I worked at Opera Software, originally to track the progress of the TLS Renego problem, and which I was allowed to take with me when I left Opera in early 2013. It is primarily used to scan a set of 23 million hostnames, most of the names derived from Alexa top million domain names, resulting in tests of about 500000 unique servers, for their support of SSL and TLS features, as well as checking for various interoperability issues and vulnerabilities.

Similar tools are also in use by others, such as the Qualys SSL Labs prober. (more…)

The OpenSSL CCS vulnerability

Last week, news arrived about a new vulnerability in OpenSSL, which affected all releases of the library. This new vulnerability, frequently referred to as the CCS vulnerability, is a Man In the Middle (MITM) vulnerability, allowing an attacker to listen in on, or modify data on a connection by tricking the client and server to set up their connection using predictable encryption keys. (more…)

Heartbleed Status: Upgrading to Heartbreak

(Update: A number of references to this article have incorrectly referred to me a working for Opera Software. Please note that I left Opera Software more than a year ago, and that I now work for Vivaldi Technologies AS)

Update May 12: After closer investigation together with F5, it seems that, due to an issue with the network connection of the prober the test used to detect F5 BigIP server showed higher numbers than it should have, and the numbers of such servers therefore got very inflated for the scans that were run in the past month. This means that the BigIP related information and conclusions are not correct, and I have therefore moved down and struck out the section regarding BigIP servers. My apologies to F5 and their customers for this mistake. (more…)

The Heartbleed vulnerability (or why you should change your Vivaldi.net password)

A few days ago a group of researchers revealed that they had discovered a serious vulnerability in OpenSSL 1.0.1, an implementation of the Transport Layer Security protocol (TLS, or SSL) which they called “Heartbleed“.

This vulnerability is very serious and will take its place among other serious TLS-related vulnerabilities of the past few years, such as the Renego problem, BEAST, CRIME and others, and is probably even more severe than any of them, particularly since this problem does not require working with a complex setup through the user’s browser, and the scope of the attack affect all users, not specific users. Some, like Bruce Schneier, are using the word “catastrophic” and this label may actually be warranted in this case.

Heartbleed’s severity is due to the fact that an attacker, exploiting a problem in OpenSSL’s implementation of a TLS protocol feature called the Heartbeat extension, developed as a lightweight way to check if a secure server is still alive, can get 64 KB of raw memory from the vulnerable server. This memory can contain passwords, or other sensitive user data, but worst of all: it can contain the private encryption keys used to secure all transactions with the server, meaning that an attacker can pretend to be the site and perform a Man In the Middle attack against the site and its users. The problem have been present in OpenSSL for two years, and there is no way to know if it have previously been discovered and used by others.

Consequences

There have been a lot of writing in various news sites about this issue, and while some have moderated their stories after a while, many still have some exaggerations as well as some very bad advice mixed with good advice.

First of all, this issue does not affect 65-70% of all websites, 17% is probably more accurate. It is accurate that about 65-70% of web sites use OpenSSL, but most are still using older versions that are not vulnerable to this issue. Netcraft estimates the number of affected servers at 17%. This sounds reasonable, as my own scans indicates that 23% of TLS servers that I have scanned
support TLS 1.2, not all of which are using OpenSSL, which was also added in the vulnerable versions of OpenSSL.

As the vulnerability also may have exposed user’s passwords, a number of articles recommends changing passwords, in part prompted by statements from computer security experts and government agencies, some of them saying something like “Change all your passwords RIGHT NOW!!!”. Unfortunately, if you do so without doing a couple of checks first, that could be almost the worst thing you can do. Why? This is why: if the website has not been updated and secured before you change the password, then you might just be handing the attackers your new password on a silver platter. Before changing your password, make sure, by asking them, that the site have secured its servers. Otherwise, you may have changed one unsecure password for another one, and will have to repeat the process when the site have been secured.

Also, please note that some websites may send emails about this issue, and that scammers are sure to follow up with phishing email  using Hearthbleed password updates as the bait. Never click on links in such emails! Use your normal URL for accessing the site, verify that the site has been secured (by asking), then change the password using the standard methods for doing that, in the account preferences.

What about Vivaldi.net?

Like many sites with a modern Linux based server park, Vivaldi.net was using one of the vulnerable versions of OpenSSL, as was our distribution service, CloudFlare.

To fix the problem on our servers, we did not just have to upgrade the servers to use the patched version, we also had to create new private encryption keys for our servers and obtain new SSL/TLS certificates for them, and revoke the old certificates. Our servers are now secure against this problem.

We, and all other web sites affected by the problem, have to go that far, since the vulnerability may have exposed our private keys, which means they cannot be trusted anymore.

However, be aware there may be a couple of side effects for clients due to the changed certificates. When we changed the certificates we also upgraded them to being signed by the more secure SHA-256 method. This also means that the certificates are signed by a new intermediate certificate, but the web and email servers are sending this certificate, but it appears that some clients have problems, either with the certificates or by not understanding SHA-256. In such cases an upgrade of the client may be necessary.

Unfortunately, the process of recovering from this vulnerability is not over yet. Now it is your turn.

We do not know, and probably will never know, whether or not somebody attacked our servers using this vulnerability before we were able to patch the servers and replace the certificates. If they did, then the passwords of all our users may have been compromised, and this means that you should change your password for Vivaldi.net as soon as possible.

Vivaldi.net now showing EV-green in browsers

Friday evening (20 December) those who keep an eye on the browser UI would have observed a small but significant change take effect at Vivaldi.net: The browser turned on the Extended Validation “Green Bar” for us, indicating that the identity of our website was now better assured than it has been, though the encryption is just as good as before.

Previously, while we were developing the site and during the first days of it being live, we used a Domain Validated SSL/TLS certificate for our sites that indicated that we had control over the domain, but not who we are. This is a useful level of web site identity verification for smaller sites that only need to present information securely and without any major collection of personal information. 

For users of a web site that collects or manages personal and payment information, it is not just important to know that the people managing the web site are in control of the domain. It is even more important to know, or be able find out, who they are, legally speaking, in case there is a problem.

This need for verifiable identity information was why a group of Certificate Authorities, such as Verisign and Entrust, and Browsers, such as Microsoft, Mozilla and Opera (including yours truly), gathered to found the CA/Browser Forum so that we could define what eventually became the Extended Validation (EV) Guidelines for CAs, and the associated “Green Bar” in browsers.

When Jon decided to start the Vivaldi.net social web site project, one of my suggestions was to have an encrypted site. Given recent revelations (e.g., NSA) it is now, or should be, unthinkable to have a social web site that is unencrypted. While many sites have been using a hybrid approach where the login, account management, and sometimes authoring, is encrypted, there are just too many ways to sniff information that way, so the whole site needs to be encrypted. Another of my suggestions was to use EV certificates on the sites, to provide better identity information and assurances to our users.

While I would have wished to have unveiled Vivaldi.net on Wednesday with an EV certificate, the process of obtaining one was intentionally designed to include a lot of paperwork that has to be completed before the certificate can be issued, and that paperwork was not completed by our CA, GlobalSign, until early evening Friday.

So, go ahead and enjoy Vivaldi.net, assured that it is Jon’s company, Vivaldi Technologies AS, that is operating it.

I’m still a techie, not a nettie

Welcome to a my new home on the Web.

After I left Opera a year ago, I considered moving my (old) home page to a new location, but did not find a good location to host it.

Moving to a new location became a bit more urgent when Opera announced their decision to  shut down MyOpera in a couple of months.

Fortunately, my new old boss, Jon von Tetzchner, decided that with MyOpera shutting down, he would provide a new home for all the people made “homeless” by the shutdown. The new site, Vivaldi.net, went live as a  beta version yesterday, and I have now started the migration here.

The small print: Opinions stated here are my own, and do not necessarily represent my employer’s views. Opinions are subject to change without notice, in particular when I find (or am pointed to) better information, unless I decide to be stubborn. Articles may contain spelling mitsakes, errors grammatical, or other mistakes; in such cases the correct meaning is what I meant to write, not what is in the text; when in doubt, ask.