If you're running a web server configured to use SSLv2, and particularly one that's running OpenSSL (even with all SSLv2 ciphers disabled!), you may be vulnerable to a fast attack that decrypts many recorded TLS connections made to that box. Most worryingly, the attack does not require the client to ever make an SSLv2 connection itself, and it isn't a downgrade attack. Instead, it relies on the fact that SSLv2 -- and particularly the legacy "export" ciphersuites it incorporates -- are pure poison, and simply having these active on a server is enough to invalidate the security of all connections made to that device.
So this essentially means that if you have any services with SSLv2 enabled (e.g. mail server) that share the same private key as other non-SSLv2 enabled services (e.g. web), that can be used to decrypt your TLS traffic. Time to check all services have SSLv2 disabled (this means not just disabling the ciphers, but fully disabling SSLv2 and SSLv3).
The certificate, which is installed in the system's certificate store under the name "eDellRoot", gets installed by a software called Dell Foundation Services. This software is still available on Dell's webpage. According to the somewhat unclear description from Dell it is used to provide "foundational services facilitating customer serviceability, messaging and support functions".
While Dell claims that this was provided to provide user support and there is no evidence it is being used to inject ads like in the case of Superfish, this is still a huge security issue as anybody with access to the private key (which has already been extracted and posted online) can now perform MITM attacks on any user with the eDellRoot CA installed.
The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack is reminiscent of the FREAK attack, but is due to a flaw in the TLS protocol rather than an implementation vulnerability, and attacks a Diffie-Hellman key exchange rather than an RSA key exchange. The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.
Yet another vulnerability allowing an attacker to downgrade the TLS connection to use weaker ciphers. The solution in this case is easy:
- Generate strong DH group: openssl dhparam -out /etc/nginx/certs/dhparams.pem 2048
- Configure web server (e.g. with nginx): Add ssl_dhparam /etc/nginx/certs/dhparams.pem; to nginx.conf
On Friday, March 20th, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by an intermediate certificate authority apparently held by a company called MCS Holdings. This intermediate certificate was issued by CNNIC.
CNNIC is included in all major root stores and so the misissued certificates would be trusted by almost all browsers and operating systems. Chrome on Windows, OS X, and Linux, ChromeOS, and Firefox 33 and greater would have rejected these certificates because of public-key pinning, although misissued certificates for other sites likely exist.
Reminder to go through all trusted Root CAs in Keychain Access / Certificate Manager tools and delete/untrust all "shady" roots (CNNIC, Turktrust, etc.)