9 ms·

Email encryption is here – use STARTTLS everywhere

71 points by severine 8y ago

noncoml 8y ago
Sure, STARTTLS is better than nothing, but your email provider still reads your email. When we talk about email encryption, we mean end-to-end encryption.
- mehrdadn 8y ago
  > STARTTLS is not an end-to-end encryption system. [...] But for various reasons it’s hard to deploy end-to-end email encryption, and we’ve spent decades trying. Also, STARTTLS works just fine with end-to-end encryption. > Please indulge me: I think a small rant is appropriate here. There are some security specialists who think that only the perfect is acceptable. Nonsense! Requiring perfection is crazy. [...] For almost all users, email encryption with STARTTLS is a major improvement over what they had before. Let’s keep working to deploy even better systems, but let’s take partial victories where we can get them.
  - deleted 8y ago
    [deleted]
- mey 8y ago
  So you are saying you do not trust your e-mail provider to secure your email. At that point I suggest finding another provider or running your own service. This secures a significant point of interception and modification of data.
  - robjan 8y ago
    In general, if a government asks your provider for access to your emails then will hand them over. The only way to mitigate this threat is to use e2e encryption or host the email server on premises but then you start encountering deliverability issues.
    - arpa 8y ago
      That's FUD. If a system is correctly set up, you'll have no deliverability issues. Edit: srsly guys, HACKER news people say that it's impossible for a person to have a proper mailserver set up? That's hilarious, if not sad!
      - CyberShadow 8y ago
        This is just not true. The Internet is full of stories of people having trouble with large email providers (notably Google and Microsoft) accepting self-hosted users' mail. A self-hosted setup's IP starts with 0 reputation (or worse, depending on who owned the IP address beforehand) and will face throttling and outright blocking for a painful amount of time. Furthermore, if you forward your email to e.g. a Gmail inbox, any spam sent to your address will go towards lowering the reputation of your forwarder, meaning that someone just has to send you a lot of spam to get your forwarder blocked from Google servers. SPF, DKIM, DMARC and TLS all cannot mitigate the above.
        arpa 8y ago
        Point 1: spf, dkim, dmarc is enough to get yourself neutral with gmail. You have to do it from get-go tho, before you tarnish your reputation. Being in DNSBL lists does not help either. Set up proper reverse dns entries also. Tls is completely optional. Haven't had any trouble neither with gmail nor ms using both residential and datacenter ips in two EU countries. I don't consider myself a hardcore linux admin specialising in mail, so there's that. As far as the second point, about forwarding spam goes, you're running a mailserver without spamassasin? What is this, the 1990s?
        CyberShadow 8y ago
        > you're running a mailserver without spamassasin? What is this, the 1990s? More like, relying on SpamAssassin to reliably and correctly classify spam is the anachronism here. Even if SpamAssassin could do a good job of filtering spam today (which it can't), the set of messages that SpamAssassin classifies as spam will inevitably differ from the set of messages that Gmail classifies as spam, so the only thing this achieves is another point where you have to worry about false positives and training the classifiers. Furthermore, the problem is exacerbated by poor support of forwarding in modern MTAs. They will queue all received messages first, and when Gmail rejects certain messages during the IMAP session (spam with high confidence, or messages it considers invalid), they result in a bounce, and the thus ensuing backscatter further degrades your mail server's reputation. The closest thing to correct behavior is Exim's cutthrough delivery feature, which has been implemented "relatively" recently, and even so it is not complete and I've run into issues with it with non-textbook setups.
  - deleted 8y ago
    [deleted]
