SSL broken, again, in POODLE attack

Yet another flaw could prove to be the final nail in SSLv3's coffin.

Read the whole story

 

[igor.levicki]

To do a quick check of your servers using openssl:

openssl s_client -connect server.example.org:443 -ssl3

While you are at it, also check if SSLv2 is disabled:

openssl s_client -connect server.example.org:443 -ssl2

If you get an error then it is disabled, if you can see the output from the server such as certificates and cipher lists then it is enabled and you need to disable it along with any weak CBC based ciphers (such as DES and RC4), and weak hashes (such as MD5).

 

[harsaphes]

Entering the "fix" for Chrome, https://zmap.io/sslv3/ I get an error message and It will not let me "OK" out of the window. Anyone else?

 

[bvankuik]

So is Safari on Mac OS X vulnerable?

 

[jdhardy]

doubledeej[/url]":3dlls1n2]On the sites I develop, someone could get ahold of a session key from one of my sites' clients, but it wouldn't do a lot of good because the instant they try to use it from a different IP address or browser they get logged out. Making this type of attack have limited use against my company.

Doesn't help in this case: imagine a malicious public access point with NAT. The user's IP address will be the same to your server (because NAT) but the AP is still reading the traffic and can impersonate the user if desired (but more likely they just scrape useful info).

 

[The Phazer]

What's the situation on mobile devices? Are users of iOS Safari able to disable it at all?

 

[Stubabe]

ThermalNoise[/url]":1tx7knbh]This is somewhat mitigated by the fact that a lot of sites switched to prefer RC4 over AES-CBC because it prevented the earlier BEAST attack. The POODLE attack will not work against RC4, though RC4 is old and broken in its own (somewhat less catastrophic) ways. Once again goes to show that a good implementation matters much more than a secure encryption primitive. (The more modern AES-CBC has fatal flaws that don't affect RC4, despite its age.)

There is nothing wrong with AES-CBC! There is plenty wrong in the way TLS applies the HMAC-SHA authentication to it (or more to the point doesn't apply it to the padding) opening up a timing side channel. That side channel can be mitigated in software with some difficulty so they just didn't bother to fix it in TLS1.2. For that matter TLS1.2 is not more secure than TLS1.1 unless you only enable GCM cipher suites. It just has the potential to be more secure, but your security is fundamentally bounded by the weakest combination of protocol+ciphersuite that your client is willing to accept.

The real fix is the AES-GCM authenticated-encryption mode, though it is becoming a single point of failure. We need new authenticated-encryption modes for diversity; hopefully NIST approves SHA-3/Keccak for authenticated encryption soon.

Or ChaCha20+Poly which is bloody fast if you use SSE2...
To be fair I don't really see much of a push for SHA3 at all. SHA2 has turned out to be far more resistant to attacks (particularly collisions) than the original progress against SHA1 (which has a similar structure to a first approximation) led people to believe.

 

[doubledeej]

jdhardy[/url]":94a8gwau]

doubledeej[/url]":94a8gwau]On the sites I develop, someone could get ahold of a session key from one of my sites' clients, but it wouldn't do a lot of good because the instant they try to use it from a different IP address or browser they get logged out. Making this type of attack have limited use against my company.

Doesn't help in this case: imagine a malicious public access point with NAT. The user's IP address will be the same to your server (because NAT) but the AP is still reading the traffic and can impersonate the user if desired (but more likely they just scrape useful info).

That's why there are other factors included, not just the IP.

 

[drfisheye]

doubledeej[/url]":2701vzod]Developers who take security seriously shouldn't be accepting session keys from any IP address other than the one to which it was originally issued. Yes, this potentially does mean additional login requests for users, but it also mitigates most potential attacks from an issue like this. And it really doesn't happen that often. Most users' IP addresses don't change unless they reboot their modems.

I do this for some applications where I know the users and know their IP addresses are pretty static. But in the general case, you can't expect that; phones get different IP addresses all the time and in my office the IP address changes regularly during work hours. In this specific office the IP's are picked from a known pool so my application can use that knowledge, but in the general case, it won't work.

 

[doubledeej]

drfisheye[/url]":110h07x0]

doubledeej[/url]":110h07x0]Developers who take security seriously shouldn't be accepting session keys from any IP address other than the one to which it was originally issued. Yes, this potentially does mean additional login requests for users, but it also mitigates most potential attacks from an issue like this. And it really doesn't happen that often. Most users' IP addresses don't change unless they reboot their modems.

I do this for some applications where I know the users and know their IP addresses are pretty static. But in the general case, you can't expect that; phones get different IP addresses all the time and in my office the IP address changes regularly during work hours. In this specific office the IP's are picked from a known pool so my application can use that knowledge, but in the general case, it won't work.

My sites have been doing it for 6 years, and I've never received a complaint about it.

 

[drfisheye]

An intrusion detection system should notice a lot of failed connection attempts and block the ip address for a while.

 

[Feniks]

Pale Moon has implemented TLS1.2 protocols since February.

 

[Deleted member 1]

I am going to say it.

Its time for the people who know better to start explaining that Windows XP IS INFACT BROKEN. Of course any OS running out of date browser IS INFACT BROKEN also.

This includes unsupported versions of OS X.

 

[DKlimax]

PhilipStorry[/url]":1n3g4vkp]

CaptainTightpants[/url]":1n3g4vkp]According to the page the article referenced (containing instructions on patching IE and Chrome), they tested the top 1MM Alexa sites and listed those not supporting anything better than SSL3 (said list appears below the instructions). Makes for interesting reading with citibank.com right at the top (although it seems not to be the case any longer having just tried it myself under Firefox limited to TLS1.2). Can't imagine Citi will be happy.


EDIT: Looks like there are a LOT of Citi domains there. Watch out you Citi-folk.

EDIT 2: According to another post below this may not be a problem, but I'd still be cautious if you use any "citi" domain variations.

I'm no security expert, but it seems to me that none of this should be particularly surprising for anyone who's been watching this kind of thing for long enough. It's public knowledge that SSL/TLS version support has been parlous on the internet for years... But it tends to get reported only dryly, in areas like the release notes for builds of web browsers.

That's certainly where I first came across it, back in 2006. I think I was first alerted by a blog post by Opera's devs - they'd put TLS 1.1 and TLS 1.1. extensions, and it broke lots of things due to bad server-side responses.
Took me a while to find the actual blog post - mostly due to My Opera closing down - I had to find another post that referred to it (https://dev.opera.com/blog/new-in-opera ... 2-support/) and then go to the Wayback Machine:
http://web.archive.org/web/200607141139 ... dml/319177

So, since at least 2006, web browser vendors have known that turning on better security breaks sites, and have resorted to nasty kludges and convoluted code - and code convolution itself can bring security issues, so often the answer was to disable by default...
The most likely causes on the server side are ancient & badly written enterprise software (no names mentioned, you can probably guess accurately enough) or badly configured/broken accelerator hardware or cache layers...

I'd kind of hoped that things have gotten better - maybe they have since 2006, it's difficult to know for sure - but this is an area where an article by a trusted source like Ars might at least help get the problem the visibility it deserves, in order to start shaming the cheapskates^Wnegligent into fixing their infrastructure.

tl;dr: Decent support for later versions of TLS is lacking, especially in larger enterprises. This is widely talked about, but nobody's ever kicked up a fuss because previously compatibility was more important than providing better security. That should change - but don't hold your breath.

Five years later it was already known to be still problem...
http://blogs.msdn.com/b/ieinternals/arc ... s-1.2.aspx

 

[passivesmoking]

lamawithonel[/url]":23mq5972]I heard the rumblings about this earlier today and disabled SSLv3 in my browser, but already I've had to re-enable it to book a room with a major hotel chain.

You should have taken your business elsewhere, and informed them why. One reason big organizations are so sluggish on security is because they don't see much financial harm from not being more agressive. If they start to lose bookings because people no longer trust their website's security they might put more priority on fixing it.

 

[PhilipStorry]

DKlimax[/url]":11gw70z9]
Five years later it was already known to be still problem...
http://blogs.msdn.com/b/ieinternals/arc ... s-1.2.aspx

Yeah, and whilst searching for the Opera details that caused me to post here, I stumbled across this Firefox support thread:
https://support.mozilla.org/en-US/questions/959936
Which links to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=861266
Which discusses the issue, and mentions that Chrome tried turning TLS 1.2 on and had to turn it off.

To be honest, I was just using Opera because that was where I first heard of this. Searching for other browsers takes time, and I felt that it was better to just be brief and to the point. But I'm sure you can find some semi-official or even official reference to this problem for Safari and Chrome easily enough - collect the full set of browser vendors! This affects everyone.

Hardware accelerators/load balancers and badly configured enterprise software are holding the security of everyone else back. It's talked about openly, but not in places where it gets coverage. And the culprits are always companies that are too big to give a damn about it - it's not going to be fixed until people kick up a stink.

That's why I mentioned Ars should do an article. Not necessarily to name and shame, but to try and get a perspective on why this is still a problem after 8 years...

[Edited for grammar]

 

[mewmew]

it's still widely supported on both servers and clients alike, and is still required for compatibility with Internet Explorer 6

Haunt me no longer, IE6!

 

[h4vlej]

YAWN.

Anybody who's still using SSL should expect to get hacked. The FLOOR today for anything considered secure is TLS 1.0. It really should be TLS 1.1. But SSL? PLEASE. It shouldn't even be used. I have been blocking this for a couple years now on all servers and my personal clients.

 

[deet]

doubledeej[/url]":1292w85m]Developers who take security seriously shouldn't be accepting session keys from any IP address other than the one to which it was originally issued. Yes, this potentially does mean additional login requests for users, but it also mitigates most potential attacks from an issue like this. And it really doesn't happen that often. Most users' IP addresses don't change unless they reboot their modems.

On the sites I develop, someone could get ahold of a session key from one of my sites' clients, but it wouldn't do a lot of good because the instant they try to use it from a different IP address or browser they get logged out. Making this type of attack have limited use against my company.

This technique doesn't cover every scenario, but it sure could be a difficult bar to pass. Someone would have to be on the same network and mimic the user agent string (as well as other browser attributes) to hack into one of my sites.

Developers who take security seriously should wean themselves away from schemes that depend on the user having a stable IPv4 address.

 

[Knoware]

I went to the Mozilla page linked in the article and looked at the Add-On and attempted to install it, Firefox warns me the Author isn't verified and tells me I shouldn't trust it!

I'm no security expert either and when I see that nice lock icon and the "Mozilla.org certified" stamp, it really makes me wonder...

To be clearer. This is the link in the Mozilla page that the articled linked to that gives me the warning:
https://addons.mozilla.org/en-US/firefo ... n-control/

 

[Tridus]

gpriatko[/url]":1c542opy]> Every https site I've checked so far is using TLS

Which TLS?

SSLv3 and TLS1.0 are equally at risk.

TLS1.1 isn't a pretty sight.

TLS1.2 is where we need to be.

Major sites have already converted in the last few hours.

Akamai was going to block SSLv3, TLS1.0, and TLS1.1 next week. They've moved that up to 'right now'. Going to be some long bridge calls tonight ;-)

Are you sure they're blocking TLS 1.0 as well? I just checked my default corporate install of IE 9 and it doesn't have TLS 1.1 or 1.2 enabled, making 1.0 the highest version that's turned on. That seems like it could get ugly.

 

[Legion6789]

Deleted

 

[CaptainTightpants]

Knoware[/url]":h95oz6eh]I went to the Mozilla page linked in the article and looked at the Add-On and attempted to install it, Firefox warns me the Author isn't verified and tells me I shouldn't trust it!

I'm no security expert either and when I see that nice lock icon and the "Mozilla.org certified" stamp, it really makes me wonder...

To be clearer. This is the link in the Mozilla page that the articled linked to that gives me the warning:
https://addons.mozilla.org/en-US/firefo ... n-control/

Yeah, noticed that myself and followed the about:config instructions mentioned in another post instead. Also fixes Android Firefox (where the extension apparently won't install according to another comment).

 

[Decoherent]

It's worth noting that Ars Technica itself doesn't work unless you allow TLS 1.0, which is irritating, because I can't move my minimum security settings up above that for the internet in general.

 

[GenericAnimeBoy]

Good to know. But that's not what I came here to say.

I came here to say that the article title image, and poodles in general, are weird and creepy. Or maybe that's just me...

 

[MilanKraft]

So because we still have ignorant, lazy jackwads insisting on using IE6, devs must keep on using SSL to support said jackwads, even though we have something much better to use, supported by a wide array of browsers including newer version of IE? First it was the POS rendering engine in IE6 holding back millions of web sites from fully using web standards (for years), now it's holding us back on security. Brilliant.

A message to everyone still using IE 6 when it's dirt simple to use something better:

 

[leedo]

Decoherent[/url]":2l1c3nxg]It's worth noting that Ars Technica itself doesn't work unless you allow TLS 1.0, which is irritating, because I can't move my minimum security settings up above that for the internet in general.

Some might consider this a feature Have you tried using a different browser?

 

[Decoherent]

leedo[/url]":3cef2pgk]

Decoherent[/url]":3cef2pgk]It's worth noting that Ars Technica itself doesn't work unless you allow TLS 1.0, which is irritating, because I can't move my minimum security settings up above that for the internet in general.

Some might consider this a feature Have you tried using a different browser?

My apologies, this morning when I had Firefox set to TLS 1.2 only, I was getting a broken page. Now, however, it's working. I did test IE 11 as well; with TLS 1.2 the login box on the front page was blank, I don't know it that's just me as well; TLS 1.1 worked properly.

EDIT- and now it's broken again I'll take this to the proper forum, sorry.

 

[Roguish]

ChrisSD[/url]":mbz3a9j5]I'm glad it's a simple fix for users of modern web browsers. For Firefox you just install the addon, nothing simpler. Unfortunately most users won't know to do this (presumably) and so will be vulnerable until November, assuming they do upgrade then.

Thanks for this!

 

[leedo]

Decoherent[/url]":xuzz3oy9]

leedo[/url]":xuzz3oy9]

Decoherent[/url]":xuzz3oy9]It's worth noting that Ars Technica itself doesn't work unless you allow TLS 1.0, which is irritating, because I can't move my minimum security settings up above that for the internet in general.

Some might consider this a feature Have you tried using a different browser?

My apologies, this morning when I had Firefox set to TLS 1.2 only, I was getting a broken page. Now, however, it's working. I did test IE 11 as well; with TLS 1.2 the login box on the front page was blank, I don't know it that's just me as well; TLS 1.1 worked properly.

EDIT- and now it's broken again I'll take this to the proper forum, sorry.

Ah, I see. Misread your original comment. I'll double check our config.

edit: how exactly are you setting FF to only allow TLS 1.2? I've set security.tls.version.min to 3 (TLS v1.2) and it seems to work here.

 

[rick*d]

SSLv3, unlike TLS 1.0 or newer, omits validation of certain pieces of data that accompany each message. Attackers can use this weakness to decipher an individual byte and time of the encrypted data, and in so doing, extract the plain text of the message byte by byte.

So, this "new" attack uses a known flaw?

 

[marumari]

igor.levicki[/url]":zrxm0no2]To do a quick check of your servers using openssl:

openssl s_client -connect server.example.org:443 -ssl3

While you are at it, also check if SSLv2 is disabled:

openssl s_client -connect server.example.org:443 -ssl2

If you get an error then it is disabled, if you can see the output from the server such as certificates and cipher lists then it is enabled and you need to disable it along with any weak CBC based ciphers (such as DES and RC4), and weak hashes (such as MD5).

Using nmap's SSL cipher enumeration is usually my go-to tool for this sort of thing, and it gives a lot of super useful information. Here's an example:

april@bipolar(~)$ nmap --script ssl-enum-ciphers system.domain.com -p 443

Starting Nmap 6.46 ( http://nmap.org ) at 2014-10-15 21:07 Cen
Nmap scan report for system.domain.com (1.2.3.4)
Host is up (0.027s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
| TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - broken
| TLS_DH_anon_WITH_AES_128_CBC_SHA - broken
| TLS_DH_anon_WITH_AES_256_CBC_SHA - broken
| TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - broken
| TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - broken
| TLS_DH_anon_WITH_RC4_128_MD5 - broken
| TLS_DH_anon_WITH_SEED_CBC_SHA - broken
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLS_RSA_WITH_IDEA_CBC_SHA - weak
| TLS_RSA_WITH_RC4_128_MD5 - strong
| TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_SEED_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
|_ least strength: broken

Nmap done: 1 IP address (1 host up) scanned in 4.95 seconds

 

[dooferorg]

As well as SSL3 needing to go there's the phasing out of SHA1 too.

Certificates will likely need to be re-signed and webservers reconfigured soon.

 

[Bernardo Verda]

CaptainTightpants[/url]":h24pjoue]

Knoware[/url]":h24pjoue]I went to the Mozilla page linked in the article and looked at the Add-On and attempted to install it, Firefox warns me the Author isn't verified and tells me I shouldn't trust it!

I'm no security expert either and when I see that nice lock icon and the "Mozilla.org certified" stamp, it really makes me wonder...

To be clearer. This is the link in the Mozilla page that the articled linked to that gives me the warning:
https://addons.mozilla.org/en-US/firefo ... n-control/

Yeah, noticed that myself and followed the about:config instructions mentioned in another post instead. Also fixes Android Firefox (where the extension apparently won't install according to another comment).

Whatever the issue was, it appears to have been dealt with.
I installed the add-on (SSL Version Control 0.2) less than an hour ago, with no problems
(except that I would have preferred radio-buttons ).

Also, Mozilla is saying :
"As of version 0.2, this add-on should work with all Mozilla products, including Firefox, Firefox for Android, Thunderbird, and Seamonkey."

 

[afidel]

dooferorg[/url]":2p3z1zji]As well as SSL3 needing to go there's the phasing out of SHA1 too.

Certificates will likely need to be re-signed and webservers reconfigured soon.

SHA1 certs can't be renewed past 12/31/2016, we recently renewed our wildcard cert and since the expiry was in 2017 it was issued as SHA2, we had to have them generate a copy as SHA1 as Citric Secure Gateway can't deal with SHA2 but it's set to expire before the main cert.

 

[Yuhong bao]

dooferorg[/url]":3iro6xdj]As well as SSL3 needing to go there's the phasing out of SHA1 too.

Certificates will likely need to be re-signed and webservers reconfigured soon.

Yea, this is one reason why I have been mentioning the need to update to XP SP3 too.

 

[gpriatko]

>Are you sure they're blocking TLS 1.0 as well? I just checked my default corporate install of IE 9 and it doesn't have TLS 1.1 or 1.2 enabled, making 1.0 the highest version that's turned on. That seems like it could get ugly.

It didn't go smoothly last night.

Right now, the story is that they're blocking SSLv3 by default unless you're white listed. That happened this morning ( around 06:00 Pacific Time ).

But I know that the white list didn't work for everybody.

They seem to have backed off on blocking TLS1.0 and TLS1.1. That could have been a misstatement from their Engineers. OTHO, what they might have meant was that they were going set the new default to be blocking TLS1.0 and TLS1.1 between edge and origin -- not client to origin.

Seeing as how the white list didn't always work, you should probably check and see what your status is: https://www.ssllabs.com/ssltest/

 

[pseudoname]

I think you buried the lead: we may finally have an opportunity to burninate IE6!

 

[DKlimax]

pseudoname[/url]":3bggc3sq]I think you buried the lead: we may finally have an opportunity to burninate IE6!

No. It supports TLS...
ETA: disabled by default though.

 

[HungryBadger]

pseudoname[/url]":2yp5s2tl]I think you buried the lead: we may finally have an opportunity to burninate IE6!

Unless you have a very specific customer requirement, why does it bother you anyway? Surely you aren't still testing for IE6 compatibility, almost nobody outside of China has been using it for years.

 

[DoomHamster]

So adding the command switch does not seem to work for me on Chrome 38.0.2125.104 m 64-bit (https://zmap.io/sslv3/browsers.html still gives me the warning that I am supporting SSLv3). Anyone else run into this?