Secure browsing like it's 1995
By Audun Mathias Øygardamoygardopera. Thursday, March 17, 2011 1:41:47 PM
As those who follow us might know, we started our "TLS prober", which probes the TLS/SSL capabilities of servers around the world, about a year ago
. For background, the TLS/SSL protocol is the protocol behind secure connections, mostly known by the "Secure" indicator in the address field, and this protocol ensures that no one can listen in on whatever you're doing online. This is especially important if you're using, for instance, banking sites. About a year and a half ago, a hole in this protocol was discovered, which means that the protocol is no longer completely secure. It has been demonstrated that this hole could be used to steal Twitter log-in information, even though the user was on a secure connection. Similar methods *could* be used to eavesdrop and steal information from, for instance, your online bank account. Fortunately, a fix has already been made, but it needs to be installed on all servers (that offer the TLS/SSL protocol) worldwide. A daunting task for sure! We created the "TLS prober" mainly to monitor how many of the servers have implemented the fix (AKA the "Renegotiation Indication Extension") so far. This has also enabled us to check for other issues around specific configurations of the secure servers, such as version support, standards compliance, ciphersuites and more. Up until recently, we didn't check for SSL 2.0 – the oldest, outdated, and insecure version of the protocol, since we didn't really assume that support for this was a big problem anymore. To our dismay, however, the amount of servers still having SSL 2.0 enabled was *pretty big*.
. For background, the TLS/SSL protocol is the protocol behind secure connections, mostly known by the "Secure" indicator in the address field, and this protocol ensures that no one can listen in on whatever you're doing online. This is especially important if you're using, for instance, banking sites. About a year and a half ago, a hole in this protocol was discovered, which means that the protocol is no longer completely secure. It has been demonstrated that this hole could be used to steal Twitter log-in information, even though the user was on a secure connection. Similar methods *could* be used to eavesdrop and steal information from, for instance, your online bank account. Fortunately, a fix has already been made, but it needs to be installed on all servers (that offer the TLS/SSL protocol) worldwide. A daunting task for sure! We created the "TLS prober" mainly to monitor how many of the servers have implemented the fix (AKA the "Renegotiation Indication Extension") so far. This has also enabled us to check for other issues around specific configurations of the secure servers, such as version support, standards compliance, ciphersuites and more. Up until recently, we didn't check for SSL 2.0 – the oldest, outdated, and insecure version of the protocol, since we didn't really assume that support for this was a big problem anymore. To our dismay, however, the amount of servers still having SSL 2.0 enabled was *pretty big*.
For background, SSL 2.0 as a security protocol was obsolete already in 1996. That's fifteen (15) years ago. Opera stopped supporting SSL 2.0 in 9.0 and physically removed the code for it from 9.5. Internet Explorer, Firefox and Chrome still support it, but you'll have to enable it manually, and both Firefox and Chrome have hidden the options for enabling it. SSL 2.0 is simply not a secure protocol anymore. Granted, some of the servers supporting SSL 2.0 will give a friendly warning that you shouldn't use SSL 2.0. Still, wouldn't it be easier to just not support SSL 2.0 in the first place?
Presumably focusing on exactly this issue, IETF just released an RFC that prohibits TLS clients and servers from offering a SSL 2.0 connection for backwards compatibility.
Another problem we discovered is that most sites still support weak ciphers, that is, ciphers with 40 or 56 bits encryption. Weak ciphers are also a remnant of the nineties and were removed from all browsers around 2000/2001, when it was proven that the encryption was possible to break within 24 hours with the right hardware. With today's hardware it would probably be feasible to break this encryption within minutes.
The only real argument in favor of servers still supporting SSL 2.0 or weak ciphers is compatibility with older browsers. However, the only browsers that need this kind of support are browsers that only support SSL 2.0 or weak ciphers. This effectively means, for SSL 2.0, browsers released before 1996 (Netscape Navigator 2.x, Internet Explorer 2.x and earlier) or, for weak ciphers, browsers released before 2000 (Netscape Navigator 4.7, Internet Explorer 5.0 and earlier). Supposing, by any chance, that a user is actually using such an old browser, I think this user would have some other problems as well; this was after all before the support of standardized JavaScript and CSS ...