- arpa 8y ago
  I am my own provider. It's really not that hard to configure a mail server. Other peoples' providers, however... so I tried using PGP. It's somehow manages to be more difficult to use than configuring and running your own mailsystem which doesn't deliver straight to gmails' spam folder, but I digress; but then my emails are at mercy of the end devices: who knows if outlook doesn't send a plaintext email home as "telemetry"? Same thing about chrome with all the extensions for using PGP... I mean, security is hard as-is, but security of an ubiquitous thing, especially when people have been conditioned to undervalue security and privacy, is a lost cause. It's best to treat emails as being in the same category as phone calls, conversations in subway and sms'es - public.
  - selectodude 8y ago
    Also all of your emails get kicked to spam when you host your own.
    - mrb 8y ago
      You can perfectly "host your own email server" while sending outgoing mail through a smart host. No falsely-tagged-spam issue that way.
      - deleted 8y ago
        [deleted]
      - techsupporter 8y ago
        No, in my experience, selectodude is right. I've written this rant before but I think it's worth sharing repeatedly, so here goes again: The big players (Google, in particular...in case it's not clear, the bulk of this rant is leveled at Google; Microsoft is an offender on perhaps 25% of the level, Yahoo just doesn't seem to care) have ZERO interest in "playing nice" with small e-mail servers. My experience running my own e-mail for almost twenty years then finally throwing in the towel and migrating to Fastmail not only proves this for me, but is, according to other sysadmins I've talked to, quite common. I did everything right when hosting my e-mail. I did it for myself and maybe four others. The volume of mail going out of my server was so low, I could read the outbound mail.log for myself, and routinely did. Every domain had SPF, DKIM, and DMARC records. The outgoing single IPv4 and IPv6 addresses I used had perfectly-matching forward and reverse DNS lookups. I had a script that checked every blacklist I could find every 24 hours. My IP addresses were allocated from my (professional) colocation provider and SWIP'd to me with valid contact information. My IP addresses had been unchanged for seven years and had been stable for ten years prior to that change. My colo provider had a draconian non-spam policy. Nobody ran an e-mail list or anything. I've used the exact same domain for e-mail for over twenty years. Still, every couple of months, Google (sometimes Microsoft, but far and away most likely Google) would decide to simply stop delivering messages from my five users--remember, including me--to Google's users. The messages would just...disappear. Sometimes, Google would stop delivering the messages mid-conversation. Replies would be going back and forth but then my reply to a Gmail user would go to /dev/null while their messages to me would still arrive. Most of the time, the mail would go to spam (even with that little yellow tag meaning "verified sender" or some such) but 20% of the time the mails would just disappear. Worse, the destination would say "250 OK" to every e-mail I sent them so I had no way of knowing that the messages had been sent to the big bitbucket in the sky. I got annoyed. I signed up for Google's Postmaster Tools and Microsoft's similar offering. Microsoft would at least show me telemetry but it wouldn't do any good. Google? Google would proclaim that I wasn't sending them enough e-mail so I couldn't show up on the dashboard. Finally, after three years of fighting this, it came to a head when I was, at all places, at a boardgame meetup during one of these "blackout periods" and got introduced to a Google SRE who worked "adjacent" to Gmail. "Oh, hey, you should talk to techsupporter, he does e-mail too!" was the opening line. We talked, I ranted, and he actually said he'd try to help. He escalated internally and the word came down from on high on their SMTP team or some such: "domain [mydomain] has insufficient reputation." What did that mean? Apparently, their system--at least at that moment--thought my domain was "too new" and they tilted towards just binning the e-mail. I got red, saw stars, then gave Fastmail $390 for three years of service on three e-mail accounts and moved everything to them within five hours. That was the last straw, the final injustice. For me, the "decentralized Internet" died on that day. Why was I so pissed? Observe these dates from WHOIS: Domain Name: MYDOMAIN.ORG [...] Creation Date: 1997-03-10T05:00:00Z Domain Name: GOOGLE.COM [....] Creation Date: 1997-09-15T04:00:00Z
