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

61–70 of 120 posts

Re: The Freak Attack SSL/TLS Vulnerability

#61

Post by diltonm »

geofft wrote: post #57
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?

Here is a check for the IP for freakattack.com:

http://www.tcpiputils.com/browse/ip-address/141.212.122.194

Edit: They have been on that list for a while, so either the staff at the University is incompetent or they don't care; what was your point again?

Re: The Freak Attack SSL/TLS Vulnerability

#62

Post by geofft »

agwa wrote: post #59
geofft wrote: post #56

Earlier quoted context omitted.

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

Yeah, I think "We agitated to make this the default in the upstream project" would be a fantastic way to solve this problem.

"We're providing builds that are patched to have better defaults" or "We're providing a git repository / config management host / something that has an always up-to-date config snippet" might also be okay, as would "Please check back to this blog post regularly". It's the static post that makes me sad.

Re: The Freak Attack SSL/TLS Vulnerability

#63

Post by geofft »

lstamour wrote: post #60
geofft wrote: post #56

Earlier quoted context omitted.

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

Staying fully patched, at least in theory, involves taking new sources or binaries from the same source on a regular basis. If we could push config like this in the same fashion, I'd be thrilled (whether that involves them coming from the people who get you your sources/binaries, or from a third party). I just worry that someone's going to follow this advice and then leave their job in a few months, and the next person maintaining the system won't even realize that the cipher suites are customized from the upstream defaults. It's not a particularly normal thing to configure.

Re: The Freak Attack SSL/TLS Vulnerability

#64

Post by nuxi7 »

nodesocket wrote: post #35
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.

Didn'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; }

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

Re: The Freak Attack SSL/TLS Vulnerability

#65

Post by devinegan »

cpncrunch wrote: post #50
OneTwoFee wrote: post #45

Earlier quoted context omitted.

Could do with making your messages a bit more clear, i.e: does No mean not vulnerable or does Yes mean not vulnerable.

Yep, I used it and I have no idea whatsoever whether my server is vulnerable or not. Similar for the ssllabs.com test.

If it connects to any of those ciphers with a YES, you may have a problem. They should all say NO.

Re: The Freak Attack SSL/TLS Vulnerability

#66

Post by nuxi7 »

jvehent wrote: post #27
elchief wrote: 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

I'm curious why you bother with (non-EC) DHE at all? Its an interoperability nightmare thanks to the lack of DH param size negotiation in the TLS handshake and all the clients that work with the larger (larger than 1024-bit) DH params also do ECDHE. And at the end of the day, there aren't really that many DHE capable clients that won't do ECDHE. For interoperability reasons I prefer to just keep DHE off and let those rare clients use non-PFS suites.

PS: you're my hero for making this page to begin with. I often direct people to it who ask about SSL settings. Even if I have my own tweaks to the list. Its useful for more than just webservers too.

Re: The Freak Attack SSL/TLS Vulnerability

#67

Post by lstamour »

geofft wrote: post #63
lstamour wrote: post #60

Earlier quoted context omitted.

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

Staying fully patched, at least in theory, involves taking new sources or binaries from the same source on a regular basis. If we could push config like this in the same fashion, I'd be thrilled (whether that involves them coming from the people who get you your sources/binaries, or from a third party). I just worry that someone's going to follow this advice and then leave their job in a few months, and the next pers…

That's where (hopefully) the automating part comes in: a file, checked in to version control, that clearly says what's changed. But this is also where automatically patched vulnerability scanners could play a role, just as you'd want to check configurations periodically to be sure no one's gone in with SSH manually...

Re: The Freak Attack SSL/TLS Vulnerability

#68

Post by nuxi7 »

geofft wrote: post #57
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?

Its probably just scans from zmap. Complaining about zmap scans is about on the level of complaining about ssllabs.com scanning your box.

https://zmap.io/

It could be a student in the dorms who discovered metasploit though. Or someone in the computer lab who has a tool that doesn't need root. (or who rooted the lab computer)

Re: The Freak Attack SSL/TLS Vulnerability

#69

Post by spatten »

If 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/

Re: The Freak Attack SSL/TLS Vulnerability

#70

Post by bryogenic »

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.

In addition to your configs I had to enable HSTS to achieve an A+ Add to a server section:

  add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
Post reply on HN