Encryption Everywhere?

April 20, 2016 by

Infosec Institute

This article discusses opportunistic encryption (OE) and ways to set up systems so that they will automatically encrypt whenever they can, rather than just whenever the user requests it.

Many types of encryption require a choice by the user – encrypt with PGP rather than sending email in the clear, log into a remote system with the secure shell SSH rather than insecure telnet, and so on. They also require some actions – find and verify the correct key for PGP, give a password for SSH, and so on. Some of these actions can be automated away, but many need input from the user.

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

Start Learning

• The basic idea of opportunistic encryption is that encrypted connections should be the default, communication should be encrypted whenever possible, the machines should just automatically do it. Modern encryption does not require huge resources and machines are getting faster all the time, so this is practical in many cases. It appears to be the most effective strategy against an enemy – such as the NSA or the Great Firewall of China – who collects massive amounts of data whenever they can, and it also makes things harder for other enemies. The shirt on the right, from Sophos, captures the idea.
• The trick is to set things up so that whenever both machines involved in a connection can encrypt, they will automatically do so without any user input. In general, this is a problem for systems administrators since they are the only ones with either the skills or the authorization to adjust machine or network setup. However, HTTPS Everywhere, described next, is available to any user since it requires only installing a browser add-on.

  Encrypting the web

  HTTPS Everywhere is a browser extension for Firefox, Chrome or Opera that makes the browser opportunistically try to encrypt all your web connections. If the server supports https (secure HTTP), then the browser uses that; if not, it falls back to plain HTTP.

  The EFF suggests "Encrypt the web: Install HTTPS Everywhere today." This is excellent advice; most servers can do https, and the add-on ensures that they, therefore, will.

  EFF have a progress report for the HTTPS Everywhere project, and Google's Transparency Report also includes data on which sites offer https . These reports show that many major sites – though by no means all, yet – offer https, so HTTPS Everywhere is quite definitely worth using. If there is a version for your browser, it is almost certainly worth installing. If not, consider changing browsers or just adding a more secure browser for some tasks.

  The Electronic Frontier Foundation (EFF) (a public interest advocacy group) and the Tor Project (an online anonymity service) are working together on the development of HTTPS Everywhere. They need volunteers for tasks ranging from writing software to translating documentation. The code is available in several places; perhaps the most convenient is on Github .

  HTTPS Everywhere is not entirely secure; it relies on TLS, and it inherits the problems as well as the benefits of the underlying system. For more detail, see our article on attacks against TLS .

  On the server end, one can enable HTTP Strict Transport Security (HSTS) so that the host will offer only https connections, not insecure HTTP.

  Server-to-server email encryption

