10 ms·
The Freak Attack SSL/TLS Vulnerability
- skuhn 12y agoI can't believe that they are outright naming vulnerable sites, that is really classless. Even if the data could be gathered by an attacker now that a vulnerability is known, you don't need to go the extra mile to provide it.
- IgorPartola 12y agoI disagree. If seeing their name on this list lights a fire under them to fix it that much faster, this is a good thing. Besides, if the you are an attacker capable of exploiting this vulnerability in the wild, this is the first and easiest part of the process. Scanning the top 1M sites would take you no time at all. Edit: what really is annoying is that the sysadmin guide is "Coming Soon!". That is the irresponsible part: "here look we broke TLS, we'll tell you how to fix it at 11!"
- skuhn 12y agoI really disagree with your perspective here, but I do concur that a fast fix is desirable for any impacted site. Notifying impacted sites ahead of public disclosure would have been a better move, and particularly ahead of public shaming and attacker targeting. While these notifications may have gone out, there is no reference to any such thing on the page. Also: do they plan to update this list? Or are these sites to be shamed forever? edit: and yes, the lack of a steps-to-fix is unforgivable. This feels like a race to be first rather than a race to responsibly release and resolve the issue all around. Especially considering that the fix is beyond trivial: Apache: SSLCipherSuite ALL:!EXPORT nginx: ssl_ciphers 'ALL:!EXPORT' (although you shouldn't use ALL, this is just an example; use https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... if you don't know what to do)
- nadaviv 12y ago> Notifying impacted sites ahead of public disclosure would have been a better move Notifying that many effected websites is practically the same as making it public, and could've resulted in letting attackers know about this before the public (and any effected websites that aren't on your list) knows about it and is able to fix that.
- yeukhon 12y agoJust a food for thought (I agree with you that if you call yourself an attacker this is baby stuff enumerating over the top 1M sites): would the author publish google.com or twitter.com if google.com / twitter.com was among one of the affected sites? Would we consider google.com more important than sohu.com and with that we would less likely publish google.com without first notifying Google? You certainly can do your due diligence by notifying everyone on that list, give a one day and then publish the full closure? I don't know. But I am interested in the timeline and looks like this CVE might have been out for a while? Certainly there is one site ranked #27 but I doubt you will get anything out of reporting that to the site adminstrator. I am pretty sure that site (a Chinese portal and search service) does not have bug bounty.
- skuhn 12y agogoogle.com was never going to be on the list, because the researchers specifically talked to Adam Langley at Google ahead of the public disclosure [1] and thus provided advanced warning. Some companies will always receive early warnings about major security vulnerabilities, and that makes sense to gather details about the vulnerability and its exploits, and to minimize the negative impact of an announcement. Other companies get to find out about it the day of the public announcement -- but they don't generally also find themselves on a wall of shame the same day. [1] https://www.smacktls.com/ https://www.smacktls.com/ under Acknowledgements
- moyix 12y agoIt is "Coming soon", but if you click on it the section of the page it links to does tell you what to do (disable export ciphers), and furthermore links to a detailed guide [1] on setting up a secure set of ciphers, which even includes an automated configuration generator [2]. To be honest, I'm not sure what more they're hoping to add there. [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende... [2] https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...
- elmin 12y agoI don't understand why they didn't first contact the website owners. Isn't this exactly what the WHOIS technical contact is for?
- ephemeralgomi 12y agoThere are too many names on that list - not to contact, but to trust. To everyone that you give secret advance notice, you're potentially handing a zero-day.
- skuhn 12y agoThat's true. Have they contacted them now? Do these places which will only fix a problem if they're shamed into it actually know that they are on the wall of shame? More to the point: has a widespread public vulnerability ever before been released alongside a list of everyone who is vulnerable to it? I can't recall such a thing ever happening.
- moyix 12y agoThe same folks providing the list this time around also made one for Heartbleed. It was posted roughly the same time as the initial disclosure, from what I recall. http://web.archive.org/web/20140411064356/https://zmap.io/heartbleed/ http://web.archive.org/web/20140411064356/https://zmap.io/he...
- skuhn 12y agoSo they did, I wasn't aware of that. This sort of proves my point from another comment: they stopped updating the list shorting after it was posted, and so all of these domains are forever stuck on the shame list. Viewing domains from the Alexa top 1M list so many times today also makes it very clear that it is total crap.
- emiliobumachar 12y agoOne cannot realistically expect a secret to remain with that many people.
- mbesto 12y ago"The idea of a branded exploit – one that is carefully curated for easy consumption – is a new one. Historically obfuscation, either real or inadvertent, has been the watchword in computer security mostly because not everyone cared about major exploits. Heartbleed, in a way, was different. It was worldwide, very dangerous, and oddly photogenic. Whereas a Java exploit or Adobe Reader problem is “invisible” to the average user, the idea of a hacker watching your passwords scroll, Matrix-like without security systems setting off alarm bells is compelling and frightening. By creating a “bugs 2.0″ page for the exploit, Codenomicon inadvertently allowed the average user to understand and potentially react to the problem." http://techcrunch.com/2014/04/09/heartbleed-the-first-consumer-grade-exploit/ http://techcrunch.com/2014/04/09/heartbleed-the-first-consum... EDIT: To the OP, I totally misread your point. I thought you were complaining that people were naming vulnerabilities (i.e. FeakAttack, Heartbleed, etc), whereas you said "naming the sites that had such a vulnerability". I agree with you, it's a bit tasteless. My bad! I'm leaving my comment here anyway, because I do think it's worth noting the benefits of branding a known SSL bug/exploit.
- deleted 12y ago[deleted]
- yuhong 12y agoExport cipher suites have been known to be weak for years.
- skuhn 12y agoThey have been known to be weak literally since their inception. The entire reason for export cipher suites was to create encryption that could be broken by the US government. No one should have permitted them since the export control was lifted in 2000. That does not change the fact that some sites did in fact continue to permit them as 'last resort' ciphersuites, to ensure total browser coverage. This did not compromise site security for users who supported actually secure ciphersuites -- until now. Responsible disclosure should mean that impacted sites (if they have been identified) should be informed before being publicly shamed. Doesn't matter if they were doing something dumb, it wasn't a known security vulnerability before now.
- BashiBazouk 12y agoHow vulnerable is accessing these sites? If I tracert to them, the few that I have tried go from the isp to high tier transit to a cloud hosting company. Doesn't seem like much in the way of attack vector beyond someone with a court order access to servers along the route.
- bashinator 12y agoOr anyone who runs the wifi in a coffee shop.
- Mandatum 12y agoAnd so the argument between "full" and "coordinated" (or "responsible") disclosure continues. Unfortunately, this way is a lot of the time the only way to get a company to patch. If they do patch at all, that is.
- Dylan16807 12y agoThey're listing sites out of the top alexa rankings. Anyone can do this scan themselves in minutes. It's not a mile, it's a tiny hop and enough simpler than writing exploit code that it's negligible.
- e28eta 12y agoI was very amused to see whitehouse.gov in the list of vulnerable sites.
- ebbv 12y agoThis is a very disappointing trend in security. Publicly shaming sites into action is not a benefit that outweighs making it easier for attackers. It's ridiculous to argue that it is.
- joshka 12y agoI disagree with this perspective entirely. There are many more users of these sites than operators. Assume that a site is no longer secure, therefore operating any of these sites and claiming secure comms is fraudulent. This fraud is obviously unintentional of course, but the greater damage is to the user, not the site. Secondly, it saves attackers a trivial amount of time. If they're able to exploit this problem, scanning for its existence is orders of magnitude easier.
- mc32 12y agoDo you know if they are only scanning or reporting the 'www' sites or are they listing the main site even if it's just a single server misconfigured, or subdomain, etc?
- skuhn 12y agoDetails are sparse, but the text file is literally bare domains and an IP that in my testing is always the A record for domain.blah. I don't think they're even looking at www.domain.blah, let alone actually crawling these sites or otherwise exhausting their domain space.
- mc32 12y agoI suspected as much. It makes this a lot less useful, but, I guess it's more like ringing an alarm than being precise. On the other hand for some sites this might amount to a false alarm if the tested address has no critical service running on it. Mind you they should all be remedied, but some more hurriedly than others.
- 12y ago
- sandworm 12y agohttps://freakattack.com/clienttest.html https://freakattack.com/clienttest.html I just tested my devices. Linux machines running firefox all passed. On the other hand my Android phone did not, lots of RSA_EXPORT ciphers accepted. But as with nearly every security story: linux/foss software for the WIN!
- skuhn 12y agoOddly, I've seen different results on subsequent visits to their site with the same browser (Chrome 40).
- mbrubeck 12y agoFirefox for Android is not vulnerable to FREAK, and is one of the few ways to get a modern, supported browser engine on older Android devices.
- deleted 12y ago[deleted]
- waitwaitwhay 12y agoWindows Phone 8 passes as well. Closed source for the win! Did I do that right?
- jonahx 12y agoHow can I test if my own, Heroku-based servers are affected?
- paulannesley 12y agoThat page has a meta description for different vulnerability: <meta name="description" content="POODLE Attack and SSLv3 Support Measurement" />
- dadrian 12y agoFixed. :)
- D4AHNGM 12y agoChecked Google Chrome prior to update, said it was vulnerable. Updated and now it isn't. Firefox 37 on OS X wasn't vulnerable apparently.
- elchief 12y agoPlease see "Recommended Configurations" in https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS to see which cipher suite you should be using on your server. Above also shows how to configure most common web servers. You can see which cipher suite your server is using at https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/
- jvehent 12y agoAuthor of Server Side TLS here. Almost everyone should be able to use the intermediate configuration we propose. I recommend our conf generator at https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... . Cipherscan is also a good tool to have in your toolbox: https://github.com/jvehent/cipherscan https://github.com/jvehent/cipherscan
- skuhn 12y agoThe guidelines on Server Side TLS are pretty good, and it is pretty similar to my own cipher list that I use in production. It and the config generator are a great resource to give to people who are less informed about TLS config. My only real gripe is that despite almost exclusively using explicit cipher suite names, there are three groups thrown in: 1. kEDH+AESGCM 2. AES 3. CAMELLIA which then require trailing filters to disable unwanted possible side effects. It's a lot more confusing for the lay person to read, and may produce unintended results on untested versions of OpenSSL. The first group will not output AES ordering in the preferred order (AES128 then AES256). The second one is redundant in my opinion. The third will likewise produce out-of-order results -- if you trust Camellia, wouldn't you prefer to use a forward secret cipher (DHE-RSA-CAMELLIA256-SHA) before a non-forward secret one (AES256-SHA)? On the topic of Camellia, I don't understand why it makes the cut on the intermediate config. No browser ever supported Camellia that didn't also support AES, did it? Anyway, I would view it as an improvement if all of the cipher suites were listed explicitly with no groups, so that there is no need for complicated filters at the end and the potential of activating something in a different version of OpenSSL that you didn't expect to be there.
- 12y ago
- jsmeaton 12y agoIs there an easy way to check our own servers? I can see the fix is to add !EXPORT to the end of the cipher list, but how do we check that the server requires the fix? Really disappointed with this announcement. Some of the other named exploits have come with repro instructions and usually with a fix (shellshock notwithstanding). This is just a description and a shame list.
- devinegan 12y agoI updated a public cipher checking script earlier to specifically check EXP ciphers: https://gist.github.com/degan/70e8059507d173751294 https://gist.github.com/degan/70e8059507d173751294 It will attempt to connect to the domain you specify with all of the EXP ciphers your OpenSSL knows about.
- onyxraven 12y agoAmazon already updated their ELB policies to disable RC4 https://forums.aws.amazon.com/ann.jspa?annID=2877 https://forums.aws.amazon.com/ann.jspa?annID=2877
- sureshv 12y agoGuess it's good I'm using ELB with TCP pass through (because ELB can't handle different SSL terminations by port).
- cesarb 12y agoIt's a pity that this ELB policy (ELBSecurityPolicy-2015-02) also disables 3DES. For older browsers (for instance IE8, see https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP https://www.ssllabs.com/ssltest/viewClient.html?name=IE&vers...) the only options with a good enough key length are RC4 and 3DES. Newer browsers also have AES, so they don't need 3DES, but it's still useful as a fallback for older clients, and it's still considered secure (but slow).
- nodesocket 12y agoWe wrote a blog post: The perfect SSL nginx configuration (http://blog.commando.io/the-perfect-nginx-ssl-configuration/ http://blog.commando.io/the-perfect-nginx-ssl-configuration/) which details all the nginx directives to set to achieve an A+ rating on sslLabs, including mitigation of FREAK, POODLE, and HEARTBLEED.
- leeoniya 12y agothis: https://gist.github.com/plentz/6737338 https://gist.github.com/plentz/6737338 start with this. if you don't need the compat, use a cipher suite without RC4 (as in the parent post)
- nodesocket 12y agoDidn't know about setting DH parameters. On each server, do the following: sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 Then in nginx.conf set: http { ssl_dhparam /etc/nginx/ssl/dhparam.pem; }
- nuxi7 12y agoNon-EC DHE is basically dead. The param size isn't part of the TLS handshake and so using a larger size actually breaks some clients that only do 1024-bit DH params. At the end of the day, almost all the clients that support larger DH param sizes also support ECDHE, which is faster anyway. You might as well not bother and just keep a few non-PFS ciphers for those clients to avoid interoperability problems. Bonus trivia: ssh-dss (SSH DSA keys) has vaguely similar problem, which they considered fixing but decided instead to simply not repeat the mistakes when writing the SSH ECDSA spec. This is why ssh-dss keys are effectively limited to 1024-bit.
- wolf550e 12y ago2048 bit DHE breaks java 6, but is only PFS option for recent msie on windows. A tradeoff worth making.
- 12y ago
- peteretep 12y agoLibreSSL removed the US Export cyphers by default, afaict, so shouldn't be vulnerable.
- Tepix 12y agoSeems like a smart move. Prevents people from shooting themselves in the foot.
- devinegan 12y agoIf you want to check your domains/servers, not just your clients I updated a cipher verification script to just test Export (EXP) ciphers via openssl: https://gist.github.com/degan/70e8059507d173751294 https://gist.github.com/degan/70e8059507d173751294
- OneTwoFee 12y agoCould do with making your messages a bit more clear, i.e: does No mean not vulnerable or does Yes mean not vulnerable.
- cpncrunch 12y agoYep, I used it and I have no idea whatsoever whether my server is vulnerable or not. Similar for the ssllabs.com test.
- devinegan 12y agoIf it connects to any of those ciphers with a YES, you may have a problem. They should all say NO.
- thibaut_barrere 12y agothanks for clarifying this.
- Animats 12y agoOpenSSL has way too many options that reduce security. A lot of that legacy code needs to be removed outright. Not turned off by some flag, not controlled by some environment variable, removed. (And then, when Rust settles down, OpenSSL needs to be rewritten in Rust, as cleanly as possible.)
- FeeTinesAMady 12y agoLibreSSL is doing the first part of that. When it's in a useable state, switch to that and leave OpenSSL in the past.
- Animats 12y agoThey're sure trying. Right now, they're struggling to turn off OpenSSL's "dynamic engine", which allows loading and unloading new crypto engines while OpenSSL is running. In case someone hot-plugs a USB crypto device, perhaps? There stuff in there that 0.001% of users want. It creates a risk for everyone else.
- drzaiusapelord 12y agoYou mean building our web security infrastructure on a "design by committee" kitchen sink protocol with a million config options was a bad idea? I'm always surprised at the lack of simplicity in FOSS projects. Just because its easy to add a feature or option, doesn't mean it should be done. Sane defaults, that yes will sometimes break legacy systems, makes sense. Moving on to removing old features, that yes will break legacy systems, makes sense. Instead, there's this "who moved my cheese" mentality that is really ugly. The top voted comments in HN are just most obscure blog postings of questionable validity claiming "wait wait guise, openssl is fine, its admins that suck because of this super obscure config kinda sorta fixes this and they should be using it!" These blog postings are symptoms of the real problem. I shouldn't have to reconfigure my entire SSL infrastructure every couple months.
- diltonm 12y agofreakattack.com is an IP owned and managed by the University of Michigan. I could not visit the site due to them being in my firewall's ban list caused by unauthorized vulnerability testing against my home network. As an aside I wonder why our tax dollars are being used to support unauthorized vulnerability attempts and for hosting a .com commercial site? Is it legal for the person/people operating freakattack.com to use US Tax Income to fund their own commercial efforts using University resources? I didn't graduate college, maybe it's legal for them to do this?
- LeafStorm 12y ago> support unauthorized vulnerability attempts That was probably just a random student who learned some fun stuff in Security class and slept through the Ethics lesson. I can't speak for UMich, but security research at my university (NC State) has a very strict "don't attack civilians" policy. > hosting a .com commercial site First off, .com sites are not necessarily commercial. Second, this isn't a commercial site, it's an informational page about a recently discovered TLS vulnerability.
- diltonm 12y agoIn the first case I read you as saying it's OK to commit a crime against a civilian in the United States as long as [the person didn't mean to] and in the second case that since not all .COM domains are used for commercial purposes and since this one seems to be information only at the moment; that our tax dollars which helps Universities across the United States to run can be used to fund whatever .COM sites students feel so inclined to register and for whatever reason they feel is justified.
- exo762 12y agoI heard that rhetoric when ones you are calling for help prosecuted Aaron Schwartz. All in times when NSA was hacking all the systems they could get their hands on both around the world and in USA. You may be overreacting and unwillingly supporting erosion of civil rights.
- 12y ago
- orblivion 12y agoSo this isn't just a thing where I update openssl? I have to learn about configuring cyphers on short notice?
- orblivion 12y agoI hate to be a jerk about this, but this isn't a rhetorical question. Are there any simple instructions? 1 2 3 and you're fixed? Why didn't this come on the same page as the disclosure? (that last question can be taken as rhetorical, for now) https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende... That's not exactly simple. http://blog.commando.io/the-perfect-nginx-ssl-configuration/ http://blog.commando.io/the-perfect-nginx-ssl-configuration/ That isn't very simple either, and it's only for nginx. This is all asking me to learn about ciphers to patch a security hole (and know for sure that it's patched). I don't think it's unreasonable to expect otherwise for a security hole. A few people voted up my parent comment so I don't think I'm alone in this. For me personally, the only important thing I have is on Heroku, which I presume has its own set of instructions, which they somehow haven't executed themselves or emailed us about yet. Unless this also affects SSH?
- spatten 12y agoIf you're using AWS Elastic Load Balancer, then the quick fix is: 1) Select the load balancer you want to edit 2) Click the "Listeners" tab 3) Click "change" under the "Cipher" column for the HTTPS row 4) Select the most recent pre-defined security policy, from 2015-02. This should get you an A on SSL Lab's test[1] https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/
- hexasoft 12y agoBreakdown of FREAK sites (Alexa Top 1M) by country. https://infogr.am/https_sites_that_support_rsa_export_suites https://infogr.am/https_sites_that_support_rsa_export_suites
- curiously 12y agois cloudflare safe from this?
- jgrahamc 12y agohttps://blog.cloudflare.com/cloudflare-sites-are-protected-from-freak/ https://blog.cloudflare.com/cloudflare-sites-are-protected-f...
- chinathrow 12y agoWaiting for ssllabs.com to add FREAK checks. Thanks guys, welcomo your support!
- bjornsing 12y agoTo me the whole idea of negotiating ciphers seems broken: a man-in-the-middle will always choose the weakest one. I guess the argument is that cipher negotiation lets you implement stronger crypto without defining a new protocol version, but what is the point of that? An attacker will just negotiate for the weaker cipher anyway (unless this negotiation is cryptographically protected too of course, but this seems so complex in comparison with the rather meaningless "goal" of cipher negotiation).
- pakled_engineer 12y agoCan also just install LibreSSL portable and it will fix all these issues of insecure ciphers, SSL3 ect.
- IgorPartola 12y agoHere's how I've been testing this: openssl s_client -cipher EXPORT -connect www.example.com:443 SSL Labs hasn't listed this vulnerability explicitly yet, but the test seems pretty simple.
- sdaflje5saf 12y agohttp://undeadly.org/cgi?action=article&sid=20150304092744 http://undeadly.org/cgi?action=article&sid=20150304092744 The following CVEs did not apply to LibreSSL: ... CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA Don't forget: http://www.openbsdfoundation.org/ http://www.openbsdfoundation.org/
- arca_vorago 12y agoI've recently been running Hiawatha servers with PolarSSL (recently renamed something else). I have avoided all the most recent bugs. https://tls.mbed.org/ https://tls.mbed.org/
- PC_Hawk 12y agoIts interesting too me that Firefox is supposedly not vulnerable, yet on both my laptop (Windows 8.1 Firefox 36) and My Desktop (Windows 7 Firefox 36) the website (freakattack.com) says i AM vulnerable? "Warning! Your client is vulnerable to CVE-2015-0204. Even though your client doesn't offer any RSA EXPORT suites, it can still be tricked into using one of them. We encourage you to upgrade your client. "