There are no known vulnerabilities if sites support weak ciphers or SSL 2.0 in addition to SSL 3.0 and TLS 1.x, as long as the client only supports strong ciphers and SSL 3.0 or higher. It may create possibilities for downgrade attacks, however, for instance if users have misconfigured their browser.
To be fair, the reason that sites still support old standards might be default configurations of the servers, not a conscious choice by those setting up the sites. Isn't it time to disable it by default in Apache webservers, just to mention one?
---
In other news, while we could not see any servers that only supported SSL 2.0, we did see a couple of servers that only supported SSL 3.0, altogether 1% of all secure servers. Please note that we reported a higher number, 1.6%, a few months ago. This was due to an error in the way we tested for TLS 1.0—some servers chose SSL 3.0 instead. The proper number is and was 1%. Many of these sites appear to be outdated or abandoned, but some seem to be up and running. We even saw a few banks, as usual.
Time to update those servers, folks?---
From old standards to new standards, here's the status for renegotiation patching as of this week:
We've reached 50% (or actually 50.8%), and most major server vendors have now released patches with the Renegotiation Indication Extension.
The breakdown per vendors looks as follows:
The vendors we know of that have not released patches yet are mostly frontends, such as SSL accelerators and load-balancers. One of the few we know the name of, because such frontends seldom identify themselves, is F5/Big-IP. We also had a look at which sites were patched. We expected the well-known sites (Alexa top 100) to be mostly patched by now, while many smaller sites, which might be less maintained, were not patched. However, large sites seem just as likely to not be patched! In fact, several well-known sites, such as Facebook and Yahoo!, have not yet patched their servers. Some banking sites, as reported by Kai Engert, haven't even disabled renegotiation, and are, therefore, fully vulnerable to an MITM attack! It seems there is still some way to go ...

In summary:
- SSL 2.0 is still supported on around 63% of TLS/SSL servers, even though SSL 2.0 is an insecure and outdated encryption protocol.
- Weak ciphers are still supported on around 63.8% of TLS/SSL servers, even though weak ciphers are relatively easy to crack.
- 50% of all TLS/SSL servers have now implemented the Renegotiation Indication Extension which patches the TLS Renegotiation vulnerability reported over a year ago.
Any reasons you can come up with for still supporting SSL 2.0 or weak ciphers? Is it time for browsers to stop supporting SSL 3.0? Anything you'd like us to check on the status of the SSL/TLS servers worldwide? Let us know in the comments!








