TLS 5: Reviving Anonymous Diffie-Hellman for Privacy

TLS servers often struggle with a limited amount of ports. Even when using IPv6 there may be reasons why this problems shows up; backward compatibility with IPv4 and a desire for central entrance of web traffic to your site are a few. SNItch makes it possible to switch to various backend servers based on the Server Name Indication contained in (at least) web traffic.

This article is part of a series of articles about TLS.

The Limited Privacy of TLS

It is often assumed that TLS is a silver bullet for security; that it will protect your privacy without a need to give it any further thought.

To explain that this is far from the truth, just log your network traffic with WireShark while you setup a TLS connection. If you use a website, you could use "tcp port 443" as your filter to skip other network interactions. Download a single page (possibly by hitting Reload in your browser) and stop scanning. The harvest of information is immense.

You might be surprised that the following information travels over TLS in plaintext:

  • The server name you are looking for – a statement of your interests
  • The CipherSuites that your brwoser welcomes – a statement of your security settings
  • Potentially, a client-side certificate – a strong identity statement
  • Potentially, the server's list of trusted root certificates – a vulnerability list for its account

The reason why this is exchanged in plaintext is simply that no encryption has been agreed upon during these early phases. The intent of TLS is to protect your application data, but it is careless concerning your metadata. And it is metadata that raises a concern for privacy.

Arranging TLS Privacy with Anonymous Diffie-Hellman

A possible solution to this problem of leaking metadata exists, although it is generally misunderstood to be a security risk: Anonymous Diffie-Hellman.

The AnonDH mechanism is a key agreement mechanism based on Diffie-Hellman, or its Elliptic-Curve variant. This means that it supports the attractive property of Perfect Forward Secrecy, but it also comes with the risk of MITM attacks. This risk is why AnonDH is generally advised against.

There are however, very good reasons to reinstate AnonDH in most places, if not all.

First, it is highly exceptional for TLS servers to validate their client's identity. This validation practice is limited to controlled groups of users, and has no realistic implementation on public servers. So for any normal server, it is safe to say that they don't validate the client's identity through TLS. Then, why would the *server* care for MITM attacks? This is the client's concern only, and the client is perfectly capable of not specifying AnonDH if it fears the risks.

Second, clients that do care but also want to take the extra effort of using AnonDH can renegotiate a TLS connection. This makes it possible to first encrypt a connection using AnonDH, without sharing the details provided before, and then under the cloak of AnonDH move on with the exchange of identities, CipherSuites, certificates and so on. Furthermore, if the renegotiation is done securely, the property of Perfect Forward Secrecy is retained.

The only concern remaining is that the server may start sending data before the renegotiation has taken place. If the server would not wait for the client to renegotiate TLS, then this might create problems; specifically, traffic may be injected during a MITM attack. Most service protocols however, wait for their clients to ask a question. At best they will initiate the connection with a simple banner that is so harmless that could also sent over plaintext. The contents of the banner are rarely used, other than to detect the live presence of the server.

Interestingly, the call for inclusion of Perfect Forward Secrecy through Ephemeral Diffie-Hellman introduces an extra DH or ECDH operation as part of the TLS flow, but its effects are not applied to the metadata of the TLS connection itself. Using AnonDH gives the exact same amount of cryptographic work, but its privacy is much better. The protocol overhead is small, a matter of a few more TLS messages flowing back and forth; this may however cause minor connection setup delays.

A new TLS Extension Flag

The reasoning about banners is a good stopgap measure, but it is not ideal. Ideal would be if both parties agree not to exchange any traffic before secure renegotiation of the TLS connection has progressed beyond AnonDH. The secure renegotiation detects (and thereby avoids) any MITM attacks that might have been mounted.

We propose to introduce a flag that can be sent as a TLS extension in both the ClientHello and ServerHello messages. We will call that flag "pfs_anon_setup".

The meaning of this flag is that the sending party states:

  • I will not send application_data on a stream that is only protected with AnonDH;
  • In case you send me this flag, I will raise a fatal error if you send application_data on a stream that is only protected with AnonDH.

This is a rather simple extension, but its impact is dramatic:

  • It signals to the server that AnonDH is not going to be a problem, and can be safely provided.
  • It signals to potential intermediates that they have no chance of listening in without being detected.

Concrete Proposal to Revive AnonDH

These are the things that help to setup a TLS environment with AnonDH. The trick is to permit it, and make itpreferred over Ephemeral Diffie-Hellman.

Server changes:

Ideally, the code on a server evolves for better support; but configuration suffices as a first step. This is a trivial matter, and may help to convince developers of clients to follow this initiative.

  • Accept AnonDH, and give it preference over TLS_DHE_ and TLS_ECDHE_ CipherSuites, which in turn rank higher than the non-DH CipherSuites.
  • While securely renegotiating TLS under an AnonDH cloack, the TLS_DHE_ and TLS_ECDHE_ CipherSuites may be disabled, as well as AnonDH. The current level of TLS configuration is generally not able to do this well enough, but it is reasonable to let the client take control within AnonDH, by dropping these now-senseless CipherSuites.
  • Servers should strive to implement the pfs_anon_setup extension in their TLS stacks.
  • This is one of the strategies that we will implement in our TLS Pool design.

Client changes:

Clients need to be more involved with TLS, and so their TLS logic needs some work. Since servers can so easily adopt AnonDH, this would be a very easy way to improve a protocol's security.

  • The first attempt should be the following sequence:
    • Offer AnonDH as a CipherSuite, along with the pfs_anon_setup extension.
    • If this succeeds, to renegotiate securely with CipherSuites without Diffie-Hellman.
  • If the first attempt is rejected while connecting under AnonDH, the client should reconnect:
    • Using a standard handshake, with higher preference for CipherSuites with Emphemeral DH.
    • It may be useful to include AnonDH once more as a first option.
    • It may be useful to raise a warning if AnonDH was permitted in the past, and is now suddenly dropped.
  • Do not worry about trying multiple times; browsers are already doing this today.
  • This is one of the strategies that we will implement in our TLS Pool design.
tls-5-anondh.txt · Last modified: 2014/02/24 11:47 by vanrein
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki