Huge props to the Chromium team for doing this; it's an excellent precedent.
SSLv3 is broken, and the only reason it's been so well-supported is that the browsers were unwilling to break web servers; the operators of those servers can't be counted on to fix them, and users direct their ire at the browser vendors. But apparently there's a red line across which the browsers won't make up for broken server configurations, and POODLE crossed it.
this is good news--Firefox leaving users vulnerable to well-known attacks by default for just a few months is actually a major improvement (not being sarcastic).
mozilla security engineers have a history of making excuses of the "let's continue doing this incredibly unsafe thing in Firefox in the name of legacy compatibility" variety. i'm thinking of folks like julien vehent & brian smith here, but kudos to the rest of the mozilla security team for finally starting to move beyond the tortured logic of defaults that leave all ff users vulnerable.
I'd be all for very disturbing warnings for any version of TLS before 1.2, and somewhat scary warnings for low-security or non-PFS operational modes.
Basically, enough so that in a big company corporate would ring up the IT department to "fix the ssl site for giving an error", but not enough so that everyone clicks through the "ignorable warning".
It wouldn't work. Users would see "very disturbing warnings" so often that the warnings would quickly stop disturbing them. Everyone --- everyone --- would blame the browsers, the way 3/4 of HN blamed Firefox when they enabled the fascist warning for self-signed certs (incidentally: a much more severe security problem than POODLE!).
If you want to think about "further", you want to suggest that Chromium disable support for TLS 1.1 and below. Nobody can ignore sites that break because they don't use the most secure variant of TLS. But that's obviously not going to happen.
this is true, but if opera, firefox, chrome, and internet explorer all agreed to deprecate TLS 1.1 and below together (or at least implement scary warnings), i wonder if sites might respond differently.
it's an ecosystem problem, but also a collective action problem.
The last update to Iceweasel in Debian stable disabled SSLv3 over a week ago. So far I've only encountered one website I frequent that will need intervention, but otherwise it was hardly noticeable.
I have an old raid controller from 3ware. The management software runs on localhost, but for illadvised security reasons forces HTTPS. One day I was not able to connect anymore (with a browser running on that machine!) I had to hunt down an old version of Firefox to still be able to connect.
Therefore it is a bad idea to not provide a fallback. It's good if every login over the internet is proteceted by HTTPS and weak fallbacks are not used. But there are places where security is just irrelevant (like my localhost scenario, or legacy hardware in a trusted local network), where I'd rather have a way of doing a connection with any way possible, no matter how insecure. Old ciphers, old SSL, compatibility hacks etc.
I wish they would keep that code arount and make it possible to connect anyway
Keeping code around doesn't come free, it still needs to be maintained, tested, and provides an additional attack vector. You need to draw the line somewhere. As pointed out in the post TLS 1.0 is 15 years old and things are still using SSLv3.
The only time Chrome's over-zealous security has even shown up for me is when it doesn't let me login to WiFi that requires a login page. Which happens a lot. Oh, and maybe once the site in question had an expired certificate and I had to use another browser to access it. Wonderful.
This is a problem on Firefox too now. It is due to the new ability for the browser to remember that pages are HTTPS only. For these routers, I generally use example.com as a non-HTTPS website to hit the login.
It's a Good Thing. For example, when Google announced they'll rank HTTPS sites slightly higher, CloudFlare announced adding SSL support to their free tier soon after, free certificates continue to be available. We should absolutely be pushing forward with secure and encrypted HTTP everywhere and be making it as easy as possible for developers to get on board.
Yes, absolutely. Controversial content of all sorts (activism, gay rights, sex, etc) gets censored all over the planet and gets people on watchlists.
When you are talking about the potential for controversy itself creating this problem, then yeah, HTTPS becomes a benefit everywhere. "Oh but we just host cute pictures!" - doesn't matter. Maybe someone commented on one of those pictures and said something about China being a terrible country. Maybe an innocent chinese visitor saw that thread and ended up on a watchlist because of that.
And even ignoring the whole "I have nothing to secure" mentality (which is no better than the "I have nothing to hide" mentality, really), having HTTPS everywhere makes the people for whom it matters safer. Look at what happens with Tor.
In a world where encryption is the exception, the one who uses it is immediately labeled a terrorist.
Make no mistake. This is not about "encrypted communications". This is not about asking the user "Do you think what you are doing here warrants extra security?". This is about the medium. It's about making encryption ubiquitous so that these situations never arise.
When you ssh into a machine, do you ask yourself that question? "Oh well I'm just going to do harmless system monitoring, don't need encryption for that!". No, you don't, because the medium gives you that security and you never have to make that false choice.
So what do you gain by not being secure?
The only argument I ever hear in answer to this is "battery life"/"processing power". Such nonsense. Monochrome displays have a similar benefit, but in general computing you don't give users monochrome displays because of all the situations where colors are useful. And you certainly don't ask the user "Do you think this image you are viewing really deserves colors? What do you gain from them, it's practically black & white already!".
I'm so tired of this whole debate. Can you tell? It's such a waste of time. As Poul-Henning Kamp put it last FOSDEM, the NSA loves that debate and probably perpetuates it. "Do we really need encryption for everything?" is a false question, especially on the internet. You don't, but other people might. And just because you have nothing to hide doesn't mean you should show everyone everything. And just because one kid was raped one time in your town doesn't mean you should store your kids in the basement and treat them like emergency supplies.
There's a huge difference between ssh and ssl's trust model, where the latter requires you to fork over money for each domain name(1) and at the same time trust ALL the other CAs in the world not to work against you.
(1) except for a couple of very inflexible free tiers at a couple of vendors, which caused more trouble than it was worth during heartbleed.
For SSH your key management is 100% in your hands and no third party can create a replacement key pair that would work in a MITM attack.
The perfect is the enemy of good. With TLS, you reduce the MITM exposure from "everyone who is in the path between you and the server" to "everyone who is in the path between you and the server, AND has control of or has hacked into a CA AND is willing to risk the CA being blacklisted by the major browsers".
The latter category is much smaller than the former (which includes anyone in the public access point you're using, for instance). Yeah, the NSA is probably in the latter category (if they think you're important enough to risk burning a CA), but the NSA is not your only adversary.
TLS is not just about encryption. It's also about authentication. Without it, your cat photos site can have malicious Javascript injected into it by malicious middleboxes.
In fact, the canonical way to exploit POODLE is by injecting a Javascript code into a non-SSL-protected page, which will do repeated requests to the SSL-protected page. If the user were to only access SSL-protected pages, and never went to an attacker-controlled page (by following a link on an email, for instance), the attacker can't get the user to run attacker-controlled Javascript and thus can't exploit POODLE as easily (there might be slower attacks, but the fast way requires attacker-controlled requests).
There's also the fact that, as far as I have seen, around half the vulnerabilities in the browser I use (Firefox, see https://www.mozilla.org/security/known-vulnerabilities/firef... for the list) need Javascript to be exploited. If you access a single page unprotected by TLS, Mallory can MITM you and inject Javascript into it to exploit whichever vulnerability of the day there is. If every page you access is protected by TLS, or you use something like NoScript to whitelist Javascript for only a few TLS-protected domains, Mallory can't make your browser run his Javascript and thus loses half the potential exploits.
Yes. Unfortunately, this is an area that has become a zero sum game. Encryption needs to happen by default in every communication. It goes beyond that, entire systems and cryptographic constructs need to be overhauled in the wake of the NIST / NSA revelations.
Starting with TLS, particularly TLS that relies on commercial certificate vendors to function.
It's a total clusterfuck.
SSLv3 is broken, and the only reason it's been so well-supported is that the browsers were unwilling to break web servers; the operators of those servers can't be counted on to fix them, and users direct their ire at the browser vendors. But apparently there's a red line across which the browsers won't make up for broken server configurations, and POODLE crossed it.