TLS
TLS and Gmail delivery
I’m seeing some questions about TLS and Gmail. Folks are seeing a correlation between sending without TLS and the mail going to bulk.
The feds are deploying DMARC
The US National Cybersecurity Assessments & Technical Services Team have issued a mandate on web and email security, including TLS+HSTS for web servers, and STARTTLS+SPF+DKIM+DMARC for email.
It’s … pretty decent for a brief, public requirements doc. It’s compatible with a prudent rollout of email authentication.
August 2017: The month in email
Hello! Hope all are keeping safe through Harvey, Irma, Katia and the aftermath. I know many people that have been affected and are currently out of their homes. I am proud to see so many of my fellow deliverability folks are helping our displaced colleagues with resources, places to stay and money to replace damaged property.
Here’s a mid-month late wrapup of our August blog posts. Our favorite part of August? The total eclipse, which was absolutely amazing. Let me show you some pictures.
Ok, back to email.
We’re proud of the enormous milestone we marked this month: ten years of near-daily posts to our Word to the Wise blog. Thanks for all of your attention and feedback over the past decade!
In other industry news, I pointed to some interesting findings from the Litmus report on the State of Email Deliverability, which is always a terrific resource.
I also wrote about the evolution of filters at web-based email providers, and noted that Gmail’s different approach may well be because it entered the market later than other providers.
In spam, spoofing, and other abuse-related news, I posted about how easy it is for someone to spoof a sender’s identity, even without any technical hacks. This recent incident with several members of the US presidential administration should remind us all to be more careful with making sure we pay attention to where messages come from. How else can you tell that someone might not be wholly legitimate and above-board? I talked about some of what I look at when I get a call from a prospective customer as well as some of the delightful conversations I’ve had with spammers over the years.
In the security arena, Steve noted the ongoing shift to TLS and Google’s announcement that they will label text and email form fields on pages without TLS as “NOT SECURE”. What is TLS, you ask? Steve answers all your questions in a comprehensive post about Transport Layer Security and Certificate Authority Authorization records.
Also worth reading, and not just for the picture of Paddington Bear: Steve’s extremely detailed post about local-part semantics, the chunk of information before the at sign in an email address. How do you choose your email addresses (assuming they are not assigned to you at work or school…)? An email address is an identity, both culturally and for security purposes.
In subscription best practices — or the lack thereof — Steve talked about what happens when someone doesn’t quite complete a user registration. Should you send them a reminder to finish their registration? Of course! Should you keep sending those reminders for 16 months after they’ve stopped engaging with you? THE SURPRISING ANSWER! (Ok, you know us. It wasn’t that surprising.)
Mandatory TLS is coming
Well, not exactly mandatory but Chrome will start labeling any text or email form field on a non-TLS page as “NOT SECURE”.
Chrome 62 will be released as stable some time around October 24th. If you want to avoid the customer support overhead then, regardless of whether any of the information on a form is sensitive, you should probably make sure that all your forms are accessible via TLS and redirect any attempt to access them over plain http to https. You can do that globally for a whole site pretty easily, and there’s not really any downside to doing so.
I still have half a dozen sites I need to convert to supporting TLS – the cobbler’s children have no shoes – and I’m beginning to feel a little urgency about it.
There’s more information in Google’s announcement, their checklist of how to set up TLS, and some background at Kaspersky Labs.
TLS certificates and CAA records
Transport Layer Security (TLS) is what gives you the little padlock in your browser bar. Some people still call it SSL, but TLS has been around for 18 years – it’s time to move on.
TLS provides two things. One is encryption of traffic as it goes across the wire, the other is a cryptographic proof that you’re talking to the domain you think you’re talking to.
The second bit is important, as if you can’t prove you’re talking to, for example, your bank you could really be talking to a malicious third party who has convinced your browser to talk to their server instead of your bank which makes the encryption of the traffic much less useful. They could even act as a man-in-the-middle and pass your traffic through to your bank, so that you wouldn’t notice anything wrong.
When your browser connects to a website over TLS it, as part of setting up the connection, fetches a “TLS certificate” from the server. That certificate includes the hostname of the server, so the browser can be sure that it’s talking to the server it thinks it is.
How does the browser know to trust the certificate, though? There’s not really a great way to do that, yet. There’s a protocol called DANE that stores information in DNS to validate the certificate, much the same as we do with DKIM. It’s a promising approach, but not widely supported.
What we have today are “Certificate Authorities” (CAs). These are companies that will confirm that you own a domain, issue you a certificate for that domain where they vouch for it’s authenticity (and usually charge you for the privilege). Anyone can set themselves up as a CA (really – it’s pretty trivial, and you can download scripts to do the hard stuff), but web browsers keep a list of “trusted” CAs, and only certificates from those authorities count. Checking my mac, I see 169 trusted root certificate authorities in the pre-installed list. Many of those root certificates “cross-sign” with other certificate authorities, so the actual number of companies who are trusted to issue TLS Certificates is much, much higher.
If any of those trusted CAs issue a certificate for your domain name to someone, they can pretend to be you, secure connection padlock and all.
Some of those trusted CAs are trustworthy, honest and competent. Others aren’t. If a CA is persistently, provably dishonest enough then they may, eventually, be removed from the list of trusted Certificate Authorities, as StartCom and WoSign were last year. More often, they don’t: Trustwave, MCS Holdings/CNNIC, ANSSI, National Informatics Center of India (who are currently operating a large spam operation, so …).
In 2011 attackers compromised a Dutch CA, DigiNotar, and issued themselves TLS Certificates for over 500 high-profile domains – Skype, Mozilla, Microsoft, Gmail, … – and used them as part of man-in-the-middle attacks to compromise hundreds of thousands of users in Iran. Coverage at the time blamed it on “DigiNotar’s shocking ineptness“.
In 2015 Symantec/Thawte issued 30,000 certificates without authorization of the domain owners, and even when they issued extended validation (“green bar”) certificates for “google.com” they weren’t removed from the trusted list.
So many CAs are incompetent, many are dishonest, and any of them can issue a certificate for your domain. Even if you choose to use a competent, reputable CA – something that’s not trivial in itself – that doesn’t stop an attacker getting certificates for your domain from somewhere else.
This is where CAA DNS records come in. They’re really simple and easy to explain, with no fancy crypto needed to set them up. If I publish this DNS record …
Protocol-relative URLs in email
When you link to an external resource – an image, a javascript file, some css style – from a web page you do so with a URL, usually something like “https://example.com/blahblah.css” or “http://example.com/blahblah.css”.
The world is beginning to go all https, all the time, but until recently good practice was to make a web page available via both http and https.
The problem is that if you try and load a resource from an http URL from a page that was loaded via https it’ll complain about it, and not load the resource.
And if your users web browser is loading the http version of your page because it’s Internet Explorer 6 and doesn’t speak modern SSL then it’ll be unable to load anything over https, including any of your resources.
So whether you choose https or http protocol for loading your page resources it’s going to break for someone.
One common trick to avoid the problem is to use a protocol-relative URL. That looks like “//example.com/blahblah.css”, and it’ll load the resource over the same protocol that the page was loaded over.
While we can safely use “https://…” everywhere now, “//…” URLs are still a common idiom for things like loading things like CSS libraries from public content-distribution networks as well as your own resources.
I was reading long-but-excellent writeup about Stack Overflow’s migration to TLS (hey, I read this sort of stuff for fun) and they point out something I hadn’t considered – mail clients don’t really have any sensible way to use protocol-relative URLs. The mail client loaded the “page” from a mailbox and so has no base document protocol to work from (even if there’s a <base> element in the content it’s not likely to affect a mail client). If the user is reading it via webmail or a mail client that’s using an embedded web browser to render HTML it might work, sometimes, but it’s not going to reliably load that resource in general.
So, if you’re copy-pasting content from your web collateral to reuse in an email, make sure you’re not loading anything external – including images – via a “//…” style URL. Rewrite them to use “https://…”.
June 2016: The Month in Email
We’re officially halfway through 2016, and looking forward to a slightly less hectic month around here. I hope you’re enjoying your summer (or winter, for those of you in the Southern Hemisphere).
Comodo, TLS certificates and business ethics
We run a lot of our own infrastructure at Word to the Wise. Our email and web presence runs on our own hardware, in our own cabinet in our own network space. Partly that’s because we’re all from very technical backgrounds, and can run them in a way that’s better suited to our needs than an off-the-shelf web service. Partly it’s so we can do things like add instrumentation to our inbound mail stream so we have easy access to information when diagnosing a customer’s delivery issues. But it’s also partly so we can keep up to date on protocols and software, and leaven our advice to clients with some first hand, real world experience.
One of those things is TLS certificates, for webservers and email servers.
We already used Comodo for code-signing certificates, so when their sales rep called me and offered some decent pricing of extended validation (EV or “green bar”) certificates in exchange for a three-year commitment that seemed like a good opportunity to experience the extended validation process.
I’ve written previously about how painful the process of getting a TLS certificate from a legacy certification authority such as Comodo is, but this post isn’t about that.
I mentioned a few months ago that our green bar TLS certificate would be going away. That was because Comodo didn’t honor their agreement with us. While we ordered three years of EV certificate from Comodo, paid them for three years of EV certificate and confirmed in writing with the sales rep that they would provide three years of EV certificate, after one year Comodo decided that they wouldn’t honor that agreement.
The sales rep was mysteriously “no longer with the company” and his sales manager decided that they’d keep the money, but not provide the agreed to certificates. After a dozen or so promised calls back or email replies from a “sales manager” to discuss “what they could do for us” didn’t happen, we gave up on Comodo and switched to using Lets Encrypt for our TLS certificates.
We’re very, very happy with Let’s Encrypt. The price of “free” is nice, but it’s the simplicity, reliability and general lack of having to deal with horrible sales reps that’s the best thing.
Apparently a lot of other Comodo customers thought the same thing, as Comodo seems to want to recapture those customers by pretending to be Let’s Encrypt. They filed trademark registrations for “Let’s Encrypt”, “Comodo Let’s Encrypt” and “Let’s Encrypt with Comodo”. Comodo is in the business of “trust” and “identity” and I can’t think of any behaviour of theirs more antithetical to that.
And, on an email note, Comodo also seemed to decide that they didn’t want their employees to know about this, nor to answer questions about it, and reportedly configured their email filters to reject email mentioning letsencrypt.org with “mail contains a virus”.
— from Peter Stenberger, on twitter
(Given Comodo are a major email filter vendor I hope that that’s just a local configuration used by Comodo themselves, not part of their public filtering products.)
We will no longer be using or recommending Comodo as a vendor.
(This post brought to you as an exercise in avoiding the question “What effect will brexit have on the email industry?”, as the answer “Global economic collapse would probably be bad for the email industry, yes.” seems a little simplistic.)
Google drops obsolete crypto
Google is disabling support for email sent using version 3 of SSL or using the RC4 cypher.
They’re both very old – SSLv3 was obsoleted by TLS1.0 in 1999, and RC4 is nearly thirty years old and while it’s aged better than some cyphers there are multiple attacks against it and it’s been replaced with more recent cyphers almost everywhere.
Google has more to say about it on their security blog and if you’re developing software you should definitely pay attention to the requirements there: TLS1.2, SNI, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, DNS alternate names with wildcards.
For everyone else, make sure that you’ve applied any patches your vendor has available well before the cutoff date of June 16th.
Gmail showing authentication info
Yesterday Gmail announced on their blog they would be pushing out some new UI to users to show the authentication and encryption status of email. They are trying to make email safer.
There are a number of blog posts on WttW for background and more information.
Clickthrough forensics
When you click on a link in your mail, where does it go? Are you sure?
HTTP Redirects
In most bulk mail sent the links in the mail aren’t the same as the page the recipients browser ends up at when they click on it. Instead, the link in the mail goes to a “click tracker” run by the ESP that records that that recipient clicked on this link in this email, then redirects the recipients web browser to the link the mail’s author wanted. That’s how you get the reports on how many unique users clicked through on a campaign.
In the pay-per-click business that’s often still not the final destination, and the users browser may get redirected through several brokers before ending up at the final destination. I walked through some of this a few years ago, including how to follow link redirection by hand.
HTTP Forensics
Evil spammers sometimes deploy countermeasures against that approach, though – having links that will only work once or twice, or redirects that must be followed within a certain time, or javascript within an intermediate page or any of a bunch of other evasions. For those you need something that behaves more like a web browser.
For serious forensics I might use something like wireshark to passively record all the traffic while I interact with a link from inside a sandboxed browser. That’s not terribly user-friendly to use or set up, though, and usually overkill. It’s simpler and usually good enough to use a proxy to record the web traffic from the browser. There are all sorts of web proxies, used for many different things. What they have in common is that you configure a web browser to talk to a proxy and it’ll send all requests to the proxy instead of to the actual website, allowing the proxy to make any changes it wants as it forwards the requests on and the results back.
For investigating what a browser is doing the most useful proxies are those aimed at either web developers debugging web apps or crackers penetration testers compromising web apps. Some examples are Fiddler (Windows), Cellist (OS X, commercial), mitmdump (OS X, linux, Windows with a little work), Charles (anything, commercial) or ZAP (anything).
I’m going to use mitmdump and Firefox. You don’t want to use your main browser for this, as the proxy will record everything you do in that browser while you have it configured – and I want to keep writing this post in Safari as I work.
Lets Encrypt Everything
Using SSL TLS to protect data in transit and authenticate servers you contacted originally required specialized software, complex configuration and expensive and complicated to require certificates.
The need for specialized software is long since gone. Pretty much every web server and mail server will support SSL out of the box.
Basic server configuration is now pretty simple – give the server a couple of files, one containing the TLS certificate and the other the associated private key. (Configuring a server securely, avoiding a variety of attacks on weak parts of the SSL/TLS protocol, can be a bit more work, but there are a lot of tools and documentation to help with that).
But acquiring a certificate from a reputable provider is still expensive enough (one Certificate Authority’s list price for entry level certificates is $77/year, though the same certificates are available for <$10/year from resellers, which tells you a lot about the SSL certificate market) that you might not want to buy one for every endpoint.
And the process of buying an SSL certificate is horrible.
First you have to find a Certificate Authority or, more likely, a cheap reseller. Then it requires generating a “Certificate Signing Request” – something that can be done in dozens of different ways, depending on the device it’s being generated for. The user-friendliest way I’ve found to do it is to use the openssl commandline tools – and that’s really, really not very friendly.
Then you need to log in to the CA, upload the CSR, follow a bunch of directions to confirm that you are who you say you are and you’re entitled to a certificate for the domain you’re asking for. That can be as simple uploading a file to a webserver that serves the domain you’re getting a certificate for. Or it can turn into an inquisition, where the CA requires your home address and personal phone number before they’ll even talk to you.
Then you need to use the same browser you submitted the CSR request from to get your certificate – as the CA doesn’t do all the cryptography itself, it relies on your web browser for some of it. There are some security-related reasons why they chose to do that, but it makes for a fragile – and near impossible to automate – process. And the attempts to upsell you to worthless “security” products are never-ending.
There’s probably more horribleness, but it’s 9 months since I last bought a certificate and I may have forced myself to forget some of the horror.
There’s no need for it to be that painful. It’s easy to mechanically prove to a Certificate Authority that you control a domain in the same way you prove ownership to other companies – put a file the CA gives you onto the webserver, or add a special CNAME to your DNS.
And once you’ve proved you own a domain a certificate for that domain could be generated completely automatically. For the most common web setups you could even prove domain ownership, generate a new certificate and install that certificate into the webserver entirely automatically.
I’m sure there’s some reason other than “because we’re milking the SSL cash cow for all it’s worth” that dealing with most Certificate Authorities is so painful and expensive. But there’s no need for them to be that way.
This year there’ve been several groups who have stepped forward to escape the pain of dealing with legacy Certificate Authorities, at least for basic domain verified TLS certificates (as opposed to the “green bar” extended verification certificates you might want for, e.g. an eCommerce site).
Lets Encrypt has been one of the higher profile new CAs who are driving this effort. With the help of ACME, an open protocol being developed for issuing certificates automatically, they’re providing zero-cost TLS certificates. They’re hoping that, to use their phrase, you’ll encrypt everything, using TLS to encrypt traffic everywhere it makes sense to do so.
So, how does it work?
It works wonderfully well.
Lets Encrypt is still in public beta testing for a few more weeks, but I just got beta access. Installing their client tool on a reasonably recent Linux box just took copy-pasting two commands and waiting a minute.
The tool supports a variety of different ways to request a certificate – from entirely automated for a vanilla Apache installation through to the most complicated, entirely manual.
To see how difficult it was I decided to install a certificate for blighty.com, a domain on one of our very old webservers – one that was too old to install the letsencrypt tool itself. Fully manual! For a website on a different server!
I ran the letsencrypt tool, telling it I wanted a certificate for blighty.com. It gave me a the contents and location of a file to put on the blighty.com webserver – creating that required copying and pasting two commands from one shell window to another. Then it created and gave me the new certificate and key. I copied those across to the webserver and reloaded it’s configuration. And I have TLS!
This is going to be very simple to completely automate, so you could easily build it in to existing automation to create TLS protected action and tracking links for branded domains. Supporting thousands of TLS protected hostnames wouldn’t be difficult.
And how about using the certificates for things other than webservers? Mail servers, say? You do need a webserver to be live while you’re generating or renewing a certificate – but that’s actually easier to do for a host that doesn’t usually serve web pages than one that does. Once the certificate is generated you can use it for any service, including mail servers.
Cryptography and Email
A decade or so ago it was fairly rare for cryptography and email technology to intersect – there was S/MIME (which I’ve seen described as having “more implementations than users”) and PGP, which was mostly known for adding inscrutable blocks of text to mail and for some interesting political fallout, but not much else.
That’s changing, though. Authentication and privacy have been the focus of much of the development around email for the past few years, and cryptography, specifically public-key cryptography, is the tool of choice.
DKIM uses public-key cryptography to let the author (or their ESP, or anyone else) attach their identity to the message in a way that’s almost impossible to forge. That lets the recipient make informed decisions about whether to deliver the email or not.
DKIM relies on DNS to distribute it’s public keys, so if you can interfere with DNS, you can compromise DKIM. More than that, if you can compromise DNS you can break many security processes – interfering with DNS is an early part of many attacks. DNSSEC (Domain Name System Security Extensions) lets you be more confident that the results you get back from a DNS query are valid. It’s all based on public-key cryptography. It’s taken a long time to deploy, but is gaining steam.
TLS has escaped from the web, and is used in several places in email. For end users it protects their email (and their passwords) as they send mail via their smarthost or fetch it from their IMAP server. More recently, though, it’s begun to be used “opportunistically” to protect mail as it travels between servers – more than half of the mail gmail sees is protected in transit. Again, public-key cryptography. Perhaps you don’t care about the privacy of the mail you’re sending, but the recipient ISP may. Google already give better search ranking for web pages served over TLS – I wouldn’t be surprised if they started to give preferential treatment to email delivered via TLS.
The IETF is beginning to discuss end-to-end encryption of mail, to protect mail against interception and traffic analysis. I’m not sure exactly where it’s going to end up, but I’m sure the end product will be cobbled together using, yes, public-key cryptography. There are existing approaches that work, such as S/MIME and PGP, but they’re fairly user-hostile. Attempts to package them in a more user-friendly manner have mostly failed so far, sometimes spectacularly. (Hushmail sacrificed end-to-end security for user convenience, while Lavabit had similar problems and poor legal advice).
Not directly email-related, but after the flurry of ESP client account breaches a lot of people got very interested in two-factor authentication for their users. TOTP (Time-Based One-Time Passwords) – as implemented by SecureID and Google Authenticator, amongst many others – is the most commonly used method. It’s based on public-key cryptography. (And it’s reasonably easy to integrate into services you offer).
Lots of the other internet infrastructure you’re relying on (BGP, syn cookies, VPNs, IPsec, https, anything where the manual mentions “certificate” or “key” …) rely on cryptography to work reliably. Knowing a little about how cryptography works can help you understand all of this infrastructure and avoid problems with it. If you’re already a cryptography ninja none of this will be a surprise – but if you’re not, I’m going to try and explain some of the concepts tomorrow.
TLS and Encryption
Yesterday I talked about STARTTLS deployment, and how it was a good thing to support to help protect the privacy of your recipients.
STARTTLS is just one aspect of protecting email from eavesdropping; encrypting traffic as the mail is being sent or read and encrypting the message itself using PGP or S/MIME are others. This table shows what approaches protect messages at different stages of the messages life:
[table nl=”~”]
Compromise point,SUBMIT~+IMAPS,TLS,PGP /~SMIME
Sender’s computer as mail is sent,,,
Sender’s computer later,,,[icon name=check-square]
Sender’s network,[icon name=check-square],,[icon name=check-square]
Sender’s ISP,,,[icon name=check-square]
Global Internet (passive),,[icon name=check-square],[icon name=check-square]
Global Internet (active),,[icon name=question-circle],[icon name=check-square]
Global Internet (later),,[icon name=question-circle],[icon name=check-square]
3rd party mail services,,,[icon name=check-square]
Recipient’s ISP,,,[icon name=check-square]
Recipient’s network,[icon name=check-square],,[icon name=check-square]
Recipient’s computer as mail is read,,,
Recipient’s computer later,,,[icon name=check-square]
[/table]
You can see that if you’re sending really sensitive data, you should be encrypting the entire message with PGP or S/MIME (or not sending the message via email at all). Doing so will protect the content of the mail against pretty most sorts of attack, but is pretty intrusive for the sender and recipient so can’t really be used without prior agreement with the recipient.
The other approaches will make some sorts of passive surveillance much more difficult, though.
Encrypting the connection a user uses to send mail ([rfc 6409]using the SUBMIT protocol[/rfc]) and to read mail ([rfc 2595]using TLS to protect IMAP or POP3[/rfc]) will protect against passive sniffing when the user is on possibly hostile network, such as public wifi or an employers network. That’s an easy place to try and sniff traffic, and if that traffic isn’t protected an attacker can not only read someone’s email, they can steal their credentials and cause all sorts of havoc. All general purpose mail clients and all ISPs support encryption here, so it’s almost universally used.
STARTTLS use with SMTP is all about protecting email traffic when it’s being sent between ISPs – both between the sender’s ISP and the recipient’s and also between any 3rd party mail services (outsourced spam filtering, mailing list providers, vanity domain fowarders, etc.).
I’ve listed three different sorts of attack on that inter-ISP traffic – passive, active and “later”.
A passive attack is where the attacker has the ability to listen to bytes as they go by, but isn’t able to modify or intercept them. While you might think of this as something a nation state would do, via secret agreements with backbone providers or high-tech fiber optic cable taps, there are ways a smaller attacker might be able to compromise an intermediate router and tap that traffic with little risk of detection. Deploying any sort of STARTTLS will protect against this, even if it’s misconfigured, using expired certificates or even just the default setup of a newly deployed mailserver. Facebook describe these weaker forms of STARTTLS as “opportunistic” in their survey – it’s not perfect, but it’s a lot better than nothing.
An active attack is one where the attacker has the ability to intercept and modify traffic between the two ISPs. This seems like it would be harder to do than a passive attack, but it’s often easier, though not as stealthy. Once that’s done, the attacker can pretend to be the recipient ISP and have full access to read, modify or discard messages. To protect against this sort of attack TLS needs to be used not just to encrypt the traffic in-flight, but also to allow the sender to validate that the mailserver they’re talking to really is who they think it is. This is what Facebook describe as “strict” – it requires that the mailserver have a valid certificate, issued by a legitimate certification authority for the domain that the mail is being sent to.
What about “later”? It’s easy to imagine a case where an attacker has been passively monitoring and recording encrypted traffic for a while, and then later they manage to acquire the encryption keys that were used (by, for example, issuing a subpoena to the recipient ISP, or using a compromise to rip them out of your servers memory). With many forms of encryption once you have those private keys it’s possible to decrypt all the traffic you’ve already captured. There are a few algorithms, though, that have what’s known as perfect forward secrecy – knowing the private keys that were used at the time the mail was transferred doesn’t allow you to decrypt them at a later time. If you’re concerned about the privacy of your messages, you should definitely read up on how to set that up.
All of these techniques are a great way to defend against ubiquitous or casual attempts to read your messages, but none of them are proof against a determined attacker. If all else fails, there’s always a wrench attack.
Protect your email with TLS
You probably use TLS hundreds of times a day. If you don’t recognize the term, you might know it better by it’s older name, SSL.
TLS is what protects your data in transit whenever you go to Google, or Yahoo or even this blog. The little padlock in your browser address bar tells you that your browser has used the TLS protocol to do two things. First, it’s decided that the server you’re connecting to really is operated by Google, or Yahoo or us – you’re (probably) not having your session intercepted by someone in the middle between you and the webserver, either to read your traffic or modify it en-route. Second, it is encrypting all the traffic between you and the webserver, so that it can’t be passively monitored while in transit. Because of concerns about ubiquitous surveillance many websites – including ours – are moving to use TLS for everything, not just for protecting a login page or a credit card number.
That’s great for the web, but how does it apply to email? One place it’s used is for connections between your mail client and your local mailserver – sending mail to the smarthost via [rfc 4409]SUBMIT[/rfc] and fetching mail using [rfc 2595]IMAP or POP3[/rfc] almost always use TLS. That protects the privacy of your messages between you and your ISP and also protects the username and password you use to authenticate with.
Mail traveling between ISPs didn’t used to be encrypted “on the wire” , but about 15 years ago [rfc 3207]an extension to SMTP was proposed[/rfc] that would allow ISPs to negotiate during each session whether they should encrypt it or not. This extension, often referred to as STARTTLS after the command it uses, allows gradual rollout of encryption of mail traffic between ISPs without requiring any sort of flag day. A mailserver that supports STARTTLS will tell everyone who connects to it “Hey! I support STARTTLS!”. When a smarthost that also supports it connects to that mailserver it will go “Great! I support STARTTLS too! Lets do this!” and convert the plain text SMTP session into an encrypted session protected by TLS.
Fifteen years seems like a long period in Internet time, but non-intrusive protocol changes can take a long time to deploy. Facebook Engineering have done the work to see how that deployment is going with their survey of the current state of SMTP STARTTLS deployment. The results are really quite positive – over three quarters of the mailservers they sent mail to supported STARTTLS, covering nearly 60% of their users. That’s definitely enough to make supporting STARTTLS worthwhile.
More about TLS and encryption tomorrow.