I can't believe how bad some of the findings were.
From smacktls.com - "JSSE clients allow the peer to skip all messages related to key exchange and authentication. In particular, a network attacker can send the certificate of any arbitrary website, and skip the rest of the protocol messages. A vulnerable JSSE client is then willing to accept the certificate and start exchanging unencrypted application data. In other words, the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years."
To reiterate - The JSSE implementation of TLS has been providing virtually no security guarantee for the past _several years_.
JSSE - the Java implementation of TLS shipped with the JDK.
I guess the silver lining in all of this is now we have a decent way to fuzz the TLS state machine which will hopefully prevent things like this in the future.
I think the most important lesson from the last couple of years is that all our security protocols must come with adversarial testing suites -- from inception. Clearly, there's a long way between designing a secure protocol (I am not saying that SSL and TLS were properly designed) and implementing one.
I think the NSA's clandestine backdooring of hardware, software and standards, in contradiction of their charter, shows that the processes and organizations producing and shipping those protocols, software and hardware also need adversarial testing.
Yeah I would have hoped that tests involving skipped or out of order protocol flows would have been part of their normal functional testing.
I remember reading a while back about NASA's testing procedures and they have a team who's sole job is finding bugs in the code produced by the other development teams. It seems like that structure should be adopted for these security critical projects. Ideally the open source community is supposed to help out with the reviews, but in reality it needs to be someone's whole job.
You can't believe it? Why not? The internet was built over a period of generations by different people, and many subsets of them were probably building something completely different from the other subsets. And it's all still running.
Cross-posting my comment from the other FREAK thread;
If such a suite was enabled, how would the plethora of SSL testing sites out there have graded it? I assume a passing grade would not have allowed insecure suites such as these to be allowed. Insecure cipher is insecure; that would not typically be worthy of a CVE? I guess the bug is that the client will accept it even if it wasn't on the clients cipher list. But it would still have to be on the servers accepted cipher list...
This is all OpenSSL has to say about it;
RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
==============================================================
Severity: Low
An OpenSSL client will accept the use of an RSA temporary key in a non-
export RSA key exchange ciphersuite. A server could present a weak
temporary key and downgrade the security of the session.
This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.
I find these notes are usually too curt to really understand what's going on...
Also, that CVE is from Jan 8, 2015, while this is claiming to be a new issue disclosed today. I've seen no mention on the oss-security list of "FREAK", so something is borked with this disclosure if it is a new vulnerability...
P.S. Matthew makes it clear, this is the same issue, just perhaps a novel way of upgrading its stated severity from "Low" to "Name That Vuln!". With Zombies from Walking Dead as the official mascot :-)
A bit off topic, but you mention this: " but they also lack poetry in their souls." I could not have thought of a more fitting statement for the condition you were talking about. Is this original? Quoted or colloquial saying?
It is a fantastic saying. A quick Google search for the phrase "lack poetry in their souls" turns up a handful of uses in the past 5 years and one theological journal article from 1922.
Remove the word 'lack' and I get plenty more results. The ngram viewer indicates Google found the first usage around 1830 and it was most popular 1840-1850.
What is sad is that OpenSSL disabled the EXPORT1024 ciphersuites in 2006. If you don't know what these are, in year 1999 the US government raised the limit to 56-bit encryption and 1024-bit RSA. They were described in https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuit... . And for the record it was in year 2000 that the restrictions was removed for "retail" software.
To go over some of the technical details, attacker can't just generate a 512-bit RSA key as the key in the ServerKeyExchange message is signed by the server, and the Finished message don't prevent the attack as all the hash depends on is the master secret that can be obtained after the 512-bit RSA key is factored. As a side note, this make me wonder if a similar attack is possible with 512-bit DHE. A server still using it is https://www.ssllabs.com/ssltest/analyze.html?d=mobilelinkgen...
Why isn't apache updated to replace the rsa key on an interval shorter than uptime? Even every 5 minutes shouldn't be particularly expensive. That also seems like a sensible approach.
That seems like a potential solution if these ciphers were still otherwise useful, but as far as I can tell they're not, so it's better to just remove them altogether.
It lowers the damage stealing a key can do, whether via factoring or some other information leakage, for bad ciphers and good ciphers. And obviously, we should stop supporting intentionally broken ciphers.
What is worth mentioning here is that Apache servers do the same thing for Diffie-Hellman 'ephemeral' keys. We imagine those keys are generated for each session, but in fact one key can last for weeks and millions of sessions. (I leave it to someone with more Apache familiarity to correct me.)
Please do not use gray fonts on light background. Black is fine, really. Dark gray is acceptable for background of dark themes since it usually a compromise between contrast and hurting the eye by making the reader's pupils to dilate. There is no such compromise for light themes (well, if you don't count readablity <-> design and your really should weight readability much more).
It's not this article only, but this article made me to change the color in the developer console.
I haven't studied the key exchange for export ciphers, but I wonder if it would be possible to save a copy of the signature on the 512-bit key and replay it later. If that's possible, then disabling export ciphers after the attacker has already a copy of the signed 512-bit key is not enough; the certificate has to be revoked (and we all know how reliable certificate revocation is).
This is an interesting downgrade attack for sure. The author didn't bring this up, but this will probably work around HSTS if you have your site set up and preloaded into the browsers HSTS list.
Heh. For the record, Nadia was doing the handholding. She ran the job across 75 EC2 nodes with software that kept crashing. I updated the post to make that a bit more clear.
I think that's what Matthew meant exactly. "Nadia doing quite a bit of handholding to deal with crashes" -- Nadia is the that's doing the hand holding, rather than needing it. I think OP misunderstood when reading.
Um, more like EC2 and cado-nfs needed quite a bit of handholding to bust through 512-bit RSA keys. For example, the script out at the moment only works for 1.0, not 2.0.
I think CADO's own tools (cadofactor.py and friends) do a better job than the FAAS script at the moment. For smallish factorization jobs like this a lot of bells and whistles are not required anyway.
The FAAS scripts don't replace cadofactor.py. They're intended to spin up a bunch of ec2 instances, configure them, and then call cadofactor.py on them with parameters optimal for that size of cluster. The CADO-NFS guys were super helpful in this process.
Unfortunately StarCluster is currently out of date, and I ran into a bunch of difficulties adapting things to c4.8xlarge instances that don't seem to work out of the box anymore. That and random ec2 volatility were the source of most of the necessary handholding.
If someone has a suggestion for a lighter weight replacement for StarCluster, that would be great.
From smacktls.com - "JSSE clients allow the peer to skip all messages related to key exchange and authentication. In particular, a network attacker can send the certificate of any arbitrary website, and skip the rest of the protocol messages. A vulnerable JSSE client is then willing to accept the certificate and start exchanging unencrypted application data. In other words, the JSSE implementation of TLS has been providing virtually no security guarantee (no authentication, no integrity, no confidentiality) for the past several years."
To reiterate - The JSSE implementation of TLS has been providing virtually no security guarantee for the past _several years_.
JSSE - the Java implementation of TLS shipped with the JDK.
I guess the silver lining in all of this is now we have a decent way to fuzz the TLS state machine which will hopefully prevent things like this in the future.