Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Freak Attack SSL/TLS Vulnerability

freakattack.com

Post reply on HN
Print view View original

51–60 of 120 posts

Re: The Freak Attack SSL/TLS Vulnerability

#51

Post by ephemeralgomi »

elmin wrote: post #39
IgorPartola wrote: post #3

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…

I don't understand why they didn't first contact the website owners. Isn't this exactly what the WHOIS technical contact is for?

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

Re: The Freak Attack SSL/TLS Vulnerability

#52

Post by emiliobumachar »

elmin wrote: post #39
IgorPartola wrote: post #3

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…

I don't understand why they didn't first contact the website owners. Isn't this exactly what the WHOIS technical contact is for?

One cannot realistically expect a secret to remain with that many people.

Re: The Freak Attack SSL/TLS Vulnerability

#53

Post by skuhn »

mc32 wrote: post #36
skuhn wrote: post #21

Earlier quoted context omitted.

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.

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

I think it's particularly misleading because some sites only run redirector services on domain.blah for the purpose of sending you to www.domain.blah.

Yes the problem should still be remedied, but no customer data flows through this service, and the connection would be renegotiated after the redirect on systems that may bear very little resemblance technically.

Re: The Freak Attack SSL/TLS Vulnerability

#55

Post by skuhn »

ephemeralgomi wrote: post #51
elmin wrote: post #39

Earlier quoted context omitted.

I don't understand why they didn't first contact the website owners. Isn't this exactly what the WHOIS technical contact is for?

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

That'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.

Re: The Freak Attack SSL/TLS Vulnerability

#56

Post by geofft »

nodesocket wrote: post #32

We wrote a blog post: The perfect SSL nginx 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.

Ugh. I've seen servers with single-DES-only because they had a state-of-the-art config file in the 1990s that nobody had ever touched later. While I appreciate the intent behind efforts like this, I'm really uncomfortable with advice to configure your server with certain ciphers by name, and not make a plan for checking regularly whether that's still correct.

Does merely "!EXP" not work for this? The intent behind OpenSSL's groups is to avoid exactly this problem.

Re: The Freak Attack SSL/TLS Vulnerability

#57

Post by geofft »

diltonm wrote: post #44

freakattack.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…

What is your evidence that the vulnerability testing was done by someone supported by your tax dollars, instead of by a computer that was part of a botnet controlled by your government's cyberenemies?

Re: The Freak Attack SSL/TLS Vulnerability

#58

Post by diltonm »

LeafStorm wrote: post #49
diltonm wrote: post #44

freakattack.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…

> 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, i…

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

Re: The Freak Attack SSL/TLS Vulnerability

#59

Post by agwa »

geofft wrote: post #56
nodesocket wrote: post #32

We wrote a blog post: The perfect SSL nginx 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.

Ugh. I've seen servers with single-DES-only because they had a state-of-the-art config file in the 1990s that nobody had ever touched later. While I appreciate the intent behind efforts like this, I'm really uncomfortable with advice to configure your server with certain ciphers by name, and not make a plan for checking regularly whether that's still correct. Does merely "!EXP" not work for this? The intent behind Op…

I'm troubled by this too. Unfortunately, Ivan Ristic has come to the conclusion that it's not possible to build future-proof cipher suite configuration in a generic way:

https://news.ycombinator.com/item?id=8473626

Re: The Freak Attack SSL/TLS Vulnerability

#60

Post by lstamour »

geofft wrote: post #56
nodesocket wrote: post #32

We wrote a blog post: The perfect SSL nginx 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.

Ugh. I've seen servers with single-DES-only because they had a state-of-the-art config file in the 1990s that nobody had ever touched later. While I appreciate the intent behind efforts like this, I'm really uncomfortable with advice to configure your server with certain ciphers by name, and not make a plan for checking regularly whether that's still correct. Does merely "!EXP" not work for this? The intent behind Op…

You'll have to keep up to date in your server config in other areas, however, including disabling attack surface area and staying up to date and fully patched. Security is never set-it-and-forget-it and that's the real problem with "state-of-the-art config" files. After you fix this manually, find a way to automate such deployments and sign up for a bunch of mailing lists or RSS feeds. Monitoring would be nice but awareness is a start.
Post reply on HN