Gmail Will Soon Warn Users When Emails Arrive Over Unencrypted Connections | Hacker News Reader

Gmail Will Soon Warn Users When Emails Arrive Over Unencrypted Connections

techcrunch.com

299 pointslujim59 comments

What depresses me is that many organisations agree that SMTP needs some work. However the stakeholders simply don't care enough to do anything about it, all Google is doing here is adding a pretty little icon for opportunistic encryption (that doesn't work very well).

Let's look at the biggest stakeholders in SMTP:

- Microsoft: Exchange (8% mail servers), Outlook (client), Outlook.com (23% of webmail).

- Google: Gmail & Google Apps (40% of webmail)

- Yahoo (21% of webmail)

- OSS: Sendmail, Postfix

So if Google, Microsoft, and Yahoo! signed up that is the majority of SMTP on the internet today. Then we find some funds to get OSS updated (or summer of code), and boom, we have an SMTP update fit for 2015.

Heck have it downgrade for right now, and we can talk about actually switching over in 2025 or whatever. But at least in 2025 we'll have something ready, the longer we take to kick this off the longer it will take to upgrade.

It is utterly insane that nothing is moving here. It is like SMTP is stuck in a perpetual IE 6 situation, and Microsoft is largely causing it all over again (Exchange + Outlook.com).

> However the stakeholders simply don't care enough to do anything about it,

Perhaps that's a sign that "it" (smtp) now works well enough with the decades of engineering investment put into spam detection, access, standardization and inter-operability that have been put into it to not justify the massive investment that an "SMTP update fit for 2015" would involve.

> spam detection, access, standardization and inter-operability

Spam detection works on a higher level than transport security, it is independent from transport (although a spam classifier might favor mails from SMTP servers sent with SSL and a client certificate signed by a CA for its domain name).

Access... well, that's IMAP/POP3's job, both support SSL for ages.

Standardization/interop, uh we already have SMTPS. The standard is there, what's lacking is support for inter-server encryption.

