
The Freak Attack SSL/TLS Vulnerability - markthethomas
https://freakattack.com/
======
nodesocket
We 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.

~~~
teekert
Hmm, as a novice, capable of setting up fine Drupal/Nginx/mail(Postfix) server
I'm kind of shocked to get an F rating on ssllabs with the default, up to
date, ssl enabled, Debian/Nginx config... Sounds like something to fix, not?
Is there that much need for some forms of backwards compatibility? Are A+
servers badly reachable from older browsers or something? Why would the
default be so bad? Somehow, in all my naivety I have always thought regular
apt-get update/upgrades would keep me secure. Seems I'm still vulnerable to
POODLE even. Guess I'll have to keep checking next to updating. Should I
delete old config files with every update? Are new ones containing the
recommended settings?

~~~
diafygi
Here's the how we get an A+ rating[1] for nginx on utilityapi.com:

    
    
        ssl on;
        ssl_certificate my_ssl.crt;
        ssl_certificate_key my_ssl.key;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers EECDH+aRSA+AES256:EDH+aRSA+AES256:EECDH+aRSA+AES128:EDH+aRSA+AES128;
        ssl_session_cache shared:SSL:50m;
        ssl_prefer_server_ciphers on;
        add_header Strict-Transport-Security max-age=63072000;
    

Our configuration doesn't support for IE6 or IE8 on Windows XP, but that's the
only downside. Also, this configuration has 100% forward secrecy :)

Finally, you can get an A+ rating for free with StartSSL's free option, then
using the SHA2 intermediate certificate[2]. This is what I use for my pgp
keyserver[3].

[1]:
[https://www.ssllabs.com/ssltest/analyze.html?d=utilityapi.co...](https://www.ssllabs.com/ssltest/analyze.html?d=utilityapi.com)

[2]:
[https://www.startssl.com/certs/class1/sha2/pem/](https://www.startssl.com/certs/class1/sha2/pem/)

[3]:
[https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightp...](https://www.ssllabs.com/ssltest/analyze.html?d=sks.daylightpirates.org)

~~~
tombrossman
You can keep your A+ and add IE8 on XP, plus boost your key exchange to
100%[0], by following Mozilla's TLS docs[1] and sticking with the default
Intermediate ciphersuite.

You might also consider disabling server tokens to hide your Nginx version
(server_tokens off;) for a bit of 'security through obscurity' and enabling
SPDY (listen 443 ssl spdy;) for a performance boost.

Also worth pointing out is the upcoming Let's Encrypt project[2] which will
make domain validated certificates free soon.

[0][https://www.ssllabs.com/ssltest/analyze.html?d=brossmanit.co...](https://www.ssllabs.com/ssltest/analyze.html?d=brossmanit.com)
[1][https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)
[2][https://letsencrypt.org/](https://letsencrypt.org/)

~~~
higherpurpose
I think using Mozilla's "Modern cipher suite" list should do it, and it seems
to be all forward secure:

[https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_com...](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility)

~~~
tombrossman
What prevents me from using 'Modern' is it requires Android 4.4+, which
excludes a hell of a lot of mobile users. I'm okay with dropping XP support
but dropping Android 4.3 and earlier is too limiting for me.

------
elchief
Please 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
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...](https://mozilla.github.io/server-side-tls/ssl-config-generator/) .
Cipherscan is also a good tool to have in your toolbox:
[https://github.com/jvehent/cipherscan](https://github.com/jvehent/cipherscan)

~~~
nuxi7
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.

~~~
jvehent
> let those rare clients use non-PFS suites

That's not acceptable for us, which is why DHE is there. Mozilla aims to
provide the best possible security to the larger number, and that drives a
number of the choices in the recommended ciphers.

~~~
edwintorok
How about the Modern suite, where you already give up compatibility with old
stuff? Is non-EC DHE needed there?

------
Animats
OpenSSL 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
LibreSSL is doing the first part of that. When it's in a useable state, switch
to that and leave OpenSSL in the past.

~~~
Animats
They'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.

------
onyxraven
Amazon 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)

~~~
cesarb
It'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&vers...](https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP))
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).

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

~~~
IgorPartola
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 part: "here look we broke TLS, we'll tell you how to
fix it at 11!"

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

~~~
ephemeralgomi
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.

~~~
skuhn
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.

~~~
moyix
The 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/he...](http://web.archive.org/web/20140411064356/https://zmap.io/heartbleed/)

~~~
skuhn
So 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.

------
peteretep
LibreSSL removed the US Export cyphers by default, afaict, so shouldn't be
vulnerable.

~~~
Tepix
Seems like a smart move. Prevents people from shooting themselves in the foot.

------
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/](https://www.ssllabs.com/ssltest/)

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

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

------
paulannesley
That page has a meta description for different vulnerability: <meta
name="description" content="POODLE Attack and SSLv3 Support Measurement" />

~~~
dadrian
Fixed. :)

------
sandworm
[https://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!

~~~
mbrubeck
Firefox 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.

------
orblivion
So this isn't just a thing where I update openssl? I have to learn about
configuring cyphers on short notice?

~~~
orblivion
I 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#Recommende...](https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations)

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?

------
sdaflje5saf
[http://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/)

------
bjornsing
To 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).

------
IgorPartola
Here'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.

------
PC_Hawk
Its 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. "

------
D4AHNGM
Checked Google Chrome prior to update, said it was vulnerable. Updated and now
it isn't. Firefox 37 on OS X wasn't vulnerable apparently.

------
pakled_engineer
Can also just install LibreSSL portable and it will fix all these issues of
insecure ciphers, SSL3 ect.

------
arca_vorago
I'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/)

------
hexasoft
Breakdown 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)

------
devinegan
If 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
Could do with making your messages a bit more clear, i.e: does No mean not
vulnerable or does Yes mean not vulnerable.

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

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

~~~
thibaut_barrere
thanks for clarifying this.

------
chinathrow
Waiting for ssllabs.com to add FREAK checks. Thanks guys, welcomo your
support!

------
jonahx
How can I test if my own, Heroku-based servers are affected?

~~~
imrehg
This gist seems to be working well for testing:
[https://gist.github.com/degan/70e8059507d173751294](https://gist.github.com/degan/70e8059507d173751294)

(I've run it against the servers I manage)

------
curiously
is cloudflare safe from this?

~~~
jgrahamc
[https://blog.cloudflare.com/cloudflare-sites-are-
protected-f...](https://blog.cloudflare.com/cloudflare-sites-are-protected-
from-freak/)

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

~~~
moyix
Running zmap or masscan is such a low barrier to entry (compared to the
expertise required to then factor the key and set up a MitM attack) that it's
hard to argue this is really making it that much easier for attackers.

Aside from the benefit of pressuring these sites into fixing the problem, it
also benefits users, who can now make an informed choice about whether to
(say) visit a vulnerable site at a cafe or wait until they get home.

~~~
meesterdude
I want to disagree with you, but you're right. If there is any reason to call
into question the trust or safety of a site I visit, I should know.

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

~~~
geofft
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?

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

[http://www.tcpiputils.com/browse/ip-
address/141.212.122.194](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?

~~~
dadrian
This is why reverse DNS exists.
[http://researchscan450.eecs.umich.edu/](http://researchscan450.eecs.umich.edu/)

