Security @ Opera

Secure browsing like it's 1995

, , , ,

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 party . 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. worried



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 ... rolleyes

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. down 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 ... sad

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!

A few results from the TLS ProberRenego: Popular, unpatched and vulnerable sites

Comments

Charles SchlossChas4 Wednesday, March 30, 2011 1:21:24 PM

knight

XenoAntaresXAntares Wednesday, March 30, 2011 2:08:58 PM

You finally renegopatched my.opera.com‽ http://files.myopera.com/Tamil/Smilies/Happy.gif -

Charles SchlossChas4 Wednesday, March 30, 2011 3:37:08 PM

Yngve Nysæter Pettersenyngve Wednesday, March 30, 2011 5:52:27 PM

Certs.opera.com is behind that unpatched Big-IP box mentioned above sad . Good thing the content on it is digitally signed.

Alexandre Willianalexandrewillian72 Wednesday, March 30, 2011 5:53:11 PM

up

Cutting Spoonhellspork Wednesday, March 30, 2011 6:15:12 PM

I have notified my bank.

Charles SchlossChas4 Thursday, March 31, 2011 12:18:38 AM

My banks has TLS v1.0 128 bit ARC4 (1024 bit RSA/MD5) and Opera says does not support TLS renego

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

It is unfortunate, but some banks block Mini because it is does not have perfect direct encryption. (must be transcoded, which is a possible vector for data-mining)

Charles SchlossChas4 Thursday, March 31, 2011 3:38:08 AM

Originally posted by hellspork:

It is unfortunate, but some banks block Mini because it is does not have perfect direct encryption


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

Contacted my bank too (not listed below), thanks for that information. up

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

Volkswagen Bank
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

I just contacted Volkswagen Bank, GE Capital, and Comdirect and asked them when this security issue will be fixed. Perhaps, you all should do the same to increase the pressure on the banks.

ouzowtfouzoWTF Thursday, March 31, 2011 2:49:41 PM

I think it would be better to make this official. When this gets in the news, the banks will change this a lot faster than when only a few people contact them. Maybe its also an opportunity to highlight Operas possibility to see if TLS renegotiation is supported or not. In Firefox4 or IE9 you can not see this.

Yngve Nysæter Pettersenyngve Thursday, March 31, 2011 3:12:48 PM

Just a clarification: Opera indicates that the server protect (or doesn't) against unsecure renegotiation; It does not report whether the server have TLS connection renegotiation enabled.

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:

Just a clarification: Opera indicates that the server protect (or doesn't) against unsecure renegotiation; It does not report whether the server have TLS connection renegotiation enabled.


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:

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?



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:

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.


Too bad there's not an easier way to check. Thanks for that information.

Cutting Spoonhellspork Saturday, April 2, 2011 4:58:41 PM

It's finally on the roadmap for my bank, to be implemented when they shut everything down to roll out the new online interface. Cleverly, Opera Mini cannot use their site; desktop Opera is fine.

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

It would be nice if Opera put back into the security icon the renogo status. Just having "secure" and "trusted" is really not that informative.

Actually, I couldn't care less if its "trusted" vs "secure."

BernG Monday, April 11, 2011 11:41:55 PM

Now that I remember, the renogo status was gotten when the address bar icon was clicked, convenient. Now we have to click in addition "details" to get the status.

Cutting Spoonhellspork Tuesday, April 12, 2011 7:52:07 AM

This is the cost of making the badge easier to read. Most users have no idea what that item would indicate anyway.

MehrdadMehrdad2011 Friday, April 22, 2011 7:53:55 PM

About 2 days ago opera 11.10 was able to connect secure sites like gmail.com, secure facebook.com, yahoo mail,... and the padlock in the address feild was showing that the connection was secure. Recently for all of that website I am expereincing unsecure connection! even gmail!

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?sad

MehrdadMehrdad2011 Friday, April 22, 2011 7:55:23 PM

I forgot to add I don't have this problem with firefox 4.0 and chrome 12.

Cutting Spoonhellspork Friday, April 22, 2011 8:16:50 PM

Is your address bar still showing a badge that says "web"? If you focus the bar, does the URL begin with https:// ?

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

Opera is more strict about things like revocation and mixed security than some other browsers. Some information is displayed in the Security information (e.g OCSP failure), other info is in raw the XHTML source of the security document linked from the Info panel, some like mixed security or problems in inline elements is not directly indicated.

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

Oh my goodness.
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.

Write a comment

New comments have been disabled for this post.