[liberationtech] A simple SSL tweak could protect you from GCHQ/NSA snooping

[Eduardo Robles Elvira]

Hello!

Thanks, this is just in time, I'll try to use Elliptic Curve
cryptography (ECDHE) whenever possible =)

Kind regards,

On Thu, Jun 27, 2013 at 12:05 PM, Eugen Leitl <eugen at leitl.org> wrote:
>
> (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 companys at stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech

--
Eduardo