Removing SSLv3 in Chrome(groups.google.com) |
Removing SSLv3 in Chrome(groups.google.com) |
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.
[1] https://blog.mozilla.org/security/2014/10/14/the-poodle-atta...
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".
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.
it's an ecosystem problem, but also a collective action problem.
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
What a nightmare that year is going to be - so many legacy devices.
"While we're at it, can we add one of those glorious SSL failure screens to any sites that don't use HTTPS in a future version of Chrome?"
"We are working on something like that, but gentler."
YMMV, but: ugh.
Do you really think everything, everything deserves encrypted comunication? cat photos too?
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.
(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 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.
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.