• A widely-used application of opportunistic encryption is to encrypt email as it travels between mail servers; the original implementation just modified one type of mail server software and was called Secure Sendmail . The version that is now an IETF standard – so that anyone can implement it and many have – is called a SMTP Service Extension; it adds encryption to the main Internet email protocol, SMTP, using TLS.

  This does not provide end-to-end protection; if you need that, then you must use an email encryption program such as PGP. The extension protects only the server-to-server connection, not sender-to-server on one end of the path or server-to-receiver on the other, though both of those can also easily be protected with TLS.

  It also does not protect mail stored on either server; anyone with administrator privileges on either server (including privileges obtained via a hack, or an administrator responding to a warrant or a request) can read, or even alter, mail stored there. The only defense against that is end-to-end encryption as with PGP – the sender encrypts, and the receiver decrypts so no-one in between can read it – though of course even that is vulnerable to an attack that compromises either the sending or receiving machine.

  Still, if you run a mail server, then the extension should almost certainly be enabled. It does not protect against all threats, but it does significantly improve security. In particular, it stops a government scooping up gigabytes of mail traffic and sifting through it with no-one the wiser.

  Even with the extension widely used governments could still access most email, but only by getting co-operation from server admins or by breaking into servers. This would force them to be more open about their activities, getting warrants, explaining themselves to mail server owners, or risking being caught trying to break in somewhere. As I see it, this alone makes the extension worth using.

  IP-level encryption

  The group who invented Opportunistic Encryption and did the first implementation, around the turn of the century, were the Linux FreeS/WAN Project . I was a participant, as the technical writer doing most of the project's documentation. We built the first version of IPsec (Internet Protocol Security) for Linux and extended it to do OE. There is an RFC describing the system in detail.

  Many systems protect only a single application – for example, HTTPS Everywhere protects the web, and OTR protects Internet chat. Others protect only a single link – for example, the server-to-server link for SMTP, or a pair of hardware encryption gadgets that protect signals on one wire.

  However, encryption done at the IP level can protect everything running over IP. IPsec is, therefore, the usual protocol for building VPNs (virtual private networks), for example protecting the link between a company's New York and Tokyo offices; that is the main task it was designed for. It can also be used to connect a single remote machine – for example an employee's home machine or a traveler's laptop – to a network, but for that task, there are other choices such as TLS or SSH.

  Opportunistic encryption at the IP level may be the only way to protect the whole Internet. Other systems require system admins to configure each connection, which works fine for relatively small networks but becomes problematic for larger-scale work. At the scale of the Internet, let alone the developing "Internet of Things", this becomes completely disastrous.

  For opportunistic encryption, the admins only need to configure each machine and the machines then automatically build connections as required.

  A major difficulty is that encryption cannot be secure without authentication – it does you no good to encrypt messages so that only the recipient can read them if you do not know who you are talking to – and authentication is in some ways a harder problem than encryption.

  FreeS/WAN's solution was to put public keys for authentication in DNS records. They were inventing this as they went along, so their initial method was rather ad hoc. Inspired by that work, a more general method called DANE (DNS-Based Authentication of Named Entities) has since been developed; it is designed mainly for use with TLS but could be used with IPsec as well.

  An IPsec connection with DNS-based authentication (or even no authentication; see BTNS below) is secure against all passive attacks – any enemy who just intercepts packets and tries to read them – assuming the cipher used is secure. However, security against active attacks – an enemy who can alter or block your packets and send his own – requires that the authentication data used be completely trustworthy.

  For DNS data, trustworthiness can be achieved only with DNS Security , but unfortunately deployment of that has been very slow; the protocols were specified in the late 90s but are still nowhere near universally used. This was one of the problems for FreeS/WAN around the turn of the century and remains a problem today.

  In particular, if authentication is not trustworthy a man-in-the-middle attack becomes possible; the enemy deceives Alice and Bob so that they think they are talking to each other, but in fact both are talking to him. He sits in the middle, reads everything, and relays Alice's messages (possibly altered) to Bob and vice versa.

  Where possible, a man-in-the-middle attack is utterly devastating; the enemy completely controls the communication. Consider, General Alice sending an order to Major Bob; it is bad enough that the enemy can read the order, as a passive attacker who had broken the cipher could. A man-in-the-middle can do that, but he can also do far worse, for example sending Bob some completely different order and giving Alice bogus reports that appear to come from Bob.

  Fortunately, even without authentication such attacks are moderately difficult; the enemy has to be able to block some protocol packets and get his own delivered instead. This is straightforward for the administrators of the Great Firewall of China, or of the firewall at some organization that wants to monitor employee communications. It is almost certainly also possible for others – spy agencies, criminal syndicates, highly skilled hackers, ... – provided they can subvert the right router or a gateway machine. However, it is likely to be out-of-reach for lesser attackers.

  The FreeS/WAN project aimed at protecting the entire Internet that using OE and DNS-based authentication. Quoting project leader John Gilmore:

  The goal of the project is to make it very hard to tap your wide area communications. The current system provides very good protection against passive attacks (wiretapping and those big antenna farms).
  

  Active attacks ... are much harder to guard against. ...
  

  The societal benefit of building an infrastructure that protects well against passive attacks is that it makes it much harder to do undetected bulk monitoring of the population. It's a defense against police-states, not against policemen.
  

  It is interesting that this was written almost twenty years before Snowden's revelations, yet FreeS/WAN could have blocked most of the bulk monitoring he revealed. Unfortunately, FreeS/WAN's OE did not become widespread, and the project shut down in 2002 without achieving its ambitious goal.

  FreeS/WAN did leave descendants, though; Openswan is still being actively maintained and is included in many Linux distributions. Packt Publishing has a book on Openswan , one chapter of which covers the history of OE.

  Better-than-nothing

  The hard part of IPsec and several other systems is the authentication since it requires managing certificates, setting up DNS entries for FreeS/WAN-style OE, or other somewhat complex procedures. If you just do the encryption without authentication, it becomes much easier, and the connection is still encrypted, so it is still secure against all passive attacks – anyone just intercepting your packets and trying to decipher them – assuming the cipher you use is secure.

  One RFC defines a mode for IPsec without authentication, called Better-than-nothing Security (BTNS). Another gives a detailed discussion of where it is applicable. BTNS is essentially opportunistic; it will encrypt whenever both machines are set up for it. The setup is much simpler than for FreeS/WAN-style OE.

  

  Learn Applied Cryptography

  Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

  Start Learning

  BTNS is secure against all passive attacks, but security against active attacks – an enemy who can alter or block your packets and send his own – is near zero. See the discussion of FreeS/WAN authentication for details.

  Generalized opportunistic encryption

  A recent RFC discusses all the systems mentioned above, plus a few others, and puts forward the notion of multi-layer opportunistic security measures; encrypt whenever possible, since that at least blocks passive eavesdroppers, and add authentication if possible to block active attackers. The general rule is always to choose the most secure option available but never block communication because some option is not available.