dmix 8y ago
Between this and SMS, the NSA (et al) had a gold mine of data when they directly tapped the lines. I remember reading they were really upset when this email providers started using this by default... always a good sign when warrantless/dragnet surveillance is made harder.
fowl2 8y ago
So this is kinda like the HSTS preload list, but includes MX server names, and is supposed to be updated every 48 hours. Couldn't we just put this in DNS?
- sydli 8y ago
  That would be fine, too, and reflects in part what MTA-STS is trying to do. A point that may be obvious, but I would like to make explicit, is that unlike on web, end-users have no good way to express whether they prefer security over deliverability on a connection, which makes downgrade attacks more difficult to deal with. Everyone defaults to preferring deliverablity (falling back to plaintext). In the absence of user intent, it's more important for an email sender to know the recipient mailserver's intent: what level of security should they expect? This can be achieved at varying degrees through DANE, MTA-STS, or a "HSTS Preload List" equivalent for email, but there is currently no reliably deployed standard for this. (edit: something I forgot to mention: of course, you'd have to trust the initial DNS lookup as well)
  - fowl2 8y ago
    What would be more/also interesting would be a way of expressing this intent by a sender. Seems like (with absolutely no thought here) a new header could me minted for this - eg. "Transport-Security: Require". Tough part as usual would be getting MTA and client support, but switching to a per message approach would at least allow incremental rollout - and critically I think - allow introspection by following bounces.
walrus01 8y ago
The site has a link to the starttls everywhere site right at the top - but it's also worth mentioning that the regular 'certbot' client for https everywhere can also be used to create certificates for your own smtpd. The easiest way is just having the sudo ability to temporarily open port 80 for the challenge/response process. using certbot: sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.com where mail.mydomainname.com is whatever is the full hostname of your MX. then a pretty typical postfix configuration blob: # TLS (SSL) private and public keys # obtained from certbot-auto in /etc/certbot/ # sample CLI to obtain new cert # sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.com smtpd_tls_CAfile=/etc/letsencrypt/live/mail.mydomainname.com/fullchain.pem smtpd_tls_cert_file=/etc/letsencrypt/live/mail.mydomainname.com/cert.pem smtpd_tls_key_file=/etc/letsencrypt/live/mail.mydomainname.com/privkey.pem # TLS (SSL) configuration smtp_tls_security_level=may smtp_use_tls=yes smtpd_use_tls=yes smtpd_tls_loglevel=1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client.
- schoen 8y ago
  Thanks for the plug. The same developer at EFF is working on both STARTTLS Everywhere and Certbot Postfix integration. :-) (Anyway, the most significant difference between the two is that STARTTLS Everywhere can also enforce certificate validation on recipient sites that request it, which Postfix won't otherwise do.)
  - rhizome 8y ago
    Thanks for calling that part out!
- zAy0LfpBZLC8mAC 8y ago
  > The easiest way is just having the sudo ability to temporarily open port 80 for the challenge/response process. The easiest way is to forget about HTTP and use DNS verification. Just create a dynamically updateable TXT record in your zone that the LE client can update and then point CNAMEs for the names that you want to create certificates for to that TXT record.
bumholio 8y ago
What we need next is a widely adopted standard of end-to-end opportunistic encryption, similar to Signal. PKI and PGP are too complex for end users. The problem that prevents such a standard from ever taking off is that, unlike TLS, there is zero interest from major providers to push end-to-end encyption, because they absolutely need access to the plain text for commercial reasons. So they advertise STARTTLS as "email encryption". By that token, CDMA and GSM are "email encryption" as well, it's not like they push the plain text naked over radio.
- bjpbakker 8y ago
  > PKI and PGP are too complex for end users They are also the only possibilities to provide proper end-to-end encryption. The last thing we need is another proprietary “standard” (remember how those same companies pushed for drm in the w3c spec). Yet the only real change can come when end users understand the implications of using the free email providers. I think this is harder for most than using a pgp email client plugin.
- rakoo 8y ago
  It's not a standard, but it's there: autocrypt (https://autocrypt.org https://autocrypt.org) aims to make end to end encryption as easy as possible. It's using PGP underneath but the whole idea is to hide key management (the real pain point) from the user. It's a long term initiative, divided in multiple levels of "compliance" that gradually break compatibility with existing systems more and more. Level 1 is there already, with some implementations.
__david__ 8y ago
So I support more encryption everywhere, but this is acting like there's something new? I know I've been using STARTLS on SMTP for almost 20 years… Am I missing something?
- jlgaddis 8y ago
  > ... there's something new? The "STARTTLS Everywhere" project [0] -- the one thing this entire article is talking about -- is what's new. > ... I've been using STARTLS on SMTP for almost 20 years ... That's great -- I have too -- but I have some bad news for you: not everybody else has been! (I know, right!?) The EFF is simply trying to bang the drums to get everyone's attention and then convince those that aren't already using STARTTLS (everywhere, hence the name) to consider doing so. The good news, for you, is that you're already done. There's nothing for you to do, unless you want to add your domains to the "policy list" so that others who are participating won't send mail to you unless encryption is in use. Fortunately, the EFF has already written about this extensively [0], so there's no need for me to rehash all the details (coincidentally, that same exact web page is also reachable by clicking on the first link in this article). [0]: https://www.starttls-everywhere.org https://www.starttls-everywhere.org
  - apple4ever 8y ago
    It seems to be dead. I submitted my domain and it’s not on the list, and there has been no communication about why or why not (given that it passes their security checker and requirements).
drudru11 8y ago
It would be better to have a TLS connection right at the start. STARTTLS is less secure. Why hasn't this happened for SMTP?
- mike-cardwell 8y ago
  Because it's not backwards compatible, and would prevent delivery of a large amount of email. We just need a way for domain owners to signal that their domains definitely accept email over STARTTLS. At that point, senders which recognise those signals can start to enforce that mail which they send to those domains MUST use STARTTLS. Fortunately, those signalling methods are beginning to rise to the surface. We have MTA-STS, and now also a preload list thanks to StartTLS Everywhere.
  - drudru11 8y ago
    All you need is another port in addition to the regular SMTP port. They are not mutually exclusive.
    - mike-cardwell 8y ago
      That is completely insecure. A MITM would just block access to the tls-on-connect port, forcing the sending host to retry on port 25, where they would strip the STARTTLS advertisement. Unless you're recommending to not fall back to port 25 after a failed connection to the tls-on-connect port. In which case, see the comment you were replying to where I said it would be backwards incompatible. Both of the solutions I mentioned are backwards compatible, and protected from a similar downgrade situation.
      - drudru11 8y ago
        Right, I should have said that I was recommending not ever sending on 25. The STARTTLS mitm is just too easy for large attackers. IMHO, being backwards compatible is necessary for a transition period. The messaging to SMTP operators should be... get on board, or you are going to start losing mail in 1 year. Even Chrome is going to show all http as insecure in the very near future. Which reminds me... I need to get all my sites upgraded.
deleted 8y ago
[deleted]
AndyMcConachie 8y ago
For folks interested in this subject I highly recommend Viktor Dukhovni's talk he gave at ICANN 61 on SMTP STARTTLS/DANE. https://mail.sys4.de/pipermail/dane-users/2018-March/000445.html https://mail.sys4.de/pipermail/dane-users/2018-March/000445.... He also runs stats every month on DANE adoption. https://mail.sys4.de/pipermail/dane-users/2018-June/000460.html https://mail.sys4.de/pipermail/dane-users/2018-June/000460.h...
- jlgaddis 8y ago
  Unfortunately, DANE relies on DNSSEC, and that's the biggest barrier to widespread adoption that DANE has.
sleavey 8y ago
I have my mail server require a TLS connection to a host before sending mail, but perhaps 2% of the time I get my mail bounced by the target server because it doesn't support it, including my old university. It's really crazy that a 20+ year old, standard technology is not literally everywhere, especially in big organisations. Incidentally, that same university in the past year started injecting footers into people's emails, so I guess their primary focus is neither privacy nor security.
- walrus01 8y ago
  At present not allowing plaintext port 25 will break a lot of email functionality, there are a ton of old and poorly set up mx out there. I have my postfix setup as "may" for TLS, not required.
  - sleavey 8y ago
    But for actively maintained servers, could they not be configured to support TLS for clients that request it without breaking plaintext email for old clients? I'm trying to understand whether supporting old clients really means not supporting encryption features for up-to-date clients.
    - walrus01 8y ago
      I was referring to server-to-server mail exchange. Yes, this is how my server is. When exchanging smtp with another domain's mx, if that other smtpd will not do TLS, it sends plaintext mail. For clients submitting mail via smtp with auth, such as thunderbird on my desktop PC, of course it does TLS1.2.
walrus01 8y ago
I really can't agree with this part: > The STARTTLS Everywhere project has created a “STARTTLS Policy List” where supporting organizations can assert that they always use STARTTLS using a valid certificate. Organizations should join that list and check that list before they send email. We don't need a new separate place to publish the TLS ability of our mx. This can be done with a txt record in the DNS zonefiles same as spf. It would need some sort of consistent rfc-guided format for what TLS policy re: downgrades, port 25 plaintext, etc, that you want to publish. Not too dissimilar from publishing an HSTS policy, but done by the authoritative nameservers for a zone rather than on an individual httpd.
Sami_Lehtinen 8y ago
Interestingly services like Outlook and Hotmail simply fail certificate check. Maybe TLS is just too hard, even for companies like Microsoft.

71 points by severine 8y ago

Sure, STARTTLS is better than nothing, but your email provider still reads your email. When we talk about email encryption, we mean end-to-end encryption.

mehrdadn 8y ago
> STARTTLS is not an end-to-end encryption system. [...] But for various reasons it’s hard to deploy end-to-end email encryption, and we’ve spent decades trying. Also, STARTTLS works just fine with end-to-end encryption. > Please indulge me: I think a small rant is appropriate here. There are some security specialists who think that only the perfect is acceptable. Nonsense! Requiring perfection is crazy. [...] For almost all users, email encryption with STARTTLS is a major improvement over what they had before. Let’s keep working to deploy even better systems, but let’s take partial victories where we can get them.
- deleted 8y ago
  [deleted]
mey 8y ago
So you are saying you do not trust your e-mail provider to secure your email. At that point I suggest finding another provider or running your own service. This secures a significant point of interception and modification of data.
- robjan 8y ago
  In general, if a government asks your provider for access to your emails then will hand them over. The only way to mitigate this threat is to use e2e encryption or host the email server on premises but then you start encountering deliverability issues.
  - arpa 8y ago
    That's FUD. If a system is correctly set up, you'll have no deliverability issues. Edit: srsly guys, HACKER news people say that it's impossible for a person to have a proper mailserver set up? That's hilarious, if not sad!
    - CyberShadow 8y ago
      This is just not true. The Internet is full of stories of people having trouble with large email providers (notably Google and Microsoft) accepting self-hosted users' mail. A self-hosted setup's IP starts with 0 reputation (or worse, depending on who owned the IP address beforehand) and will face throttling and outright blocking for a painful amount of time. Furthermore, if you forward your email to e.g. a Gmail inbox, any spam sent to your address will go towards lowering the reputation of your forwarder, meaning that someone just has to send you a lot of spam to get your forwarder blocked from Google servers. SPF, DKIM, DMARC and TLS all cannot mitigate the above.
      - arpa 8y ago
        Point 1: spf, dkim, dmarc is enough to get yourself neutral with gmail. You have to do it from get-go tho, before you tarnish your reputation. Being in DNSBL lists does not help either. Set up proper reverse dns entries also. Tls is completely optional. Haven't had any trouble neither with gmail nor ms using both residential and datacenter ips in two EU countries. I don't consider myself a hardcore linux admin specialising in mail, so there's that. As far as the second point, about forwarding spam goes, you're running a mailserver without spamassasin? What is this, the 1990s?
        CyberShadow 8y ago
        > you're running a mailserver without spamassasin? What is this, the 1990s? More like, relying on SpamAssassin to reliably and correctly classify spam is the anachronism here. Even if SpamAssassin could do a good job of filtering spam today (which it can't), the set of messages that SpamAssassin classifies as spam will inevitably differ from the set of messages that Gmail classifies as spam, so the only thing this achieves is another point where you have to worry about false positives and training the classifiers. Furthermore, the problem is exacerbated by poor support of forwarding in modern MTAs. They will queue all received messages first, and when Gmail rejects certain messages during the IMAP session (spam with high confidence, or messages it considers invalid), they result in a bounce, and the thus ensuing backscatter further degrades your mail server's reputation. The closest thing to correct behavior is Exim's cutthrough delivery feature, which has been implemented "relatively" recently, and even so it is not complete and I've run into issues with it with non-textbook setups.
- deleted 8y ago
  [deleted]
arpa 8y ago
I am my own provider. It's really not that hard to configure a mail server. Other peoples' providers, however... so I tried using PGP. It's somehow manages to be more difficult to use than configuring and running your own mailsystem which doesn't deliver straight to gmails' spam folder, but I digress; but then my emails are at mercy of the end devices: who knows if outlook doesn't send a plaintext email home as "telemetry"? Same thing about chrome with all the extensions for using PGP... I mean, security is hard as-is, but security of an ubiquitous thing, especially when people have been conditioned to undervalue security and privacy, is a lost cause. It's best to treat emails as being in the same category as phone calls, conversations in subway and sms'es - public.
- selectodude 8y ago
  Also all of your emails get kicked to spam when you host your own.
  - mrb 8y ago
    You can perfectly "host your own email server" while sending outgoing mail through a smart host. No falsely-tagged-spam issue that way.
    - deleted 8y ago
      [deleted]
    - techsupporter 8y ago
      No, in my experience, selectodude is right. I've written this rant before but I think it's worth sharing repeatedly, so here goes again: The big players (Google, in particular...in case it's not clear, the bulk of this rant is leveled at Google; Microsoft is an offender on perhaps 25% of the level, Yahoo just doesn't seem to care) have ZERO interest in "playing nice" with small e-mail servers. My experience running my own e-mail for almost twenty years then finally throwing in the towel and migrating to Fastmail not only proves this for me, but is, according to other sysadmins I've talked to, quite common. I did everything right when hosting my e-mail. I did it for myself and maybe four others. The volume of mail going out of my server was so low, I could read the outbound mail.log for myself, and routinely did. Every domain had SPF, DKIM, and DMARC records. The outgoing single IPv4 and IPv6 addresses I used had perfectly-matching forward and reverse DNS lookups. I had a script that checked every blacklist I could find every 24 hours. My IP addresses were allocated from my (professional) colocation provider and SWIP'd to me with valid contact information. My IP addresses had been unchanged for seven years and had been stable for ten years prior to that change. My colo provider had a draconian non-spam policy. Nobody ran an e-mail list or anything. I've used the exact same domain for e-mail for over twenty years. Still, every couple of months, Google (sometimes Microsoft, but far and away most likely Google) would decide to simply stop delivering messages from my five users--remember, including me--to Google's users. The messages would just...disappear. Sometimes, Google would stop delivering the messages mid-conversation. Replies would be going back and forth but then my reply to a Gmail user would go to /dev/null while their messages to me would still arrive. Most of the time, the mail would go to spam (even with that little yellow tag meaning "verified sender" or some such) but 20% of the time the mails would just disappear. Worse, the destination would say "250 OK" to every e-mail I sent them so I had no way of knowing that the messages had been sent to the big bitbucket in the sky. I got annoyed. I signed up for Google's Postmaster Tools and Microsoft's similar offering. Microsoft would at least show me telemetry but it wouldn't do any good. Google? Google would proclaim that I wasn't sending them enough e-mail so I couldn't show up on the dashboard. Finally, after three years of fighting this, it came to a head when I was, at all places, at a boardgame meetup during one of these "blackout periods" and got introduced to a Google SRE who worked "adjacent" to Gmail. "Oh, hey, you should talk to techsupporter, he does e-mail too!" was the opening line. We talked, I ranted, and he actually said he'd try to help. He escalated internally and the word came down from on high on their SMTP team or some such: "domain [mydomain] has insufficient reputation." What did that mean? Apparently, their system--at least at that moment--thought my domain was "too new" and they tilted towards just binning the e-mail. I got red, saw stars, then gave Fastmail $390 for three years of service on three e-mail accounts and moved everything to them within five hours. That was the last straw, the final injustice. For me, the "decentralized Internet" died on that day. Why was I so pissed? Observe these dates from WHOIS: Domain Name: MYDOMAIN.ORG [...] Creation Date: 1997-03-10T05:00:00Z Domain Name: GOOGLE.COM [....] Creation Date: 1997-09-15T04:00:00Z

dmix 8y ago

Between this and SMS, the NSA (et al) had a gold mine of data when they directly tapped the lines. I remember reading they were really upset when this email providers started using this by default... always a good sign when warrantless/dragnet surveillance is made harder.

fowl2 8y ago

So this is kinda like the HSTS preload list, but includes MX server names, and is supposed to be updated every 48 hours. Couldn't we just put this in DNS?

sydli 8y ago
That would be fine, too, and reflects in part what MTA-STS is trying to do. A point that may be obvious, but I would like to make explicit, is that unlike on web, end-users have no good way to express whether they prefer security over deliverability on a connection, which makes downgrade attacks more difficult to deal with. Everyone defaults to preferring deliverablity (falling back to plaintext). In the absence of user intent, it's more important for an email sender to know the recipient mailserver's intent: what level of security should they expect? This can be achieved at varying degrees through DANE, MTA-STS, or a "HSTS Preload List" equivalent for email, but there is currently no reliably deployed standard for this. (edit: something I forgot to mention: of course, you'd have to trust the initial DNS lookup as well)
- fowl2 8y ago
  What would be more/also interesting would be a way of expressing this intent by a sender. Seems like (with absolutely no thought here) a new header could me minted for this - eg. "Transport-Security: Require". Tough part as usual would be getting MTA and client support, but switching to a per message approach would at least allow incremental rollout - and critically I think - allow introspection by following bounces.

walrus01 8y ago

The site has a link to the starttls everywhere site right at the top - but it's also worth mentioning that the regular 'certbot' client for https everywhere can also be used to create certificates for your own smtpd. The easiest way is just having the sudo ability to temporarily open port 80 for the challenge/response process. using certbot: sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.com where mail.mydomainname.com is whatever is the full hostname of your MX. then a pretty typical postfix configuration blob: # TLS (SSL) private and public keys # obtained from certbot-auto in /etc/certbot/ # sample CLI to obtain new cert # sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.com smtpd_tls_CAfile=/etc/letsencrypt/live/mail.mydomainname.com/fullchain.pem smtpd_tls_cert_file=/etc/letsencrypt/live/mail.mydomainname.com/cert.pem smtpd_tls_key_file=/etc/letsencrypt/live/mail.mydomainname.com/privkey.pem # TLS (SSL) configuration smtp_tls_security_level=may smtp_use_tls=yes smtpd_use_tls=yes smtpd_tls_loglevel=1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client.

schoen 8y ago
Thanks for the plug. The same developer at EFF is working on both STARTTLS Everywhere and Certbot Postfix integration. :-) (Anyway, the most significant difference between the two is that STARTTLS Everywhere can also enforce certificate validation on recipient sites that request it, which Postfix won't otherwise do.)
- rhizome 8y ago
  Thanks for calling that part out!
zAy0LfpBZLC8mAC 8y ago
> The easiest way is just having the sudo ability to temporarily open port 80 for the challenge/response process. The easiest way is to forget about HTTP and use DNS verification. Just create a dynamically updateable TXT record in your zone that the LE client can update and then point CNAMEs for the names that you want to create certificates for to that TXT record.

bumholio 8y ago

What we need next is a widely adopted standard of end-to-end opportunistic encryption, similar to Signal. PKI and PGP are too complex for end users. The problem that prevents such a standard from ever taking off is that, unlike TLS, there is zero interest from major providers to push end-to-end encyption, because they absolutely need access to the plain text for commercial reasons. So they advertise STARTTLS as "email encryption". By that token, CDMA and GSM are "email encryption" as well, it's not like they push the plain text naked over radio.

bjpbakker 8y ago
> PKI and PGP are too complex for end users They are also the only possibilities to provide proper end-to-end encryption. The last thing we need is another proprietary “standard” (remember how those same companies pushed for drm in the w3c spec). Yet the only real change can come when end users understand the implications of using the free email providers. I think this is harder for most than using a pgp email client plugin.
rakoo 8y ago
It's not a standard, but it's there: autocrypt (https://autocrypt.org https://autocrypt.org) aims to make end to end encryption as easy as possible. It's using PGP underneath but the whole idea is to hide key management (the real pain point) from the user. It's a long term initiative, divided in multiple levels of "compliance" that gradually break compatibility with existing systems more and more. Level 1 is there already, with some implementations.

__david__ 8y ago

So I support more encryption everywhere, but this is acting like there's something new? I know I've been using STARTLS on SMTP for almost 20 years… Am I missing something?

jlgaddis 8y ago
> ... there's something new? The "STARTTLS Everywhere" project [0] -- the one thing this entire article is talking about -- is what's new. > ... I've been using STARTLS on SMTP for almost 20 years ... That's great -- I have too -- but I have some bad news for you: not everybody else has been! (I know, right!?) The EFF is simply trying to bang the drums to get everyone's attention and then convince those that aren't already using STARTTLS (everywhere, hence the name) to consider doing so. The good news, for you, is that you're already done. There's nothing for you to do, unless you want to add your domains to the "policy list" so that others who are participating won't send mail to you unless encryption is in use. Fortunately, the EFF has already written about this extensively [0], so there's no need for me to rehash all the details (coincidentally, that same exact web page is also reachable by clicking on the first link in this article). [0]: https://www.starttls-everywhere.org https://www.starttls-everywhere.org
- apple4ever 8y ago
  It seems to be dead. I submitted my domain and it’s not on the list, and there has been no communication about why or why not (given that it passes their security checker and requirements).

drudru11 8y ago

It would be better to have a TLS connection right at the start. STARTTLS is less secure. Why hasn't this happened for SMTP?

mike-cardwell 8y ago
Because it's not backwards compatible, and would prevent delivery of a large amount of email. We just need a way for domain owners to signal that their domains definitely accept email over STARTTLS. At that point, senders which recognise those signals can start to enforce that mail which they send to those domains MUST use STARTTLS. Fortunately, those signalling methods are beginning to rise to the surface. We have MTA-STS, and now also a preload list thanks to StartTLS Everywhere.
- drudru11 8y ago
  All you need is another port in addition to the regular SMTP port. They are not mutually exclusive.
  - mike-cardwell 8y ago
    That is completely insecure. A MITM would just block access to the tls-on-connect port, forcing the sending host to retry on port 25, where they would strip the STARTTLS advertisement. Unless you're recommending to not fall back to port 25 after a failed connection to the tls-on-connect port. In which case, see the comment you were replying to where I said it would be backwards incompatible. Both of the solutions I mentioned are backwards compatible, and protected from a similar downgrade situation.
    - drudru11 8y ago
      Right, I should have said that I was recommending not ever sending on 25. The STARTTLS mitm is just too easy for large attackers. IMHO, being backwards compatible is necessary for a transition period. The messaging to SMTP operators should be... get on board, or you are going to start losing mail in 1 year. Even Chrome is going to show all http as insecure in the very near future. Which reminds me... I need to get all my sites upgraded.

deleted 8y ago

[deleted]

AndyMcConachie 8y ago

For folks interested in this subject I highly recommend Viktor Dukhovni's talk he gave at ICANN 61 on SMTP STARTTLS/DANE. https://mail.sys4.de/pipermail/dane-users/2018-March/000445.html https://mail.sys4.de/pipermail/dane-users/2018-March/000445.... He also runs stats every month on DANE adoption. https://mail.sys4.de/pipermail/dane-users/2018-June/000460.html https://mail.sys4.de/pipermail/dane-users/2018-June/000460.h...

jlgaddis 8y ago
Unfortunately, DANE relies on DNSSEC, and that's the biggest barrier to widespread adoption that DANE has.

sleavey 8y ago

I have my mail server require a TLS connection to a host before sending mail, but perhaps 2% of the time I get my mail bounced by the target server because it doesn't support it, including my old university. It's really crazy that a 20+ year old, standard technology is not literally everywhere, especially in big organisations. Incidentally, that same university in the past year started injecting footers into people's emails, so I guess their primary focus is neither privacy nor security.

walrus01 8y ago
At present not allowing plaintext port 25 will break a lot of email functionality, there are a ton of old and poorly set up mx out there. I have my postfix setup as "may" for TLS, not required.
- sleavey 8y ago
  But for actively maintained servers, could they not be configured to support TLS for clients that request it without breaking plaintext email for old clients? I'm trying to understand whether supporting old clients really means not supporting encryption features for up-to-date clients.
  - walrus01 8y ago
    I was referring to server-to-server mail exchange. Yes, this is how my server is. When exchanging smtp with another domain's mx, if that other smtpd will not do TLS, it sends plaintext mail. For clients submitting mail via smtp with auth, such as thunderbird on my desktop PC, of course it does TLS1.2.

walrus01 8y ago

I really can't agree with this part: > The STARTTLS Everywhere project has created a “STARTTLS Policy List” where supporting organizations can assert that they always use STARTTLS using a valid certificate. Organizations should join that list and check that list before they send email. We don't need a new separate place to publish the TLS ability of our mx. This can be done with a txt record in the DNS zonefiles same as spf. It would need some sort of consistent rfc-guided format for what TLS policy re: downgrades, port 25 plaintext, etc, that you want to publish. Not too dissimilar from publishing an HSTS policy, but done by the authoritative nameservers for a zone rather than on an individual httpd.

Sami_Lehtinen 8y ago

Interestingly services like Outlook and Hotmail simply fail certificate check. Maybe TLS is just too hard, even for companies like Microsoft.