Live data from Hacker News

The Freak Attack SSL/TLS Vulnerability

freakattack.com

21–30 of 120 posts

Re: The Freak Attack SSL/TLS Vulnerability

#21
post #20
post #13

Earlier quoted context omitted.

I 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, sc…

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

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

Re: The Freak Attack SSL/TLS Vulnerability

#22
post #2

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

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

It 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#Recommende...

[2] https://mozilla.github.io/server-side-tls/ssl-config-generat...

Re: The Freak Attack SSL/TLS Vulnerability

#23
post #9

Earlier quoted context omitted.

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

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

google.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/ under Acknowledgements

Re: The Freak Attack SSL/TLS Vulnerability

#24
post #7

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

I would agree with you for a vulnerability like Heartbleed, where the attack was against the site itself. This is an attack against the users of these sites, so users need to know which sites are vulnerable. Also, attackers are far more capable of gathering this data on their own than users are.

Re: The Freak Attack SSL/TLS Vulnerability

#25
Please see "Recommended Configurations" in 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/

Re: The Freak Attack SSL/TLS Vulnerability

#26
Is 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.

Re: The Freak Attack SSL/TLS Vulnerability

#27
post #25

Please see "Recommended Configurations" in 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/

Author 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-generat... . Cipherscan is also a good tool to have in your toolbox: https://github.com/jvehent/cipherscan

Re: The Freak Attack SSL/TLS Vulnerability

#29
post #2

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

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

Post reply on HN