Slashdot Mirror


Gmail Becomes First Major Email Provider To Support MTA-STS and TLS Reporting (zdnet.com)

Google announced this week that Gmail has become the first major email provider to support two new security standards, namely MTA-STS and TLS Reporting. From a report: Both are extensions to the Simple Mail Transfer Protocol (SMTP), the protocol through which all emails are sent today. The purpose of MTA-STS and TLS Reporting is to help email providers establish cryptographically secure connections between each other, with the main goal of twarthing SMTP man-in-the-middle attacks. SMTP man-in-the-middle attacks are a major problem for today's email landscape, where rogue email server operators can intercept, read, and modify the contents of people's emails. The two new standards will prevent this by allowing legitimate email providers to create a secure channel for exchanging emails.

22 of 44 comments (clear)

  1. It it doesn't use blockchain by cdsparrow · · Score: 1

    I want nothing to do with it!

  2. Skeptic in me says they have ulterior motives by JoeyRox · · Score: 4, Insightful

    Such as cornering the market for harvesting e-mail content to sell us more targeted ads.

    1. Re:Skeptic in me says they have ulterior motives by s0lar · · Score: 2

      Skeptic in me says they have ulterior motives

      I am sure they do... yet this feature is not visible to end-user really. Well, they will probably add a little line item or an icon to indicate that the inbound delivery was secured. Yet that has little to do with the email's content which, by definition, is either transferred from GMail's storage or transferred into it.

    2. Re:Skeptic in me says they have ulterior motives by swillden · · Score: 1

      Such as cornering the market for harvesting e-mail content to sell us more targeted ads.

      I strongly doubt that the Gmail security team ever thinks about advertising at all. I also doubt that any executive in the advertising division ever heard about this before it launched. The nature of Google is that nearly all of these initiatives are bottom up, with little or no coordination across divisions. If something one group is doing seems like it might actively harm another, then that gets escalated. Otherwise, there's not much central planning, not at this level of detail.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    3. Re:Skeptic in me says they have ulterior motives by AmiMoJo · · Score: 4, Informative

      They stopped doing that in 2017. Aside from anything else there were lawsuits over non-Gmail users having their messages scanned when Gmail users received them. The advertising on Gmail, assuming you don't block it, is now based on data from other Google services you use.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  3. Twarthing? by cyber-vandal · · Score: 1

    Come on editors.

  4. Nothing to see here by cmaurand · · Score: 1, Interesting

    My servers have been negotiating TLS connections for years. What's all this about?

    1. Re:Nothing to see here by s0lar · · Score: 1

      Are you sure that you are talking about the server-to-server connections rather than client-to-server ones? The latter have been using TLS for a long time, yes.

    2. Re:Nothing to see here by caseih · · Score: 2

      Yes, server to server. My postfix server has been attempting to StartTLS on every outgoing port 25 connection to other mail servers. Many servers (but not all) will speak TLS on port 25.

    3. Re:Nothing to see here by Justus · · Score: 5, Informative

      MTA-STS is analogous to HSTS (HTTP Strict Transport Security). It's a way for MTAs to express that a connection _must_ be encrypted, so if your server connects and attempts a StartTLS that fails, you can distinguish between "doesn't support TLS" and "something fishy is going on." In the latter case the server can avoid sending mail through a possibly-compromised connection.

      TLS Reporting is an extension whereby MTA operators can get reports from other MTAs on which mails succeeded or failed. That is, it lets you see how many mails weren't sent due to MTA-STS failures, which could give you an indication that someone is attempting to attack your users.

    4. Re:Nothing to see here by swillden · · Score: 1

      My servers have been negotiating TLS connections for years. What's all this about?

      What do your servers do when they attempt to negotiate a TLS connection with another SMTP server, but the other server doesn't appear to support TLS? Do they refuse to connect and deliver email? Or do they shrug and deliver it anyway?

      The latter is what you have to do, because not every SMTP server supports TLS. MTA-STS provides a way for your server to check whether a given remote server is expected to support TLS. If yes, and if the TLS negotiation fails, your server can safely assume that something funny is going on and refuse to deliver the mail. If no, then your server can safely assume that the remote server probably really doesn't support TLS, and that probably nothing funny is going on.

      The root problem is that TLS can only defend against active attacks if it's mandatory. As long as the sending server is willing to fall back to a non-TLS connection, then TLS does nothing against active attacks. It still protects against passive eavesdropping, so it's not useless, but it's much less useful. Being able to know for sure when you should demands TLS fixes this -- at least for the servers that support TLS and advertise the fact through MTA-STS.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Nothing to see here by marka63 · · Score: 1

      Well our servers use DANE and TLSA records so they don't fallback if the site has published the record.

      MTA-STS depends on DNSSEC working while, paradoxically, claiming it is needed to avoid DNSSEC. Go analyse the protocol.

      The majority of the worlds authoritative server to recursive server DNS lookups are DNSSEC validated today though the result of that validation may be "insecure". MTA's that support DANE also validate DNS responses. There was never a need for MTA-STS. Just deploy DANE. It isn't subject to the attacks MTA-STS is.

  5. Re:Ads injected into your emails when? by nadass · · Score: 1

    They're already working on the AMP for Email standard -- where email self-modify their contents on-the-fly.

  6. Transport or Network layer Encryption by ironicsky · · Score: 1

    I keep thinking, we keep creating application and service level encryption to protect data transmission - but why not at the stack level, or one level deeper - the transport or network layer? Each physical network device should create a public/private key encrypted connection per remote host they are connecting to, and store that key in an on-chip storage that gets orphaned or erased when the connection closes.

    It seems to me that if we added a deeper level of strong encryption to the physical devices then application level encryption becomes a 2nd level of protection as redundancy. I'm sure people much smarter than me have thought of this, but why has it not become standard?

    1. Re:Transport or Network layer Encryption by cdsparrow · · Score: 1

      Good luck getting any hardware manufacturers getting something like that made on any large scale. Countries don't want encrypted communications.

  7. Any non-end-to-end encryption is crap by ffkom · · Score: 2

    Why would I want to secure only segments of the information transfer when this means there are still plenty of points where adversaries can tamper with my email? The better solution has been around for decades already, it's called end-to-end encryption, and implemented for example by GPG.

    1. Re:Any non-end-to-end encryption is crap by Anonymous Coward · · Score: 1

      Why would I want to secure only segments of the information transfer when this means there are still plenty of points where adversaries can tamper with my email? The better solution has been around for decades already, it's called end-to-end encryption, and implemented for example by GPG.

      Because masses of clueless morons hate learning new things so they won't put in the small effort it would take to learn how to use GPG. ...

      Google, and other webmail providers, could implement GPG and/or S/MIME support in their web clients. Javascript to do all the work already exists. Storage of the certs is a minor issue, but gmail could store them server side and encrypt with the users password (PBKDF2 or similar applied first), or store them in HTML5 Web Storage on the users machine (possibly a configurable option - like,"Are you connecting from a public computer" type of thing). They could start by signing all emails, which would allow all recipients everywhere to detect if the message was tampered with (or it'd be tampered with and have the sig stripped).

      If they did that, it'd take off. Stuff like HSTS (HTTP Strict Transport Security) would be added to indicate "email from this user should always include a crypographic sig, so alert if it doesn't". Once connections are mapped, gmail (and others) would know which recipients can accept an encrypted message, and could offer that, or enable it by default when possible. And this would all work fine with standard clients as well.

      Google is in a tough spot here. They want to be good and add security, but they can't do anything that'd gut their only revenue option with email... if they did end-to-end encryption, they wouldn't be able to read your email and sell info for advertisers. So instead of doing the right thing, they're adding bunches of more convoluted and less standard stuff. This has little to do with how ignorant the masses are - we need to make it transparent for them to use this stuff.

    2. Re:Any non-end-to-end encryption is crap by AmiMoJo · · Score: 2

      Thanks to Snowden we know that the NSA likes to collect and attack email in transit between servers, and doubtless it's popular with other spy agencies. This largely fixes those vulnerabilities.

      Consider that it's much riskier for the NSA to infiltrate data centres to get at these emails now. The risk of detection is much higher, compared to simply sniffing them off the wire on some anonymous backbone router somewhere.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:Any non-end-to-end encryption is crap by Lost+Race · · Score: 1

      Encrypting email "end-to-end" (i.e. at the MUA) leaves the envelope unencrypted, because the MTA needs that info to deliver the message. SSL prevents snooping of the envelope info between MTAs.

  8. Normally, when I consider "protecting my information from eavesdropping", the eavesdroppers I'm concerned about are Google (or Facebook, or Amazon, or similar companies.)

    --
    Your ad here. Ask me how!
  9. Twarthing attacks by Spazmania · · Score: 1

    I too wish to twarth attacks. If you ask nicely, I might even try to thwart them.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
  10. Spam is still not a technical problem by shanen · · Score: 1

    Yep, I didn't realize it was a dupe either, but I'll repost the same comment:

    As usual, the technology remains morally neutral, but another technical bandage is NOT a real solution. Just another flavor of "Live and let spam", and the REAL objective of such weak-@ssed technical approaches is to deny liability for any harms done.

    The specific aspect of spam that bugs me most is the time wasted. If the google was liable for all the time wasted by their support of spam, I think they'd be bankrupt, even at minimum wage rates. Other people might be more annoyed by the abuse of corporate reputations. Or maybe you're annoyed by the abuse of personal information? Or the entry-level-crime argument, especially for phishing and identity theft?

    Anyway, I always want to see the solutions. So what am I doing on Slashdot these years?

    My favored solution approach is to go after the spammers' business models. There's even an obvious proof of concept. Where is all your pump-and-dump stock-scam spam? Gone, gone, gone. Because they went after those spammers' business model--though only after several research papers proved that the scam worked so well it was like printing money.

    Why aren't such approaches being adopted? My theory is because they'd have to work with us. To really fight the spammers effectively they'd need to collaborate with the potential victims. One part of it is that we are the only ones who know our side of the targeting. It doesn't matter how good the spam looks if I actually know that I've never done business with that bank, eh? But the bigger part is that they don't want to reveal how much of our personal information they are already holding. They don't have to ask me for such categories of information because they probably have all the details already. Probably even the account numbers.

    --
    Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.