Gmail Becomes First Major Email Provider To Support MTA-STS and TLS Reporting (zdnet.com) 44
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.
It it doesn't use blockchain (Score:2)
I want nothing to do with it!
Twarthing attacks (Score:2)
I too wish to twarth attacks. If you ask nicely, I might even try to thwart them.
Skeptic in me says they have ulterior motives (Score:5, Insightful)
Re: (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.
Re: (Score:2)
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.
Re:Skeptic in me says they have ulterior motives (Score:5, 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.
Re: (Score:1)
Twarthing? (Score:2)
Come on editors.
Nothing to see here (Score:2, Interesting)
Re: (Score:1)
Re: (Score:3)
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.
Re:Nothing to see here (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.
Re: (Score:2)
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 f
Re: (Score:2)
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 subj
Transport or Network layer Encryption (Score:2)
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 a
Re: (Score:2)
Good luck getting any hardware manufacturers getting something like that made on any large scale. Countries don't want encrypted communications.
Any non-end-to-end encryption is crap (Score:3)
Re: (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
Re: (Score:3)
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.
Re: (Score:2)
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.
Why? (Score:2)
Normally, when I consider "protecting my information from eavesdropping", the eavesdroppers I'm concerned about are Google (or Facebook, or Amazon, or similar companies.)
Spam is still not a technical problem (Score:2)
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