(for the sake of completeness) http://www.theregister.co.uk/2013/06/26/ssl_forward_secrecy/
A simple SSL tweak could protect you from GCHQ/NSA snooping It might slow you down, but hey, you can't have everything By John Leyden, 26th June 2013 Forward Secrecy An obscure feature of SSL/TLS called Forward Secrecy may offer greater privacy, according to security experts who have begun promoting the technology in the wake of revelations about mass surveillance by the NSA and GCHQ. Every SSL connection begins with a handshake, during which the two parties in an encrypted message exchange perform authentication and agree on their session keys, through a process called key exchange. The session keys are used for a limited time and deleted afterwards. The key exchange phase is designed to allow two users to exchange keys without allowing an eavesdropper to intercept or capture these credentials. Several key exchange mechanisms exist but the most widely used mechanism is based on the well-known RSA algorithm, explains Ivan Ristic, director of engineering at Qualys. This approach relies on the server's private key to protect session keys. "This is an efficient key exchange approach, but it has an important side-effect: anyone with access to a copy of the server's private key can also uncover the session keys and thus decrypt everything," Ristic warns. This capability makes it possible for enterprise security tools - such as intrusion detection and web application firewalls - to screen otherwise undecipherable SSL encrypted traffic, given a server’s private keys. This feature has become a serious liability in the era of mass surveillance. GCHQ have been secretly tapping hundreds of fibre-optic cables to tap data, The Guardian reported last week, based on documents leaked to the paper by former NSA contractor turned whistleblower Edward Snowden. The NSA also carries out deep packet inspection analysis of traffic passing through US fibre optic networks. Related revelations show that the NSA applies particular attention - and special rules - to encrypted communications, such as PGP-encrypted emails and SSL encrypted messages. Captured data should really be destroyed within five years, unless it consists of "communications that are enciphered or reasonably believed to contain secret meaning, and sufficient duration may consist of any period of time during which encrypted material is subject to, or of use in, cryptanalysis", according to the terms of a leaked Foreign Intelligence Surveillance Court order. The upshot is that intelligence agencies are collecting all the traffic they can physically capture before attempting to snoop upon encrypted content, where possible. These techniques are currently only practical for intelligence agencies but this may change over time - and those interested in protecting privacy need to act sooner rather than later, Ristic argues. "Your adversaries might not have your private key today, but what they can do now is record all your encrypted traffic," Ristic explains. "Eventually, they might obtain the key in one way or another - for example, by bribing someone, obtaining a warrant, or by breaking the key after sufficient technology advances. At that point, they will be able to go back in time to decrypt everything." The Diffie–Hellman protocol offers an alternative algorithm to RSA for cryptographic key exchange. Diffie–Hellman is slower but generates more secure session keys that can't be recovered simply by knowing the server's private key, a protocol feature called Forward Secrecy. "Breaking strong session keys is clearly much more difficult than obtaining servers' private keys, especially if you can get them via a warrant," Ristic explains. "Furthermore, in order to decrypt all communication, now you can no longer compromise just one key - the server's - but you have to compromise the session keys belonging to every individual communication session." Someone with access to the server's private key can perform an active man-in-the-middle attack and impersonate the target server. However, they can do that only at the time the communication is taking place. It is not possible to pile up mountains of encrypted traffic for later decryption. So, Forward Secrecy still creates a significant obstacle against industrial scale snooping. SSL supports Forward Secrecy using two algorithms: Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE). The main obstacle to using Forward Secrecy has been that Diffie-Hellman is significantly slower, leading to a decision by many website operators to disable the feature in order to get better performance. "In recent years, we've seen DHE fall out of fashion. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys," Ristic explains, adding that ECDHE is bit faster than DHE but still slower than RSA. In addition, ECDHE algorithms are relatively new and not as widely supported in web server software packages. The vast majority of modern browsers support ECDHE. Website admins who add support for the encryption technique would help the majority of their privacy-conscious customers and adding DHE allows Forward Secrecy to be offered to the rest. A blog post by Ristic explains how to enable Forward Secrecy on SSL web servers, a well as providing a good explanation about the technology is beneficial for privacy - as well as noting the limitations of the technique. "Although the use of Diffie-Hellman key exchange eliminates the main attack vector, there are other actions a powerful adversary could take," Ristic warns. "For example, they could convince the server operator to simply record all session keys." "Server-side session management mechanisms could also impact Forward Secrecy. For performance reasons, session keys might be kept for many hours after the conversation had been terminated. "In addition, there is an alternative session management mechanism called session tickets, which uses separate encryption keys that are rarely rotated - possibly never in extreme cases. "Unless you understand your session tickets implementation very well, this feature is best disabled to ensure it does not compromise Forward Secrecy," Ristic concludes. Ristic founded SSL Labs, a research project to measure and track the effective security of SSL on the internet. He has over time worked with other security luminaries such as Taher Elgamal, one of the creators of the SSL protocol, and Moxie Marlinspike, creator of Convergence, to tackle SSL governance and implementation issues and promote best practice. Whether sysadmins switch to more privacy-friendly key exchange methods in spite of performance drawbacks is by no means sure, but publicising the issue at least gives them the chance to decide for themselves. ® -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