Charles SchlossChas4 # Wednesday, March 30, 2011 1:21:24 PM
XenoAntaresXAntares # Wednesday, March 30, 2011 2:08:58 PM
Charles SchlossChas4 # Wednesday, March 30, 2011 3:37:08 PM
Yngve Nysæter Pettersenyngve # Wednesday, March 30, 2011 5:52:27 PM
Alexandre Willianalexandrewillian72 # Wednesday, March 30, 2011 5:53:11 PM
Cutting Spoonhellspork # Wednesday, March 30, 2011 6:15:12 PM
Charles SchlossChas4 # Thursday, March 31, 2011 12:18:38 AM
They keep asking me to use online and you wonder why I don't, plus they block Opera as a "business decision" & even block Opera Mini
Cutting Spoonhellspork # Thursday, March 31, 2011 3:17:03 AM
Charles SchlossChas4 # Thursday, March 31, 2011 3:38:08 AM
Originally posted by hellspork:
I think tho they block it because the user agent has Opera in it, I was told on the phone that it was a business decision to block Opera
ouzowtfouzoWTF # Thursday, March 31, 2011 9:14:58 AM
I checked some german online banking pages. These are my results (ordered by TLS renegotiation support):
Hypovereinsbank
https://my.hypovereinsbank.de/
Seems to support TSL renegotiation.
DKB
https://banking.dkb.de/dkb/
Seems to support TSL renegotiation.
Targobank
https://www.targobank.de/de/online-banking/login.cgi
Seems to support TSL renegotiation.
Santander
https://securebanking.santander.de/
Seems to support TSL renegotiation.
Bankhaus Neelmeyer
https://www.bv-activebanking.de/neelmeyer/loginFormAction.do
Seems to support TSL renegotiation.
Deutsche Bank
https://meine.deutsche-bank.de/trxm/db/
Does not support TLS renegotiation.
Commerzbank
https://www.commerzbank-privat.de/
Opera first indicated that the page is only "secure" (no certificate) but when I go back and then forward in history, the page gets "trusted". However TLS renegotiation is not supported.
https://www.commerzbanking.de/
Insecure connection. Opera says that the server attempted to apply security measures, but failed.
Postbank
https://banking.postbank.de/app/welcome.do
Does not support TLS renegotiation.
Norisbank
https://meine.norisbank.de/trxm/noris/
Does not support TLS renegotiation.
ING DiBa
https://banking.ing-diba.de/webkunden/goLogin.do
Does not support TLS renegotiation.
Comdirect
https://kunde.comdirect.de/lp/wt/login
Does not support TLS renegotiation.
All in all I think this is not a very good result. Especially for the big banks like Deutsche Bank, Commerzbank and Postbank.
I dont want to contact all of them, but the word should be spread that some of them are not very secure.
larsen25 # Thursday, March 31, 2011 2:24:05 PM
https://online-banking.volkswagenbank.de/PBODEFE/Login/LoginPage.aspx?brand=vw
Does not support TLS renegotiation.
GE Capital
https://banking.gecapital.de/p14pepe/entry?rzid=XC&rzbk=3895
Does not support TLS renegotiation.
larsen25 # Thursday, March 31, 2011 2:29:16 PM
ouzowtfouzoWTF # Thursday, March 31, 2011 2:49:41 PM
Yngve Nysæter Pettersenyngve # Thursday, March 31, 2011 3:12:48 PM
What the Renego patching is about is adding support for the "TLS Renegotiation Indication Extension" (RFC 5746)
ouzowtfouzoWTF # Thursday, March 31, 2011 4:42:58 PM
Originally posted by yngve:
Ok, so the pages which support it are not automatically saver than the ones that doesnt. I understand. Is there a way to check if they have it enabled?
Yngve Nysæter Pettersenyngve # Thursday, March 31, 2011 6:01:23 PM
Originally posted by ouzoWTF:
TLS Connection Renegotiation?
It is possible to attempt client initiated renegotiation, but no browser client supports that (libraries usually do), so you would have to have specially designed implementation.
Server initiated renegotiation occurs when the server asks the client to start renegotiation, which usually happens due to some special URL being visited.
If either of these can occur for a site that has not patched the Renego vulnerability (and you can find some of those that allow client initiated renegotiation listed at Kai's site) then the MITM request injection attack can be staged against that site (impact depends on what attacks the site actually "support"), and there is no way the client can tell that it is happening. At most you will see some post-event information in the loaded page, but then it may be too late.
ouzowtfouzoWTF # Thursday, March 31, 2011 6:37:54 PM
Originally posted by yngve:
Too bad there's not an easier way to check. Thanks for that information.
Cutting Spoonhellspork # Saturday, April 2, 2011 4:58:41 PM
A problem with a few sites though, is that they block desktop Opera because they think it is a mobile browser. As though there weren't millions of sites that can figure this out.
BernG # Monday, April 11, 2011 11:38:35 PM
Actually, I couldn't care less if its "trusted" vs "secure."
BernG # Monday, April 11, 2011 11:41:55 PM
Cutting Spoonhellspork # Tuesday, April 12, 2011 7:52:07 AM
MehrdadMehrdad2011 # Friday, April 22, 2011 7:53:55 PM
Is this a security issue in opera 11.10, all of these website, or the country and the ISP I am conecting the Internet through them?
MehrdadMehrdad2011 # Friday, April 22, 2011 7:55:23 PM
Cutting Spoonhellspork # Friday, April 22, 2011 8:16:50 PM
I can't say this has happened to me, at least. What version of what Operating System are you using?
Yngve Nysæter Pettersenyngve # Friday, April 22, 2011 8:18:15 PM
It would be a potential security issue if Opera showed something as secure when it isn't, NOT when it shows something as unsecure even though it may be secure.
A way to determine the cause of some issues is to load a single element from the server (or servers), such as a raw CSS, Image or JS file, that does not include any other content from the site. This will tend to limit the possible sources of the problem, and can be used to narrow down the problem step by step.
Another way is to install a separate test installation of Opera, to make sure it does not have to do with something in your configuration; testing with a separate PC from same or different network is also a good idea if necessary.
You might also want to inspect the site certificates to make sure they are correct.
If only you are seeing it, and considering that I have not seen a flood of reports that is IMO likely, it is very likely caused by something close to you, maybe your ISP, maybe your PC; Extensions have been implicated in such problems before.
MehrdadMehrdad2011 # Saturday, April 23, 2011 7:38:46 AM
It was only because of one extention that published recently and I installed it 2 days ago. IN-Place Translator version 1.6 extension developed by acyschikove. I disabled it and everything is o.k. now. You can check yourself. Thank you Yngve Nysæter Pettersen. If Opera is very strict about security It's a good idea to check each extensions before publishing.