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 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.
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)
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.
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 :-)
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.
$ openssl version
OpenSSL 1.0.1k 8 Jan 2015
$ openssl ciphers -v EXP
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export
EXP-ADH-DES-CBC-SHA SSLv3 Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export
EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export
EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
Do you mean the session ticket keys, used to encrypt session resumption information?
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.
Well that was unexpected...
Their actual network is *.nsa.ic.gov, and all that fun stuff on Verizon Business. (Amongst other things.)
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.