Opera talks about security features in Opera 9. The good parts - they have totally rewritten their protocol engine, and:
3. We have disabled SSL v2 and the 40 and 56 bit encryption methods supported by SSL and TLS.
The somewhat silly part, they've added more warnings for use of 40 and 56 bit ciphers, but forgotten to warn about that popular zero-bit cipher called HTTP.
The slow part - it must have been two years since we first started talking about it to get to now: SSLv2 in Opera 9 disabled, and TLS Extensions enabled. (SNI itself is not mentioned. I forget where the other suppliers are on this question.)
Why so long?
2. TLS 1.1 and TLS Extensions are now enabled by default.When we tested these features in Opera 7.60 TP in September 2004, our users found 100+ sites that would not work with either or both of these features. So why enable these features now, have we lost our minds?
The reason isn't that the problematic sites have disappeared. Unfortunately, they haven't. The reason we are activating these features now is that we have worked around the problems.
It makes me giddy, just thinking about those 100 sites ... So Opera backed off, just like the others. The reason that this is taking so long is that as far as your average browser goes, security is a second or third priority. Convenience is the priority. Opera's page, above, has lots of references to how they want to be fully standards compliant etc etc, which is good, but if you ask them about security, they'll mumble on about irrelevancies like bits in algorithms and needing to share information with other browsers before doing anything.
SSL v2, originally developed by Netscape, is more than 11 years old. It was replaced by SSL v3 (also developed by Netscape) in 1996. SSL v2 is known to have at least one major weakness. And considering the age of the servers that only supports SSL v2, one can certainly wonder how secure the servers themselves are.Some may wonder why disabling an outdated protocol is news. *Shouldn't these "features" have been removed long ago?*
I like standards as much as the next guy, and I use a browser that is proud of user experience. I even suggest that you use for its incidental security benefits - see the Top Tips on the front page!
But when it comes to protecting people's online bank accounts, something has to break. Is it really more important to connect to a hundred or a thousand old sites than it is to protect users from security attacks from a thousand phishers or a hundred thousand attacks?
The fact is, as we found out when we tried to disable these methods during the 7.60 TP and 8.0 Beta testing, that despite both the new versions of the protocol and the SSL v2 protocol's security problems, there were actually major sites using it as their single available SSL version as recently as a year ago! It is actually only a few years since a major US financial institution upgraded their servers from SSL v2 to TLS 1.0. This meant that it was not practical from a usability perspective to disable the protocol.
Come on guys, don't pussy foot around with user security! If you want to get serious, name names. Pick up the big stick and wack those sites. If you're not serious, then here's what is going to happen: government will move in and pass laws to make you liable. Your choice - get serious or get sued.
The connection between all this dancing around with TLS and end-user security is a bit too hard to see in simple terms. It is all to do with SNI - server name indication. This is a feature only available in TLS. As explained above, to use TLS, SSLv2 must die.
Once we get SNI, each Apache server can *share* TLS certificates for multiple sites over one single IP number. Right now, sharing TLS sites is clumsy and only suitable for the diehards at CAcert (like this site is set up, the certs stuff causes problems). This makes TLS a high-priced option - only for "e-commerce" not for the net masses. Putting each site over a separate IP# is just a waste of good sysadmin time and other resources, and someone has to pay for that.
(Do you think the commerciality of the equation might explain the laggardness of browser manufacturers here?)
With SNI, using TLS then has a goodly chance of becoming virtual - like virtual HTTP sites sometimes called VHosts. Once we start moving more web servers into TLS _by default_, we start to protect more and more ... and we shift the ground of phishing defence over to certificates. Which can defend against phishing but only if used properly (c.f. toolbars).
Yes, I know, there are too many steps in that strategy to make for easy reading. I know, we already lost the battle of phishing, and it has moved into the Microsoft OS as the battleground. I know, TLS is bypassed as a security system. And, I know, SSL was really only for people who could pay for it anyway.
Still, it would be nice, wouldn't it? To have many more sites using crypto by default? Because they can? Imagine if websites were like Skype - always protected? Imagine how much easier it would be to write software - never needing to worry about whether you are on the right page or not.
And if that's not convincing, consider this: what's happening in "other countries" is coming to you. Don't be the one to hold back ubiquitous, opportunistic crypto. You might be reading about RIP and massive datamining in the press today about other countries; in a decade or so you'll be reading about their unintended victims in your country, and you will know the part you played.
In other crypto news:
Microsoft buys SSL VPN vendor Whale
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9000608
Government to force handover of encryption keys
http://news.zdnet.co.uk/0,39020330,39269746,00.htm
UK law will criminalise IT pros, say experts
http://news.zdnet.co.uk/business/legal/0,39020651,39270045,00.htm
How is a user made more secure if their "secure browser" doesn't let them access a number of sites they want to, so they dump it for a browser which doesn't have that "feature"?
If we, the browser makers, are going to do things which break bits of the web, we need to do them together. Striking out on ones own is counter-productive because people just move to a product which doesn't have the inconvenience, thereby reducing rather than increasing their security.
You may scoff at collaboration if you wish, but I think it's the right way forward.
Posted by: Gerv at May 24, 2006 09:28 AMHi Gerv,
Security is a relative benefit - it is not an absolute. The greater good is important to security, not because of philosophy but because it is a good measure of relatives, and it smooths out the effect of absolutes. Half a billion people with better security, or the million or so who get phished every year, is to be compared to the few thousands that might be inconvenienced by the poorer access to those legacy sites.
On one hand we could drop 100-4000 sites. For that, we improve security for all browsing users, and move forward in protecting each year's million phishing victims. At some cost of some inconvenience as the 100-4000 sites need to upgrade.
Alternatively, we keep those 100-1000 sites available and we expose all those people to more attacks. Call it a year wasted, so that's 1 million people, 1 billion dollars. Take some proportion of that, because we can't attribute all the blame to one decision...
That's a lot of pissed off, poorer people - because of what? You didn't want to deny those same people access to a website? On the Internet? With a free browser? Ask a phishing victim sometime.
It's a fair trade-off *iff* you are considering security as important. If security is important, then we generally argue that some inconvenience has to be put up with. So some people move to another browser, or do not upgrade. That's their choice. That doesn't mean everyone, it's a miniscule percentage that would actually move.
In choosing the convenience of access and trying to stop customers migrating because they also choose convenience, browser manufacturers have chosen lower security. That's their choice, and the fact that all browser manufacturers have chosen that path, and are collaborating on that, is a singular observation.
Posted by: Iang at May 24, 2006 10:08 AMThe release note for Opera 8 on "Die inoffizielle Opera-Fansite" says:
# SSLv2 and 40-bit encryption are enabled by default again.
# Readded experimental support for TLS Extensions and TLS 1.1. Setting is disabled by default.
bizarre story, I just had to use my browser for a bank web site
you know its often the case that java applets windows work better with PC (I only have a mac on hand)
I laboriously tried EVERY mac browser to see if it would work
the last one I tried waa, I think, the ONLY BROWSER you have to pay for, its called OmniWeb (omnigroup.com or something)
incredibly it DID WORK PERFECTLY ... omniweb on a mac (I am fairly certain) is the best and perhaps only really reliable browser (on a mac) if you need touse ordinary java applets typical as you might see when logging in to your online bank etc
wild huh!
You keep referring to these "100 sites" but remember that these sites were found during a very limited test period by the relatively few users who frequent the pretty technical beta forum AND are sufficiently interested in encryption and SSL to take part in such a specific testing. It's anyone's guess how many sites out there are incompatible with the new SSL stuff but when brief and limited testing turned up 100 the real number must be at least 15 times larger. Also SSL sites are typically very important to the end user. There are alternatives to most HTTP resources but you NEED to access your online banking. As Gerv already tried to explain the only way forward is the browser vendors pushing together, both pushing CAs to improve their procedures and pushing in unison sites to upgrade their outdated servers.
> (Do you think the commerciality of the equation might
> explain the laggardness of browser manufacturers here?)
Now that's complete rubbish. Users feeling secure is essential to our existence while we get none of the payments to ISPs for those non-shared IP addresses. Where is the logic in this accusation?
Posted by: Hallvord R. M. Steen at May 29, 2006 06:28 AMHallvord, thanks for your comment. On the "cooperation" front:
I know you're probably smarting at the injustice of my post - but you should be aware that this is nothing new. All browsers are at fault, and I write the same criticisms about all of them from time to time. The faults are serious, the faults are real and are only being addressed if one observes geological timeframes. I know the browser manufacturers are all working hard - but there is a difference between working hard and working smart.
Grouping together as a browser community won't help, it will hinder. It will make you feel better for a while, but you really have to do the hard work to understand the big picture. No other browser is going to help you do that, because you all come from the same culture, the same background, the same architecture. You need diversity, not monoculture, to address the blindspots.
By clustering together in a community, this has led you to make a big mistake - blame the CAs. You make it above by pushing the CAs to improve their procedures - and the browser people all huddled together with the CAs to work on the "high assurance" programme. Although the weakness of the CAs is cause for concern, events are even overtaking that concern, such that it is far from the most serious worry we have. The "high assurance" programme will achieve no improvement in security to users, but it may shuffle some other pieces around the board. It does not compare with addressing the security problems of today, and elevating it as "something we are doing" reveals that browser manufacturers have no better strategy than blaming the next guy in the line up.
That's not to say that the CAs can't improve their procedures - they can and they might in time. They have many problems too, but what they cannot do is address the vast bulk of attacks which are against the browser and the Microsoft OS.
Posted by: Iang at May 29, 2006 09:38 AM