Not out of the woods yet: There are more POODLEs

As I wrote in my previous article about this, in October a group of Google security researchers had discovered a problem, called POODLE, in SSL v3 that in combination with another issue, browsers’ automatic fallback to older TLS and SSL versions, allowed an attacker to quickly break the encryption of sensitive content, like cookies.

The main mitigating methods for this problem are disabling SSL v3 support, both server side (now down to 66.2%, but slowing down) and in the client, and to limit the automatic fallback, either by not falling back to SSL v3 (which is now implemented by several browsers), or by a new method called TLS_FALLBACK_SCSV (introduced by Google Chrome and others). Continue reading “Not out of the woods yet: There are more POODLEs”

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. Continue reading “Attack of the POODLEs”

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.