Opportunistic encryption

Opportunistic encryption, often abbreviated OE is the attempt to arrange network communication systems so that any two nodes can encrypt their communication, without any connection-specific setup by the system administrators. Once two machines are set up for OE, they can set up secure connections automatically. Other encryption systems aim at providing encryption wherever necessary. OE has a different aim; it is opportunistic and will encrypt wherever possible.

Some encryption systems come into play only when the user asks for encryption, for example applying PGP to an email message (instead of sending in the clear), logging in to a remote system with SSH (instead of unencrypted telnet), or requesting an encrypted web connection by using https (instead of just http). Some infrastructure is required — you must know the recipient's key for PGP, have the password to log in with SSH, and check the server's certificate for https.

For other systems, administrators must configure each connection which is to be encrypted. For example, in building a VPN between two offices, the administrators on the two ends must co-operate to set up the connection. If you want your laptop to connect either to a wireless access point or to your office VPN, then you need to get some information from the system administrator and configure your machine to match; at the very least, you need a password and there may be other things to set up. In these cases, you are being the second administrator configuring your end of the connection. Alternately, you might give the laptop to your IT staff and let them set it up, but in any case someone has to set up both ends of each connection.

Opportunistic encryption aims to avoid all that. Once a machine is set up for OE, it automatically checks whether the other end of any connection is capable of OE. If so, the two machines automatically set up an encrypted connection. This works without any user requests and without any need for administrators to configure connections. It even works when the two administrators have had no contact with each other. Of course, there is still some administrative work involved; the machines must be set up for OE and related policies set. An important policy decision is what to do if OE fails — communicate in the clear or refuse the connection.

One benefit is a reduction in administrative workload. If the administrators must set up every connection, worst case effort for a network of N machines scales by N². Of course, some networks are simpler; if all you need is N machines connecting to a single server or wireless access point, then you need only set up N+1 devices. However, for N machines with everyone able to talk to everyone, there are $N(N-1)/2$ connections; if you must configure each of them and N is large, this becomes highly problematic. There are several ways to avoid this disaster on large networks. A centralised authentication system such as Kerberos can manage authentication and keying for many machines, a public key infrastructure may help (though it also brings its own complications), and a few strategically placed encryption devices — whether hardware encryption at link level or IPsec gateways at network level — can provide an encryption service to many clients. These techniques can often reduce the workload to something manageable. However, none of them scales very well to a large heterogeneous network such as the Internet.

OE, however, cuts the Gordian knot. For OE, the effort scales linearly; the work to set up N machines so that any of them can communicate securely with any other for OE is just N. Once OE is set up, any two OE-capable machines can secure their connections. This could, at least in theory, scale to the whole Internet. This was a large part of the political motivation for FreeS/WAN, the project that invented OE; their goal was to encrypt a large portion of the Internet and block various government monitoring programs. If OE were sufficiently widespread, then secure connections could be the default, more-or-less everything would be encrypted, and monitoring the net would become nearly impossible. This is what the cypherpunks on the FreeS/WAN project wanted to achieve.

Like any encryption scheme, an OE system must rely on some form of source authentication. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details.

Opportunistic encryption for IP

The term "opportunistic encryption" comes from the FreeS/WAN project, who built OE into a Linux implementation of IPsec and wrote an RFC documenting the design. They relied on DNS to manage authentication data. Used alone, this would be secure against passive attacks; add DNS security to protect the authentication data and it is also secure against active attacks.

Another way to use IPsec with reduced administrative overheads is better-than-nothing security or BTNS, IPsec done without authentication. This gives the same security level as OE done without DNS security.

Normal IPsec, FreeS/WAN-style OE and BTNS are all secure against passive eavesdroppers who only try to listen in; encrypting the connection stops them. Normal IPsec, or OE with secure DNS, are also secure against active attackers who try to trick systems into communicating with them instead of legitimate partners. BTNS, or OE without secure DNS, are not; you need authentication to block those attacks.

The Planete project are building OE for IPv6. They claim "Unlike existing schemes (e.g. FreeS/WAN), our proposal does not rely on any global Third Trusted Party (such as DNSSEC or a PKI). Hence, we claim it is more secure, easier to deploy and more robust."

OE done at the IP layer of the protocol stack protects everything above that layer, and does so without any assistance from higher-layer protocols and generally entirely transparently to the users.

Opportunistic encryption of other protocols

The most widely deployed OE system encrypts server-to-server SMTP mail transfers. The original implementation was ssmail or Secure Sendmail , which built encryption into the mail server code. The current standard instead relies on TLS. This does not provide all of the benefits of end-to-end mail encryption systems such as PGP; in particular it provides no protection against an enemy with privileged access to one of the mail servers involved, or against someone monitoring the connection between the user and the mail server. However, it does prevent attacks at routers between the mail servers. It provides partial protection against wholesale mail monitoring, forcing a government that wants to do large-scale monitoring either to subvert mail servers or to get the server owners to co-operate.

There are also TLS-based systems for encrypting the link between user and mail server.

There are also systems which apply OE to TCP connections, Google's obfuscated TCP and the later TCP crypt. These are secure against passive attacks but vulnerable to man-in-the-middle attacks.