Serious SSL woes that Vivaldi shares with Chromium and others
-
Ok, so here is my complaint about SSL. Actually, Vivaldi's not alone with that, Chromium and even Firefox did it before, and I don't like it. The first is the blocking of entire cryptographic protocols. Most will know about SSLv3 being dumped by Google with a statement along the lines of "just upgrade your servers". That's just WRONG. Same goes for even older protocols. Even more troublesome is the limitation of the cipher suites within a given protocols specifications for older versions of the engine. Vivaldi still lets you use SSLv3, but not certain ciphers like some 3DES variants. (Note: You may override certain SSL problems, like unknown CAs or self-signed certs, but the problems I'm describing can NOT be overridden as of now.) Now you can always say "But this is insecure!". Yes. I agree. To some extent. I would want to see the browser warn me about this, and show me all the details of the problem, would even want to see it lecture me about it, so I can understand the issues better. I would NOT like to see it force me though! SSL/TLS security is not an "on/off" thing. The level of protection of each protocol and cipher depends on the nature of its vulnerabilities and the exact threat model as defined by the user. I have a very clear threat model for several "security zones" in my networks, and some would allow for the use of SSLv3 (yeah, with Poodle and all). It is still better than plain text traffic even if some people wanna tell you it's not - they don't know my security policies, so how can they make such a statement?! Google says "upgrade your servers". Yeah well, I can do that for any Linux or BSD server with relative ease. For certain Windows servers too, depending on the software used. But there are a lot of embedded systems using web interfaces for management or interfacing with machinery, that simply cannot be easily updated. This includes but is not limited to out-of-band network management interfaces of UPS units, KVM-over-IP gateways, DAS RAID controllers, storage appliances and other really expensive hardware. So should I throw away a huge storage appliance or all my UPS units (APC for instance still doesn't support "safe" TLS even today and not even for its newest products! They're not alone.)? Impossible! So? Enable it. Make it strictly optional. Make sure the user has to enable it manually. Lecture the user about the consequences. Warn him with red flashy lights if you need to. But don't FORCE the user to switch back to Opera 12 (or whatever) just because he can't maintain his IT infrastructure anymore. Not everybody has a VPN gateway to secure access to a separate management LAN for these things. Don't block any cryptographic protocol irrecoverably. Don't block any cryptographic cipher irrecoverably. This depends on the local security policy and pre-defined threat models, whether for simple private use or in corporate environments. I as the user will force myself to adhere to my threat models. I don't want the browser to do that for me. Give me choice! Thank you very much.
-
Hi GrandAdmiralThrawn,
What you should consider about SSL v3 is that it is and old protocol. It is almost 20 years old, and it was replaced by a newer version 16 years ago. What that means is that any and all servers that only supports SSLv3 have not only been running for at least 16 years(!), they have done so without any significant maintenance! If such a server isn't already "pwned" by at least one attacker, it is living on borrowed time, because it is very likely riddled with security holes. Swiss cheese with very little, or no cheese comes to mind.
The number of servers that only support SSL v3 is minimal. When I scanned my sample of servers on Monday, using my TLS Prober, it found only 0.347% (1866) of them, out of 537000 servers. That is down from 0.9% a year ago, and most of it since October when it was 0.71%, and with recent developments it it's likely to drop even closer to zero shortly. The number of servers that support SSL v3 was effectively 100% a year ago, but is now down to 61%, just from October.
Regarding SSL v3, after POODLE it must now be considered completely broken for block encryption methods like 3DES, and RC4 is almost as badly off, and close to being practically breakable. Both of these facts have made the IETF reach the conclusion that the SSL v3 and RC4 can no longer be trusted. The document requiring clients and servers to not negotiate RC4 is about to be published as an RFC, and the document for doing the same with SSL v3 is in Last Call, meaning that it is probably 2 months away from being published as an RFC. In fact, a couple of days ago, suggestions were made to give TLS 1.0 the same treatment.
As such SSL v3 is so badly broken, that it is not just time, but more than time, to put it out of its misery. Any system that relies on SSL v3 being supported by clients should have been replaced, at most, 13 years ago.
This is not the first time this kind of thing have happened. We did it a number of years ago with SSL v2, and we did it with 40-bit and 56-bit encryption, for the same reason that we are now killing SSL v3 and RC4: Their continued existence represent a clear and present danger to our users.
Encryption methods and protocols have finite lifespans, and always have had that, and anyone who does not take that into account when building a system (or who rely on somebody who doesn't) is in for a world of hurt when the rest of the world do act on that fact and retires one or more of them, particularly when the upcoming retirement or need for it has been advertised for years.
-
I understand your concerns, but this is simply not what the real world looks like.
Let me get back to my example, APC. Not the only example, but for me the most prominent one at the moment. The industry leader in uninterruptible power supplies is still shipping management interfaces even for their largest installations which do NOT negotiate TLS 1.1 or 1.2.
Instead, they still rely on TLS 1.0 using 168-bit 3DES. That is a cipher Vivaldi (and others) will refuse to negotiate as it is simply not in their cipher suites anymore as far as I understand the error messages.
Now I'm not talking about hardware 16 years old. Not 10 years. Not 5 years. I'm talking about the latest-and-greatest you can buy from the world leader in UPS units. This is year 2014 stuff. Their documentation suggests to "just switch encryption off" to make it work. I mean, is this what we want?
I still believe that given the MITM attack vectors, TLS 1.0 and SSLv3 can still provide more protection than plaintext communication depending on what you'd perceive as probable threats.
You make it sound as if SSLv3 and certain ciphers are stoneage technology and were not in use for a decade or so, but this is simply not true. Connecting to a Hewlett Packard MSA2312fc SAN right now, what I'll get is vulnerable AES256-CBC (instead of GCM) in TLS v1.0 again.
I'm talking about protection of investments here.
Google says "Please tell your servers administrator to upgrade the web server".
Well, i AM the administrator, and truth is, I can't do anything about it. I couldn't even buy new hardware, first because of pointless expenses ranging well into 5-digit numbers and second because we already have the newest possible hardware available for some parts of the infrastructure.
Business/Industrial hardware is just like that. Takes forever to move forward, with validation processes longer than the lifetime of a Debian release it seems.
The servers you scanned were likely Port 443 regular web servers, nginx, Apache, IIS, that sort of thing. That's not typically the port management interfaces would listen on. Also, many might not be accessible via the public Internet.
Thus, that statistic is likely not significant in the context I am talking about.
Bottom line is, I still believe the user should have the freedom of choice in this regard, proper warnings included of course. The IETF bringing the ban of protocols and ciphers up as a standard (or at least RFC) is nice and all. But if major companies take 10 years to follow that standard, then what?
-
-
SSL v3 is stone age; TLS 1.0 is not much better, TLS 1.1 is actually the minimum recommended today, due to attacks on TLS 1.0.
-
Vivaldi has support for 3DES with RSA and SHA1. 3DES is also stone age, and nominally it only have 112 bits of security.
-
TLS 1.0 is still enabled, it is the stone age SSL v3 that is being forcibly retired because it can no longer do the job. A reason for also retiring TLS 1.0 and TLS 1.1 are that they include MD5 which is effectively broken, and SHA1 is creaking dangerously.
-
GCM is using a framework that was actually defined for TLS 1.2, not TLS 1.0. Any server that supports it should support TLS 1.2 as well.
As for the hardware you mention, I recommend asking the vendors for firmware updates if they do not support at least TLS 1.0 with AES (should support TLS 1.2 IMNSHO). with those pricetags their software ought to be upgradable.
-
-
The Firmwares are all upgradeable of course, yes. But have you ever worked with large OEMs or "Enterprise level hardware" manufacturers? They're as flexible as Mount Everest. Also about as fast-moving. And they don't listen to smaller customers. And larger customers (from my experience that is) typically have validation and compliance protocols of their own, making them lack behind for years anyway.
I know guys in bigger companies who are stuck with OpenSSL 0.9.7 or Java 1.6 and unbelievable stuff like that because of the sluggishness of such processes.
Those I have worked with so far care surprisingly little about security (if its not actual security products they're building and selling).
I still believe (and always will) that this should be my choice to make, not anyone else's, given the circumstances. Especially if I can't make companies do their job properly. I'm going to use old protocols and ciphers in any case, either with Vivaldi or Opera 12 if Vivaldi won't let me (multi-browser again..). It's not that I love old cryptographic protocols and ciphers that much. It's that I have no choice, plain and simple. And even Googles and Mozillas combined strongarms don't seem to do the trick, at least not yet.
Best thing I've read so far from the APC side was "We might upgrade the latest generation of network management cards some time in the future".
Yeaaah.. riiight…
@GCM: Of course.. I wasn't trying to imply that there'd be any AES256-GCM in TLS 1.0. I was trying to say "both protocol and cipher are old".
Edit: After thinking about it a bit more, I believe I have to acknowledge that it's just not going to happen, especially given the IETFs course of action (that I have to admit I wasn't aware of in all details). Considering the situation it would mean that Vivaldi would be required to violate accepted RFCs (soon-to-be standards) to make the magic happen. I presume that this can never be, no matter how "right" I would think it'd be to put control over the matter into users' hands.
2 browsers for 2 fields then.
-
Hi, just an bit of extra information. I decided to take a look around, and found two articles (that you may have seen already) that might be of interest with respect to APC:
Unsecure key for the certificate, blocked by browsers: http://www.schneider-electric.us/sites/us/en/support/faq/faq_main.page?page=content&country=US&lang=en&id=FA162031&locale=en_US&redirect=true
The TLS 1.0/SSL v3 problem: http://www.schneider-electric.us/sites/us/en/support/faq/faq_main.page?page=content&country=ITB&lang=en&locale=en_US&id=FA238115&redirect=true
In the latter case, it seems that the APC firmware does not implement TLS 1.0 properly (violating RFC 2246), and is intolerant for TLS extensions, which means that absolutely no modern browser is able to connect to an APC unit using TLS 1.0 and extensions. Previously this was worked around by falling back to SSL v3, which is no longer advisable (if it ever was).
An additional point about this intolerance, is that it is likely that their TLS 1.0 implementation has not been patched for the 5 year old TLS Renegotiation vulnerability (RFC 5746). I am not saying it is vulnerable if they haven't, as the vulnerability requires the server to perform/accept a renegotiation of the connection to be vulnerable, which I don't know if this server do. It it is likely, though, that a client is not able to tell if the connection is properly established, and not intercepted by a man in the middle. As that fix is primarily based on using TLS Extensions, if the APC firmware is intolerant for extensions, then the firmware's TLS implementation is probably not patched for that issue.
-
Backwards compatibility has always been a thorn in the side of the Internet and computers in general. Whether it be protocols, hardware capabilities, or software evolution toward dependence on newer standards and hardware. Whether or how much to invest in backwards compatibility are decisions that have to be faced every step of the way by every player in the game.
Hardware makers and those who invest heavily in hardware want backwards compatibility to persist forever. Software creators want it to end more quickly, since it burdens their design and sometimes the security of their products. Adding options for reverse compatibility costs design effort, code bulk, and perhaps performance-loading in order to provide for the aging external protocol structures, internal APIs required, and all the other things needed to support capabilities no longer in common usage. And with evolving foundational architectures (such as rendering engines underlying a browser or security compartmentalization of a modern OS), supplying the elements for reverse compatibility can become very difficult if the functionality being sought is no longer an accessible part of that core architecture.
At the end of the day, makers of hardware relying on obsolete and vanishing control protocols simply have to decide THEY need to provide support for upgrading their products to newer protocols, and owners of such hardware need to realize THEY have to deal with the obsolescence in a framework of reality… either pressure the makers for updates, replace the hardware with products from makers who are current, or find alternate ways to control the hardware via the obsolete protocols and accept the various risks and limitations of choice that entails.
It's always appropriate to politely ask (as you have) that a software maker provide for reverse-compatibility inclusion in a newly emerging product. But only he can make the determination of how much effort to include in which direction(s) to provide it. His costs vs. likely reward are just as important to him as your business's costs are to you.
-
Thank you for your replies,
@Blackbird: You are correct of course. But seeing as how the IETF is handling the issue makes me think (even though this hurts me here), that they probably should not re-introduce those protocols and/or ciphers. The correct thing would clearly be for affected hardware manufacturers to update their firmwares.
In certain cases I am sure that this is just not going to happen (certain older hardware from different manufacturers). In the APC case it still might. But they're surely taking their time..
So in the meantime - and for some products probably for as long as they'll be running - the only way is to have an older web browser ready..
-
1. It's bad practice to expose management interfaces to a network without strict access control. Even if the crypto is up2date, you should use at least a VLAN to protect this interfaces.
2. It's also bad practice to use a system which you use to surf on the web to maintain servers.
If this points are fixed, you can think about browser security. Besides that I think that you should not use Vivaldi for this purpose at the moment(It's not a stable software yet), try entering vivaldi://flags in Vivaldi and search for "ssl".
-
I do not intend to use Vivaldi for anything but testing yet. And that'll probably stay like that for a long, long time.
@ 1.) Yeah of course, still needs a browser that can access it though. Also, a VLAN still needs an external gateway to it, for global access as opposed to on-site access only. And IP-level access control is pointless if the clients address is arbitrary. For that I prefer PKI and user authentication where applicable.
@ 2.) Impossible?! How would you maintain embedded systems on the go from a Laptop anywhere on the planet then? I can always place an SSH gateway between management interfaces and clients (or VPN) for mission critical applications. But if you travel around, you take 1 notebook with you, it'll have to be multirole. It should be sufficient to lock such maintenance tasks to a separate user on any Linux or UNIX client machine (very few Windows machines in our case).
-