SMTPS has been deprecated since forever (late 90's or thereabouts). The standards for encrypted SMTP are: STARTTLS over port 25 for transfer/relay and STARTTLS over port 587 for submission.

But STARTTLS is a step backwards because a MITM can disable crypto by not advertising STARTTLS

A MITM could also deny SMTPS ports. If you want to ensure STARTTLS is in use then most smtp software has a setting to force STARTTLS or drop the connection.

My understanding that the issue is that attackers will then just do STARTTLS with their own self-signed certificate, as checking the common name of the certificate is difficult in the context of SMTP.

Well, use DNSSEC and add a new field in the DNS (e.g. CRYPTINFO = FORCE-HTTPS, FORCE-SMTPS). That would take time to spread, yes, but it would be a perfect solution for a lot of "prevent MITM downgrade" issues.

Yes, it would take a long time to spread considering there's a whopping 388 domains out there using DNSSSEC for SMTP, the majority of them run by neckbeards and not commerical email services.

    388 	Zones have deployed TLSA for SMTP with STARTTLS (Port 587)

I don't expect this to catch on, ever.

http://secspider.verisignlabs.com/stats.html

That's fine. They can deny it. At least you won't be MITM. I'd rather have no service than compromised service.

Look at Fastmail. They don't even offer STARTTLS. Why? Because of downgrade attacks!

    SSL/TLS Encryption	Enabled, but not STARTTLS

https://www.fastmail.com/help/technical/servernamesandports....

What I'm saying is that there's no difference in STARTTLS and SMTPS. In either case, the client should drop the connection if it doesn't manage to negotiate the desired transport encryption.

Whether that happens because it doesn't get the expected response to STARTTLS or because the SMTPS port fails to respond with a proper TLS handshake is the same.

A "downgrade attack" only works if the client decides to keep going after failing to establish encryption. This is a client policy configuration issue, and has nothing to do with whether one uses the bytes "HELO server\r\nSTARTTLS\r\n" or a raw TLS handshake to negotiate the connection after opening the TCP port.

STARTTLS exists as an opportunistic encryption upgrade, not enforcement. If a MITM strips the advertisement of STARTTLS (very, very simple to do) the client and server will both happily continue plaintext communications.

This is the default for every mail server I've ever seen.

This is the default for every mail client I've ever seen.

How are people not terrified of this?

Mind you, this is literally what a Cisco PIX/ASA firewall does when you enable the "esmtp inspect" feature. It strips the STARTTLS so everyone falls back to plaintext and it can "scan" your email communications for Bad Things^TM.

    When Cisco ASA is configured for ESMTP inspection, the ASA is not able to examine
    the TLS session because it is encrypted. Therefore the ASA will prevent the 
    establishment of the STARTTLS session and allow the SMTP endpoints to determine
    whether the SMTP session should continue in clear text (that is, with no privacy).

This is very normal. I can't remember the last time I encountered a small business with a Cisco PIX/ASA that didn't have this enabled.

http://www.cisco.com/web/about/security/intelligence/asa_esm...

edit: Oh hey, look at Postfix's documentation

    Mandatory TLS encryption: announce STARTTLS support to remote SMTP clients,
    and require that clients use TLS encryption. According to RFC 2487 this 
    MUST NOT be applied in case of a publicly-referenced SMTP server. Instead,
    this option should be used only on dedicated servers.

http://www.postfix.org/postconf.5.html#smtpd_tls_security_le...

There's literally an RFC that says DO NOT ENFORCE TLS ENCRYPTION WITH STARTTLS TO THE PUBLIC INTERNET

   A publicly-referenced SMTP server MUST NOT require use of the
   STARTTLS extension in order to deliver mail locally.

Case closed, SMTP security is broken. The deprecation of SMTPS was either a mistake or a carefully crafted NSA move. Who knows?

It's configurable, as you say. Maybe I don't understand your argument "at least you won't be MITM'ed". Almost nobody runs SMTPS anyways. I'm just saying that if someone decides they want to enforce encrypted SMTP, it really doesn't matter if that is implemented as mandatory STARTSSL vs SMTPS. One is not more suspectible to MITM than the other.

You missed my edit. The RFC clearly states you are not to enforce encrypted SMTP with STARTTLS to the public internet.

You don't enforce STARTTLS receiver-side (smtpd). You enforce it sender-side (smtp) by looking up the receiver's policy using DNSSEC/DANE. This is allowed by the RFC and is implemented in Postfix. I've been running this on my personal mailservers for over a year.

All you need is a DNSSEC resolver and two lines of Postfix configuration to get it working:

    smtp_dns_support_level = dnssec
    smtp_tls_security_level = dane

http://www.postfix.org/postconf.5.html#smtp_tls_security_lev...

Google's Online Security Blog posted earlier today regarding improving email security including "opportunistic TLS"[1] through the M3AAWG association, which does list the above companies as either sponsors or members[2]

1: https://googleonlinesecurity.blogspot.com/2015/11/new-resear...

2: https://www.m3aawg.org/about/roster

This unfortunately shows you know little about the forward momentum in the email standards. There have been many changes in the last few years that you just didn't see. DMARC creates policies on authentication. DANE creates policies on SMTP encryption. These technologies are gaining wide implementation and acceptance.

MAAWG meets three times a year to move these things forwards.

Just because the standard dialog here is "SMTP sucks, let's replace it" doesn't make it true. People are working harder than you think on solving these problems.

SMTP is hop by hop, so it's the wrong layer for addressing privacy. Starttls only happened because it was zero effort to turn on and gets you possibly little opportunistic privacy.

This is a bad move that will give users a false sense of security. Server-to-server SMTP is unauthenticated. Just because an email arrived at Gmail over an encrypted connection doesn't mean that the connection wasn't intercepted by a MitM that read the message and then relayed it to Gmail over an encrypted connection.

Opportunistic encryption is nice to have because it stymies passive surveillance, but it's not something that can be relied upon to provide security or privacy. Thus, its presence or absence should never be communicated to users, to avoid suckering them into a false sense of security.

There's a way to fairly reliably mark messages as insecure when they're sent by clients that don't verify certs.

For every incoming ssl smtps connection, google could forge a cert the first time it encounters a connection from a particular ip on a particular day. If the client continues with the ssl negotiation, google would know to mark the message as unsecure, because the sender isn't verifying certs.

You could obviously adjust the frequency with which the recipient (eg google) tests each IP. It wouldn't have to be every 24 hours. You could also use additional heuristics to re-test, even going so far as to disconnect immediately and force the client to retry (giving it a forged cert test) if you trust the client ip but see a different helo than you saw last time. You could even use global bgp feed to invalidate any successful tests from a netblock when there's a visible routing change for it.

If Gmail did this, the MitM would be sure to correctly validate Gmail's certs.

Introducing spurious failures to improve security feels like one of those ideas likely to have unintended consequences.

What would stop the MiTM from verifying Gmail's cert? Say, the email is sent in plain text, it is intercepted by the bad guy, then the bad guy sends it on to gmail encrypted, with cert checking and everything.

I am failing to see what your proposal would help.

99% of gmail users will never know that the feature exists until they see the warning. That can only have the benefit of encouraging the correspondent to get their provider(s) to enable the encryption.

> stymies passive surveillance... presence or absence should never be communicated ... to avoid suckering them into a false sense of security.

I think you're not giving enough weight to the first point. This really does provide an advantage for individuals who receive their password/reset url or some other credentials via email. At least it wouldn't be intercepted on that hop. Seems like the benefits outweigh the drawbacks.

> At least it wouldn't be intercepted on that hop

It wouldn't be passively intercepted. It could trivially be actively intercepted. Gmail would not display a warning in this case, thus making the user think their password/reset URL was safe when it really wasn't. And trying to inform users about the difference between passive and active interception, and expecting them to make a risk evaluation based on it, is just not realistic for the vast majority of users.

That's not always true, and with more and more hosts supporting key pinning technologies like DANE, it'll be less true with time.

My mail server is set up to know that mail to Google domains (and others, like those hosted by Google or Microsoft) must be encrypted and the certificate must be correct. I occasionally look through my server logs to find more domains I can add to the list.

If anything, a spammer or phiser has more motivation to deliver their mail over TLS because of this development, compared to some legitimate host. Whether the mail was delivered via TLS provides no information on its legitimacy. That is why it is problematic that it could give a false sense of security.

Getting the internet as a whole away from plaintext is more important than dealing with MITMs - you may or may not be subject to a MITM attack at any given time, you absolutely are subject to passive surveillance at all times.

Don't let the perfect be the enemy of the better.

Depends on your threat model. Which do you consider more of a threat to you, the NSA or a corporate competitor who hired a black hat for some espionage? Whichever answer you give, there will be people to whom the answer is the opposite. It's not that they're being obtuse - that really is the answer for their situation.

> Don't let the perfect be the enemy of the better.

Think both/and, not either/or.

This isn't a zero sum game. Removing the ability for people to passively spy on you doesn't mean you can't add MITM protection later.

Having everything be encrypted by default is strictly more secure. There's no reason to avoid taking the first step in fear of the second one.

It actually can be zero sum.

Solve the problem with a poor 50% solution which most people can't understand, and you may be stuck with it for another 20 years.

I would encourage anyone to use TLS. However, I take issue with using it as an indicator of the trustworthiness of the sender or its host.

It looks like Gmail is only adding a warning for non-TLS deliveries, not a green padlock (or whatever) for TLS deliveries. I'd be more worried about your point in the latter case. There are other systems in place (SPF, DKIM, DMARC) to identify fake mails.

My guess is that they will simply start using free SSL certs from StartSSL or LetsEncrypt.

Edit: reading the thread more, I guess it depends if they're actually gonna authenticate the certs: https://news.ycombinator.com/item?id=10556544

Can an attacker MitM a connection without changing the key fingerprint?

No, but the problem is that the SMTP specs don't define how to validate the cert -- for example, many deliveries will work with a self-signed certificate[0], so a MITM can just make a new certificate.

[0] https://serverfault.com/questions/579138/is-it-ok-to-use-sel...

We're talking about deliveries to Gmail, and Gmail can decide what kind of client certificates count as authenticated when sending emails to Gmail. For example, they could establish the convention that the highest tier of lock icon requires a client certificate under the same domain name as the sender's address, verified by path validation of commonly trusted certificate authorities. A lower tier of lock icon might be a path-validated certificate of some kind, and the lowest tier might be a self-signed certificate - perhaps analogous to how tiers of HTTP and HTTPS are displayed.

The proposal for "Secure SMTP using DNS-Based Authentication of Named Entities (DANE)" applies a similar strategy, though it's only for client authentication of the server certificate, not vice versa [1]. There was a proposal at one point to add client certificate requirements to the DMARC standard, though that work appears to have fizzled out.

[1] https://tools.ietf.org/html/draft-ietf-dane-smtp-01

This is true, I forgot that element of context. If they do this, I hope they pick a "good" standard, and hope that nobody else applies a different standard (forcing senders to decide whose to use, or complicating their implementation to support both.)

I think this is a good move that establishes a useful foundation, building on the work that Google has done thus far in their Safer Email effort. The quality of the security depends on the implementation details, but being Google, I would expect the Gmail team to have considered these issues carefully, and to have a plan for the future.

There are a number of short term and long term benefits. A few years ago, a significant majority of all email was transmitted in plaintext. Google's Safer Email Transparency Report called attention to this, and provided an incentive for ISPs to enable opportunistic TLS and increase their TLS percentage to 100%. This first step appears to have had a meaningful impact on the amount of TLS employed by large senders and ISPs.

At this point, however, messages appear identically to email receivers, whether sent across TLS or not. This report alone was not enough motivation for all large senders and ISPs to employ TLS. Much like how websites with the "lock icon" have a privileged status in browser UIs, the next step of displaying the TLS status (or lack of TLS) in the UI will provide an incentive for senders to employ it.

Employing more TLS today is a benefit even as things stand. Opportunistic TLS protects against passive eavesdropping, which is still a win, and it allows you to detect active MITM interception with scrutiny: MITM interception will leave a permanent trail in message metadata. Plus, one only needs to employ a basic degree of path validation to deter most casual MITM interception (based on self-signed certificates). Gmail could establish tiers of trust, analogous to the types of HTTPS lock icons, and require senders to use a properly path-validated client certificate from a generally trusted CA in order to achieve the highest degree of trust, analogous to the lock icons in HTTPS. The STARTTLS protocol anticipates this kind of authentication [1], but does not specify it:

> Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.

I would expect Gmail to raise the bar over time. This initial effort creates an incentive to roll out opportunistic TLS, even if poorly implemented such as with self-signed certificates. Simply getting TLS in place universally will be a great starting point for further refinement.

Over time, I'd expect to see additional features such as, perhaps: (1) incentives to use path-validated certificates from a trusted CA, over self-signed certificates (2) mechanisms for sending domains to declare what kind of certificate and TLS they'll use when sending, such that receivers can validate TLS connections and reject invalid client certificates. There was some talk in the past about adding this to the DMARC standard, but that fizzled out. There is another effort toward establishing a convention for this by applying DNS-based Authentication of Named Entities (DANE) to SMTP [2]. Although the existing DANE SMTP protocol only establishes a convention for server authentication and not client authentication, there is still value for senders, and I expect work to progress toward client authentication over time. Protocols aside, Gmail could also establish their own conventions, out-of-band mechanisms, or tiers of authentication, like browsers have for EV certificates. We might also see (3) better support for grappling with identity alignment, i.e., emails from example.com are expected to be sent across TLS using an example.com client certificate (perhaps not necessary given DKIM).

In the interim, Gmail can add metadata to the message that captures the client certificate used to transmit the message. A security-conscious receiver can inspect those details, perhaps using a plugin or with a visual scan. It would not be so hard to build a plugin that pins certificates or expected CAs for popular domains, for example.

To summarize, I think this is useful and is heading in the right direction. It's not a complete solution, but it's difficult to go directly from where email is today to a complete solution.

[1] https://tools.ietf.org/html/rfc3207 [2] https://tools.ietf.org/html/draft-ietf-dane-smtp-01

I'm happy about incrementally rolling this stuff out. STARTTLS for now. Surfacing that in the UI. Then maybe DANE, and in parallel some form of downgrade notification, or pinning, or something.

I'm all for rolling out opportunistic STARTTLS, but I don't see how you can surface it in the UI in a way that's meaningful to the vast majority of users. If STARTTLS was not used, the message might have been intercepted. If STARTTLS was used, it's less likely it was intercepted, but it still easily could have been. (How much less likely? No one knows for sure.) How is this information helpful to users?

Let's get things like DANE and pinning deployed first. Once Gmail can make a strong assertion that a message was securely delivered, then it can surface this information.

I have to agree with this. Email is not a secure medium and this is just going to confuse people.

This is a great marketing move, because users have absolutely no control over the flow that their email takes... except to tell the other user to start using Gmail.

This Thunderbird addon does the same, if you prefer a local client: https://addons.mozilla.org/en-us/thunderbird/addon/paranoia/

I use Postfix, I'll have to check how it makes outgoing connections but I'd assume it's unencrypted. My client connection to my server is encrypted but never thought to use it for the connections to the servers my server delivers mail to.

You have to install a certificate if you want it to be encrypted.

#opportunistic encryption s2s

smtp_tls_security_level = may

smtp_tls_CApath = /etc/ssl/certs

This will use STARTTLS to upgrade the connection. This does not protect you against an active attacker, but it will protect you against passive eavesdropping (~mass surveillance).

Thanks Wicher and baudehlo, great tips.

I will soon warn my users when they're recieving an email that is not PGP-encrypted.

But they force XMPP/Jabber s2s connections to be in the clear?

smh

Gmail will warn users for this, but not for soft failing SPF. That doesn't make sense.

A step in the right direction!

Is Google's End-to-End extension still progressing? Or are they hoping we forgot about it?

You mean without PGP right?

Looking forward to seeing Chrome marking HTTP as not secure.. https://plus.google.com/+FrancoisBeaufort/posts/TaTACsJSnjN

You should not use Gmail anyway. Privacy issues and security issues. I still have several Gmail accounts. Daily warnings in my Thunderbird (Someone has your password....--- Yes, guess fucker, it is me who has my password). I have one Gmail account that I can not access anymore besides knowing my password, the previous password and a security question. Unfortunately I have a domain registered with this email. This domain may be lost.

Pay a few bucks and get your own email. External email, hosted in Switzerland (high privacy, not EU or US jurisdiction) costs me 15 Euro per year. I can use my own (even external!) domain.

So the security issue is that they are too secure?

Reply on news.ycombinator.com