Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing SSLv3 in Chrome

groups.google.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Removing SSLv3 in Chrome

#21

Post by 0x0 »

scrollaway wrote: post #19
mcosta wrote: post #15

Earlier quoted context omitted.

> encrypted HTTP everywhere Do you really think everything, everything deserves encrypted comunication? cat photos too?

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 b…

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.

Re: Removing SSLv3 in Chrome

#22

Post by cpeterso »

TD-Linux wrote: post #18
aroch wrote: post #4

Earlier quoted context omitted.

Just to add, Firefox announced two weeks ago that SSLv3 would be disabled by default in Firefox v34[1], around late November. [1] https://blog.mozilla.org/security/2014/10/14/the-poodle-atta...

It's been turned off in Nightly for a while, and I've noticed several sites broken because of it - most notably, the T-Mobile payment website.

For interested T-Mobile users, here's the Mozilla tech evangelism bug trying to reach T-Mobile about their broken site:

https://bugzilla.mozilla.org/show_bug.cgi?id=1042380

Re: Removing SSLv3 in Chrome

#24

Post by pix64 »

justcommenting wrote: post #14
aroch wrote: post #4

Earlier quoted context omitted.

Just to add, Firefox announced two weeks ago that SSLv3 would be disabled by default in Firefox v34[1], around late November. [1] https://blog.mozilla.org/security/2014/10/14/the-poodle-atta...

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…

You do realize Chrome 40 is also coming out in November, yes?

http://www.chromium.org/developers/calendar

Re: Removing SSLv3 in Chrome

#25

Post by bribriinlondon »

mcosta wrote: post #15
grrowl wrote: post #13

Earlier quoted context omitted.

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.

> encrypted HTTP everywhere Do you really think everything, everything deserves encrypted comunication? cat photos too?

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.

Re: Removing SSLv3 in Chrome

#26

Post by justcommenting »

pix64 wrote: post #24
justcommenting wrote: post #14

Earlier quoted context omitted.

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…

You do realize Chrome 40 is also coming out in November, yes? http://www.chromium.org/developers/calendar

i do - my comment was about security team attitudes

Re: Removing SSLv3 in Chrome

#27

Post by lnanek2 »

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.

Re: Removing SSLv3 in Chrome

#28

Post by justcommenting »

tptacek wrote: post #9
zdw wrote: post #8

Why not go further? 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 suppo…

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.

Re: Removing SSLv3 in Chrome

#29

Post by atesti »

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

Re: Removing SSLv3 in Chrome

#30

Post by cesarb »

mcosta wrote: post #15
grrowl wrote: post #13

Earlier quoted context omitted.

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.

> encrypted HTTP everywhere Do you really think everything, everything deserves encrypted comunication? cat photos too?

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.

Post reply on HN