![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
mark) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
dw_maintenance2014-10-14 05:38 pm
Upgrading against the POODLE vulnerability
Hi all,
Today another SSL vulnerability was announced. This one is named POODLE and is, while serious, much less serious than the Heartbleed event from some months ago.
Unfortunately, the only real way to fix the problem is to disable something called "SSLv3" entirely. Basically, this means that we instruct our servers that they are no longer allowed to speak version 3 of the SSL protocol (you can think of it as a language -- we ban this language from our servers). It turns out this is generally OK since most browsers don't actually speak using SSLv3 these days -- you actually use what's called TLS, which is a more modern, better way of protecting the stuff you send across the Internet.
The SSLv3 protocol is actually around 15 years old at this point, and TLS has been out so long that nearly every browser out there supports it. However, shutting off SSLv3 does mean that very old browsers -- IE6, for one -- can no longer talk to Dreamwidth using encryption. In this case, since the encryption wouldn't actually mean anything, we think it's better to not even pretend that it works.
I will be making this change sometime in the next hour or three. This really should impact almost none of you, but there might be one or two and, in that case, I'm sorry. We think it's better to do this so you know you're not actually secure than to let Dreamwidth pretend to be secure.
Edit: This has been deployed. SSLv3 is disabled on Dreamwidth.
Comments and questions welcome, as always!
no subject
Yes, the change is live now.
(If you log in from the navstrip or the site skin anywhere, your password is still encrypted, even if you aren't on a HTTPS page -- it's encrypted in-browser. It's not perfect, but at least it's not being sent in cleartext.)
no subject
You mean, if javascript is on in your browser, if the javascript loads to the browser and if it runs correctly in your browser, then your password is still encrypted, right?
Maybe you all could pick one story and stick to it? I don't disagree with the conclusion to suspend SSLv3, but you know, "it's not perfect, but at least it's not being set in cleartext" is a lot more true of supporting SSLv3 despite POODLE than it is of a silently failing javascript in-browser encryption scheme.
Which is it? "Imperfect is better than cleartext" or "Since it's not perfect, better it's in cleartext".
no subject
no subject
Yes, I do mean all those things. My apologies for being unclear.
And I don't see any inconsistency, though of course you may disagree. For passwords, if someone's not capable of using HTTPS login for whatever reason, it's always been our theory that it's better to at least make as much of an attempt as possible to encrypt passwords. If logging in were the only part of the site that required HTTPS, we might have made a different choice on how to handle POODLE. But the shop is also served by HTTPS only, so we made the decision to shut off SSLv3 support rather than allow people to transfer credit card data over a known-insecure protocol.
no subject
Yeah, that makes sense. It would be nice if that was the initial explanation.
It's a shame that you can't separate the shop from login, seeing as how they have different required levels of security. For login, any is better than some but plaintext is adequate; for shop, there's a minimum level below which it's better that the shop not be accessible.
In an interesting synchronicity, we were just having a chat over in
no subject
You're right, the fallback to cleartext is definitely worse, making you vulnerable to a passive MITM, where the SSLv3 or javascript methods would only be vulnerable to an active MITM. I could see maybe throwing in a noscript section that tells you the password will be sent in cleartext.
no subject