Email has no privacy assurance whatsoever
Email is short for “electronic mail”. The implication is that this is a direct metaphorical equivalent for the familiar paper process, but it just ain’t so. One of the points of departure from user expectation is the concept of a sealed envelope.
When you put a paper letter in a paper envelope and seal it, there is an expectation of privacy because someone has to physically break the seal which is difficult to do without obviously damaging the envelope. Email, by contrast has no secure envelope. It is transferred over the Internet using plain text over TCP port 25.
The implication is that anyone can read your mail without you realizing it. Most people think the only point of concern is that an attacker capturing packets at a public WiFi hotspot will snoop your mail. The most obvious countermeasure is using SSL with webmail. This is a good countermeasure as far as it goes but it only encrypts the communication between you and your post office. However the transport of your message between post offices is still going to be in plain text and will likely pass through several routers on the Internet en route.
So what? Who can tap traffic on those routers? Perhaps some uber-hacker is siphoning of traffic for analysis but man that seems like a huge amount of data to sift through and not likely worth doing, right?
Unfortunately Deep Packet Inspection is now ubiquitous. ISPs and governments, including the USA, have widely deployed hardware to capture and mine data out of unencrypted data packets passing through the Internet. Effectively that means it is safe to assume that all of your email (and other traffic) is being captured and analyzed by one or more automated systems trying to determine if it matches patterns of “bad behavior”. Deep Packet Inspection, by the way, is the mechanism that ISPs use to provide “tiered service” and detect copyright violations.
Maybe you think this sounds OK because you aren’t doing anything wrong, but consider whether you trust all of the people who have access to this data to do no evil, trust these people and algorithms to never make mistakes and trust that they never lose control of your private data.
A Modest Proposal
RFC 2478 describes a cryptographic mechanism similar to SSL for web sites that places a strong cryptographic layer over the transfer of email via SMTP. This transport layer security is widely supported by mail servers today and is the mechanism by which SMTP client programs like Microsoft Outlook, Mozilla Thunderbird and Apple Mail are able to communicate securely with an SMTP gateway. Many mail providers, like Gmail, already require (or at least offer) SMTP over TLS connections for clients sending mail.
RFC 2478 was published more than ten years ago. Most, if not all, contemporary SMTP gateways are capable of supporting secure SMTP over TLS. If all mail servers simply transferred all messages between each other with TLS encryption then nobody could read the messages except the administrators of the destination and source post offices and the intended recipients. This could be phased in over a reasonable period of time.
- SMTP in the clear becomes deprecated.
- During the deprecation period servers are configured to attempt to communicate with TLS by default.
- After some time, administrators can configure warnings in the headers and to-line like “[UNSECURED]”. This is an important user-education step.
- SMTP in the clear becomes a banned protocol and servers are forbidden from supporting it. (Testing and troubleshooting SMTP can still be done via classical telnet by using OpenSSL as a wrapper.)
- Servers will refuse connections from servers that do not offer TLS which will cause the message to bounce to the sender with a statement that their mail server is not secure.
Securing all SMTP traffic in a TLS envelope would go a long way toward restoring some reality to the baseline assumption that nobody is reading email in transit. The technology has been standardized since 1999. Why do we not have secure server-to-server mail transfer ten years later?
Like this:
Be the first to like this post.
