Opportunistic encryption

This article may be deleted soon.
	To oppose or discuss a nomination, please go to CZ:Proposed for deletion and follow the instructions. For the monthly nomination lists, see Category:Articles for deletion. 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, but opportunistic encryption tries to encrypt wherever possible. The reasoning behind it is that a secure encrypted connection is almost always preferable to an insecure connection, so encryption should be the default, used whenever 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 unencypted 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 N2. 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. The concept of opportunistic encryption can be applied at any level of the protocol stack. The most widespread application is for SMTP mail transfers, described in the next section. The most general effects are obtained by applying OE at the IP level; this is covered in the OE for IP section. There are also systems which apply the OE principle to TCP, covered in the similar projects section. Opportunistic encryption of mail 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. In both systems, some extra things are added in the SMTP setup dialog; these let either server query whether the other can handle the encryption. If both can, the link is encrypted. 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. These are not opportunistic; the user must request encryption. However, they combine nicely with Secure SMTP to give an almost end-to-end solution; the combination blocks all eavesdropping "on the wire". Note however that — unlike a genuine end-to-end method such as PGP — it does not block eavesdropping by anyone with privileged access to a mail server. There has been some recent work on an opportunistic end-to-end encryption system for email called STEED for "Secure Transmission of Encrypted Electronic Data"[1]. 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. 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. FreeS/WAN used DNS to manage authentication data. In particular, they put the authentication keys in the DNS reverse maps so that they could be looked up when all the IPsec software knows is the IP address it needs to communicate with. The DNS reverse maps also had data which supported a single OE gateway doing IPsec on behalf of a range of client addresses; the partner could discover the gateway address with DNS lookup on any client address. The technique is designed to avoid any requirement for digital certificates or a complex public key infrastructure; if you have the authority for the reverse map of an address range, then you can set up OE for that range. DNS already provides a hierarchical system for delegating control over address ranges; FreeS/WAN OE simply used that, rather than introduce complications. There are no certificates involved and no attempt is made to handle the difficult problem of binding names to cryptographic credentials. An authentication key (a plain hexadecimal string, not embedded in a certificate) and a gateway address are bound to a range of client addresses; that is all. Given those, the other end can set up an IPsec tunnel to the gateway and route all traffic for the client address range via that tunnel. Used alone, this is secure against passive eavesdroppers who only try to listen in; encrypting the connection stops them. Add DNS security to protect the authentication data and it is also secure against active attackers who try to trick systems into communicating with them instead of legitimate partners, to alter messages in transit, or to send bogus messages. DNS security protects both the keys in the reverse maps and the mapping from domain names to IP addresses in the forward maps, so (assuming both IPsec and DNS security are safe), OE with DNS security is secure against man-in-the-middle attacks and other attacks based on spoofing DNS information or packet IP addresses. FreeS/WAN-style OE without secure DNS is not secure against active attacks; you need authentication to block those attacks, and authentication data obtained from insecure DNS is not trustworthy. That said, the attacker needs a fair effort to subvert the system, even without secure DNS. First he must subvert two DNS servers, or trick the two target IPsec gateways into using the wrong DNS servers. This lets him provide bogus authentication data and set up a man-in-the-middle attack. Then he must conduct that attack, intercepting and replacing packets in the Internet Key Exchange (IKE) protocol. This gets him the encryption and authentication keys for the Encapsulated Security Payload (ESP) protocol. At that point, all is lost; the enemy can both read the encrypted traffic and forge messages that the recipient systems will accept as genuine. However, it may not be permanently lost. The keys for ESP are changed regularly and OE always uses the perfect forward secrecy option in IPsec, so every time those keys change, the attacker must conduct another successful man-in-the-middle attack on IKE to get the new keys. In short, even without DNS security, FreeS/WAN-style OE is secure against all passive attackers (anyone just eavesdropping) and an active attack against it needs significant skill and resources. 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." They have a novel authentication technique based on "IPv6 Anycast, Authorization certificates and Crypto-Based Identifiers (CBID)". 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. Projects with similar goals OE at the IP level offers one way to encrypt more-or-less the entire net, but it is not the only way. There are other projects which have similar aims. Better-than-Nothing Security or BTNS is IPsec done without authentication; one of the RFC authors was a former FreeS/WAN team member. This gives basically the same security level as FreeS/WAN-style OE done without DNS security; it is secure against passive attacks, but not against active attacks. However, since BTNS does not use authentication at all, active attacks against it are simpler than against FreeS/WAN-style OE. There are also systems which apply opportunistic techniques to TCP connections, Google's obfuscated TCP and the later TCP crypt. These too are secure against passive attacks but vulnerable to active attacks, in particular to man-in-the-middle attacks. The EFF project HTTPS Everywhere aims at encrypting most web traffic by making https the default, always trying that first and only falling back to http if that fails. This is essentially opportunistic; it makes the browser use https encryption whenever the server supports it. HTTPS Everywhere resists passive attacks and moreover is secure against active attacks provided that the SSL protocol underlying https is. SSL is designed to be secure against such attacks, but it depends on certificates and therefore on certificate authorities and there is room for considerable doubt about some certificate authorities. If an authority were subverted, then a man-in-the-middle attack using bogus certificates would be possible. References