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

31–40 of 120 posts

Re: The Freak Attack SSL/TLS Vulnerability

#31

Post by skuhn »

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

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

Re: The Freak Attack SSL/TLS Vulnerability

#33

Post by bashinator »

BashiBazouk wrote: post #12
skuhn wrote: 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.

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

Or anyone who runs the wifi in a coffee shop.

Re: The Freak Attack SSL/TLS Vulnerability

#34

Post by leeoniya »

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.

this: 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)

Re: The Freak Attack SSL/TLS Vulnerability

#35

Post by nodesocket »

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

Re: The Freak Attack SSL/TLS Vulnerability

#36

Post by mc32 »

skuhn wrote: post #21
mc32 wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: The Freak Attack SSL/TLS Vulnerability

#38

Post by devinegan »

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

I updated a public cipher checking script earlier to specifically check EXP ciphers: 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.

Re: The Freak Attack SSL/TLS Vulnerability

#39

Post by elmin »

IgorPartola wrote: post #3
skuhn wrote: 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…

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