In October last year, researchers from Google published details about an attack on SSL v3, called POODLE. This attack worked by modifying the padding bytes of the encrypted SSL records that are used to make the records into even multiples of 8 or 16 byte blocks of data, as used by 3DES and AES encryption in the “CBC” mode, checking how the server responded, and used this to deduce the plain text of the transmitted data, one byte at a time, with just a few tries. Continue reading “The POODLE has friends”
Category: Miscellaneous
Usikker registrering av persondata i mange nettbutikker
[Apologies to my English language readers, as this article mainly concerns encryption in Norwegian online shopping sites, I decided to write it in Norwegian]
Jeg har ved at par tidligere anledninger undersøkt bruken av kryptering av norske nettbutikker, sist i 2013. Konklusjonen begge ganger har vært at kryptering er lite brukt.
I løpet av januar gjennomførte jeg en ny undersøkelse av kryptering i norske nettbutikker. I tillegg til 59 butikker jeg hadde undersøkt tidligere, inkluderte jeg denne gangen 184 nye nettbutikker fra Posten.no‘s liste over nettbutikker, totalt 243 butikker. Continue reading “Usikker registrering av persondata i mange nettbutikker”
A possible reason why many e-commerce sites do not use encryption?
If you have read my past articles, you may have noticed that I am a little annoyed by the low number of e-commerce sites using HTTPS encryption to protect their customers. While most do use encryption for payments, usually that is because they use the services of a payment processor, and because using encryption for the payment info submission pages is required by the credit card companies. As far as I can tell, very few e-commerce sites use encryption for displaying the shopping cart, collecting customer information about name and address, or the customer login, although I have an impression that larger e-commerce companies are better at this than smaller ones. Continue reading “A possible reason why many e-commerce sites do not use encryption?”
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”
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. Continue reading “What is tls-testing.tlsprober.net?”
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. Continue reading “The OpenSSL CCS vulnerability”
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. Continue reading “Heartbleed Status: Upgrading to Heartbreak”
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.
