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.
The Freak Attack SSL/TLS Vulnerability
111–120 of 120 posts
Re: The Freak Attack SSL/TLS Vulnerability
#112OpenSSL 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.)
You mean building our web security infrastructure on a "design by committee" kitchen sink protocol with a million config options was a bad idea?
I'm always surprised at the lack of simplicity in FOSS projects. Just because its easy to add a feature or option, doesn't mean it should be done. Sane defaults, that yes will sometimes break legacy systems, makes sense. Moving on to removing old features, that yes will break legacy systems, makes sense. Instead, there's this "who moved my cheese" mentality that is really ugly.
The top voted comments in HN are just most obscure blog postings of questionable validity claiming "wait wait guise, openssl is fine, its admins that suck because of this super obscure config kinda sorta fixes this and they should be using it!" These blog postings are symptoms of the real problem. I shouldn't have to reconfigure my entire SSL infrastructure every couple months.
Re: The Freak Attack SSL/TLS Vulnerability
#113Earlier quoted context omitted.
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'…
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'…
I'm not wild about having non-FS options that a man in the middle could force a downgrade to. IE8 on XP isn't worth it.
Re: The Freak Attack SSL/TLS Vulnerability
#114I 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 was very amused to see whitehouse.gov in the list of vulnerable sites.
Re: The Freak Attack SSL/TLS Vulnerability
#115http://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/
Re: The Freak Attack SSL/TLS Vulnerability
#116I've recently been running Hiawatha servers with PolarSSL (recently renamed something else). I have avoided all the most recent bugs.
Re: The Freak Attack SSL/TLS Vulnerability
#117Earlier quoted context omitted.
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?
You are actually correct that you were scanned by an official, funded project at the University of Michigan. The research team specializes in "internet-wide measurement", meaning they scan for vulnerabilities on a regular basis in order to get a sort of "Internet health report".
Nonetheless, if this bothers you, visiting the IP that scanned you gives you instructions for opting out: http://141.212.122.194
Re: The Freak Attack SSL/TLS Vulnerability
#118So this isn't just a thing where I update openssl? I have to learn about configuring cyphers on short notice?
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...
That's not exactly simple.
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?
Re: The Freak Attack SSL/TLS Vulnerability
#119Its 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. "
Re: The Freak Attack SSL/TLS Vulnerability
#120OpenSSL 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.)
LibreSSL is doing the first part of that. When it's in a useable state, switch to that and leave OpenSSL in the past.
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.