![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
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
no subject
no subject
no subject
no subject
no subject
I think of the whole subject kind of like the evolution of siege warfare.
First they built SSLv1, but it was crap. So it never actually was used and went away. Then they made SSLv2 and said "check out our awesome wall, nobody can sack our city!" and a bunch of people showed up, looked at it for 30 seconds, and then built a ladder and sacked the city.
Very shortly thereafter they made SSLv3. Which featured such things as bigger walls, arrow slits, and even some archers. And it stood for a while, but eventually, someone made a trebuchet and could rain down pain and destruction from great distances. Also crossbows.
They had to get fancier, those city builders. There came designs for walls that actually made the physics of dropping heavy boulders work out kind of badly. Not to mention that if you build walls thick enough, the heaviest rocks can't do all that much. So for a while, TLSv1.0 was the king of the hill and the darn people who sack cities had to go away (or get very, very large armies and starve them out -- medieval DDoS attacks).
And then, as they say, necessity is the mother of invention. Those cravers of other people's data -- er, cities -- started to deploy gunpowder based weaponry and fancier schemes. The walls started to fall again, and so TLSv1.1 was created to patch things up one more time.
Of course, you see where this is going.
Every few years the cycle repeats. Sometimes we win -- in that scientists who study this stuff find the vulnerabilities before the bad people -- and sometimes we lose. And unlike actual sieges, it's usually impossible to know for sure if you've been breached (pretty hard to prove a negative). The best we can do is try to be vigilant and respond quickly when one of these things does happen, have good logs, and watch things.
Maybe this was informative, maybe entertaining, maybe neither. Also, I realize I just made some probably egregious misinterpretations of medieval warfare. I am totally open to critique and education. :)
/ramble mode off
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
ETA: and now I can't load https://www.dreamwidth.org/login.bml so it looks like yeah, it's not supporting TLS.
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)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
It happened shortly after this entry was posted!
no subject
Yup, this happened ~2 hours ago.
(no subject)
(no subject)
no subject
no subject
no subject
(no subject)
(no subject)
no subject
no subject
Big thumbs up to the maintainers for clear and open communication.
no subject
And the curly twisted fur poodle would also have little plug-ins on the end of each coil, a bit like the plugs you connect an iPod or whatnot with.
Also, you are entirely not the only person wondering where the heck they come up with these names. I keep expecting to find one named Nosegoblin or something equally hideously random. But then, I guess Heartbleed is pretty random isn't it? But seriously, I'm so glad my mental image made you smile.
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
no subject
no subject
A related question
Re: A related question
Re: A related question
no subject
no subject
Thank you so, so much for this. For once, I do not seem to be one of the people whose older browser is impacted, but I have been often enough to really, really appreciate an explanation, and an acknowledgment that anybody using something that old might be doing so for a reason, rather than the usual "your browser is ugly and its mother dresses it funny, upgrade now, loser!" attitude that many other sites think qualifies as customer service.
You guys seriously rock.
(And it sounds like the affected browsers will still be able to use the site, just not with encryption? Leaving it up to the users to decide what's priority for them? Awesome.)
no subject
This. So much.
Glad my browser is in the clear this time. :)
(no subject)
(no subject)
no subject
no subject
It's definitely not that easy, sadly. We could turn on site-wide SSL tomorrow, except for the fact that people can include content (images, videos, etc) in their entries loaded from other servers, and that content isn't always (isn't often) served over a SSL connection. If you have a page served over a secured connection that contains unsecured content, most browsers will throw errors, fail to load the unsecured content, or (at the strictest security settings) refuse to load the page entirely.
It's not an unsolveable problem, and we've spent a lot of time talking over the question of how we can solve it, but we haven't found a good enough solution yet.
(no subject)
(no subject)
Insecurity
-- hendrik
Re: Insecurity
-- hendrik