
Removing SSLv3 in Chrome - silenteh
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/Vnhy9aKM_l4
======
tptacek
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.

~~~
aroch
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...](https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-
the-end-of-ssl-3-0/)

~~~
TD-Linux
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.

~~~
cpeterso
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](https://bugzilla.mozilla.org/show_bug.cgi?id=1042380)

------
zdw
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".

~~~
tptacek
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.

~~~
yuhong
Yea, it would be likely a couple of years at least before we can disable TLS
1.0.

------
d64mdlekma
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.

------
tshtf
Microsoft is planning the same:
[http://azure.microsoft.com/blog/2014/10/29/protecting-
agains...](http://azure.microsoft.com/blog/2014/10/29/protecting-against-the-
ssl-3-0-vulnerability/)

~~~
agildehaus
This link is not specific to what versions of IE this affects. Is it for all
their supported versions 9 to 11?

~~~
yuhong
The funny thing is that IE6 is still supported, but only on Server 2003.

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

~~~
cube00
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.

------
ck2
Imagine the day researchers announce RC4 has been cracked for sure.

What a nightmare that year is going to be - so many legacy devices.

------
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.

~~~
TD-Linux
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.

------
Doctor_Fegg
From the thread:

"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.

~~~
grrowl
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.

~~~
mcosta
> encrypted HTTP everywhere

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

~~~
scrollaway
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.

~~~
0x0
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.

~~~
cesarb
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.

