SSL: Intercepted today, decrypted tomorrow

Millions of websites and billions of people rely on SSL to protect the transmission of sensitive information such as passwords, credit card details, and personal information with the expectation that encryption guarantees privacy. However, recently leaked documents appear to reveal that the NSA, the United States National Security Agency, logs very high volumes of internet traffic and retains captured encrypted communication for later cryptanalysis. The United States is far from the only government wishing to monitor encrypted internet traffic: Saudi Arabia has asked for help decrypting SSL traffic, China has been accused of performing a MITM attack against SSL-only GitHub, and Iran has been reported to be engaged in deep packet inspection and more, to name but a few.

The reason that governments might consider going to great lengths to log and store high volumes of encrypted traffic is that if the SSL private key to the encrypted traffic later becomes available — perhaps through court order, social engineering, successful attack against the website, or through cryptanalysis — all of the affected site’s historical traffic may then be decrypted at once. This really would open Pandora’s Box, as on a busy site a single key would decrypt all of the past encrypted traffic for millions of people.

There is a defence against this, known as perfect forward secrecy (PFS). When PFS is used, the compromise of an SSL site's private key does not necessarily reveal the secrets of past private communication; connections to SSL sites which use PFS have a per-session key which is not revealed if the long-term private key is compromised. The security of PFS depends on both parties discarding the shared secret after the transaction is complete (or after a reasonable period to allow for session resumption)...

http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

Boneh Publications: The most dangerous code in the world: validating SSL certificates in non-browser software

SSL (Secure Sockets Layer) is the de facto standard for secure Internet communications. Security of SSL connections against an active network attacker depends on correctly validating public-key certificates presented when the connection is established. We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries. Vulnerable software includes Amazon's EC2 Java library and all cloud clients based on it; Amazon's and PayPal's merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware - including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android - and all applications employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack. The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present developers with a confusing array of settings and options. We analyze perils and pitfalls of SSL certificate validation in software based on these APIs and present our recommendations.

via crypto.stanford.edu

Iranian hackers obtain fraudulent HTTPS certificates: How close to a Web security meltdown did we get?

"On March 15th, an HTTPS/TLS Certificate Authority (CA) was tricked into issuing fraudulent certificates that posed a dire risk to Internet security. Based on currently available information, the incident got close to — but was not quite — an Internet-wide security meltdown. As this post will explain, these events show why we urgently need to start reinforcing the system that is currently used to authenticate and identify secure websites and email systems.

There is a post up on the Tor Project's blog by Jacob Appelbaum,analyzing the revocation of a number of HTTPS certificates last week. Patches to the major web browsers blacklisted a number of TLS certificates that were issued after hackers broke into a Certificate Authority. Appelbaum and others were able to cross-reference the blacklisted certificates' serial numbers against a comprehensive collection of Certificate Revocation Lists (these CRLURLs were obtained by querying EFF's SSL Observatory databases) to learn which CA had been affected.

The answer was the UserTrust "UTN-USERFirst-Hardware" certificate owned by Comodo, one of the largest CAs on the web. Comodo has now published a statement about the improperly issued certs, which were for extremely high-value domains including google.com, login.yahoo.com and addons.mozilla.org (this last domain could be used to trojan any system that was installing a new Firefox extension, though updates to previously installed extensions have a second layer of protection from XPI signatures). One cert was for "global trustee" — not a domain name. That was probably a malicious CA certificate that could be used to flawlessly impersonate any domain on the Web..."

https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https