Are new Google E2EE emails really end-to-end encrypted? Kinda, but not really.
- Thread starter JournalBot
- Start date
tbh - this feels very very similar to the many commercial email encryption services out there...
Upvote
4
(4
/
0)
E2EE in the exact same way as in all messaging apps. I have been complaining about tech journalists calling that end-to-end encrypted forever. So here we are with this new definition they have accepted being used to water down real E2EE on emails.
Upvote
-4
(1
/
-5)
If I'm enterprise A that has a need for encrypted email then I also probably have a need for communication retention for certain legal reasons. That probably means I can't let the ephemeral keys be deleted because I can't afford the risk of not being able to decrypt legally mandated messages just because Bob or Alice haven't opened them. Therefore key retention seems like it becomes a critical policy, and the KACL becomes the obvious point of attack vs the users mailbox. Once I control the KACL I own your email.
Upvote
5
(5
/
0)
If the alternative is MoveIT; rest assured that it's also not secure; but at least it's user hostile.
Honestly, email is in sort of a weird place in terms of being both over and under trusted: If your threat model is your mailserver operator it's probably worse now than it has ever been(even fairly substantial companies often farm out email to one of the cloud vendors or a managed service instance, spam blocking means that even a willingness to geek it up yourself will encounter deliverability problems, and individual consumer accounts are almost entirely provided by adtech guys with somewhat limited privacy policies). If your threat model is sending stuff to the wrong people it's probably somewhat worse than it was(more smartphone autocomplete/guesses from several different contact lists; somewhat less email from single-entity devices where allowed recipients and potential address list autocompletes are heavily managed); but if your threat model is stuff getting snagged off the wire we've never had it so good.
I was actually asked to go grubbing after this detail at work a few weeks ago (modest mail flow; ~100k emails a day, opportunistic TLS except for a few specific external parties where we have mandatory TLS); and 100% of the mail moving between the server and internal users were on encrypted transports; while SMTP to/from remote mailservers was over 99% TLS; with most of the plaintext being really shit 3rd party email marketing nonsense.
Obviously if Alice wants to talk to Bob without having to trust two mailservers, including one she might not even know the identity of ahead of time, she's going to have to encrypt at the message level; but it looks like the shift to TLS as a default rather than a special occasion has been as broad in email as it has with websites.
Upvote
3
(3
/
0)
Proton is wonderful. I recently switched to them because I don’t want all of my most important accounts tied to a US email provider in a country whose administration increasingly hostile to the rule of law and non citizens living in the US. Sadly, I wouldn’t put it past this administration to just cut people’s account access using arbitrary criteria or for speaking out against them. Nevermind the risk of plain text emails being swept up in a dragnet by powerful agencies that are losing their trustworthiness.
It seems like now is as good a time as ever for regular people to reduce their reliance on US companies for essential communications and to protect their speech with E2EE. The only issue is getting family to make the switch—I’ve had to do the lifting for some of them.
Upvote
8
(9
/
-1)
It has been rethought at least twice. It was rethought as OPENPGPKEY records in DNS. The domain of the email address and a hash of the local part become a domain name that you look up to get the public key for that address. The owner of the domain is in control of the DNS records, and DNSsec guarantees that the response is genuine, so fake keys can't be uploaded by just anybody.
But most DNS providers expect customers to manage DNS records through their proprietary limited web interface. They aren't interested in adding support for some obscure new record type that only one odd customer asks for, and if they did, client programs would have to implement support for each proprietary web interface to be able to upload keys. And nobody bothers to verify DNSsec signatures anyway.
So to get around the DNS roadblock, the key handling was rethought as Web Key Directory. The domain of the email address and a hash of the local part become a URL that you look up to get the public key for that address. The owner of the domain is in control of the web server, and HTTPS guarantees that the response is genuine. Client programs upload keys by sending them to a designated email address. A challenge-response protocol over email, based on the assumption that an email provider can securely deliver mail to their own user's inbox, ensures that fake keys can't be uploaded by just anybody.
But email providers aren't interested in implementing and managing some obscure new service that only one odd customer asks for.
It's the same problem as with IPv6, IDNA, IPsec, SCTP and every other attempt to improve the Internet: Nobody can use it because vendors don't support it because customers don't demand it because nobody else uses it because their vendors don't support it because ...
Upvote
7
(7
/
0)
With one important difference: SMTP over TLS is usually only opportunistic encryption. If Mallory intercepts your SMTP session, he can make it look like the server doesn't offer TLS, and the client will happily send the message unencrypted. A web browser given an HTTPS URL won't silently switch to plain HTTP if Mallory blocks the HTTPS port.
Upvote
-3
(0
/
-3)
One simple improved security feature I would like Google to add is passwords for docs and spreadsheets. It would add an extra level of security. This is especially needed because Google defaults to all editors being able to modify permissions, and people can also easily add people in error when Gmail pops up the "This person needs access to this file" when a link is included in a group email.
Your security defaults are poor Google!
Hint: If you upload a password protected Word doc to Drive, Google will ask for the password before letting people view it.
Your security defaults are poor Google!
Hint: If you upload a password protected Word doc to Drive, Google will ask for the password before letting people view it.
Upvote
-1
(0
/
-1)
Proper use of IDPs mean that when the IDP is intercepted, it's used and dead.
The intended recipient knows there is a breach when they try to use it and restarts the process.
Upvote
0
(1
/
-1)
TLS has nothing to do with message encryption... It's transport level
Upvote
-1
(0
/
-1)
Thanks - that really shows how long ago I stopped paying attention to PGP.
Upvote
0
(0
/
0)
That is true. Mandatory TLS is definitely the way to go. I was just pleasantly surprised, when looking at an opportunistic TLS mailserver, that TLS useage was above 99% and that, realistically, nothing important would break if I had gone in and flicked things to mandatory TLS across the board.
I wouldn't trust opportunistic TLS against a sophisticated adversary actively gunning for me; but it's way, way, easier to enforce mandatory TLS when the numbers for opportunistic are so good; rather than it being something you have to be super careful about because 10% of SMTP servers support it and half of recipient orgs will look at you like you have 3 heads if you even ask.
Upvote
3
(3
/
0)
Seems like it's E2EE as far as companies are concerned. When you are sending work emails you aren't expecting them to be secret from your employer. I"m pretty sure most companies wouldn't even allow completely E2EE emails because it would prevent audits and investigations.
Upvote
3
(3
/
0)
Google has probably done more than anyone to undermine proper security in the modern era.
Let's examine two plausible alternatives.
1) We use DNSSEC to secure DNS (i.e. no more cache poisoning attacks)
2) We use DANE to extend this to HTTPS for everything with a DNS address.
3) We use S/MIME with public keys in DNS to allow end to end encrypted email for everyone. Email can now be authenticated and encrypted. No more address spoofing, no more scraping of emails by email providers.
Vs. what google is proposing.
1) We don't do anything to secure DNS.
2) We use let's encrypt to provide TLS certificates, based on known insecure DNS.
3) We use this scheme to do encrypted email, requiring people to constantly log in to unknown servers in order to retrieve their emails, and this validation is easily spoofed by anyone who can already read the persons' emails.
So basically the E2E encrypted email becomes so unwieldy that nobody can plausibly use it, and as a result google gets to keep scraping everyone's emails for ad targeting.
Yay, I guess?
Let's examine two plausible alternatives.
1) We use DNSSEC to secure DNS (i.e. no more cache poisoning attacks)
2) We use DANE to extend this to HTTPS for everything with a DNS address.
3) We use S/MIME with public keys in DNS to allow end to end encrypted email for everyone. Email can now be authenticated and encrypted. No more address spoofing, no more scraping of emails by email providers.
Vs. what google is proposing.
1) We don't do anything to secure DNS.
2) We use let's encrypt to provide TLS certificates, based on known insecure DNS.
3) We use this scheme to do encrypted email, requiring people to constantly log in to unknown servers in order to retrieve their emails, and this validation is easily spoofed by anyone who can already read the persons' emails.
So basically the E2E encrypted email becomes so unwieldy that nobody can plausibly use it, and as a result google gets to keep scraping everyone's emails for ad targeting.
Yay, I guess?
Upvote
0
(1
/
-1)
Feels a bit late for this, when FastMail and ProtonMail exist. Partnering with one (or both) of those options seems like it might've been a better use of Mozilla's remaining cash. I still wish them success.
Upvote
4
(4
/
0)
I love PGP, but the little amount of extra steps you have to go through and the extra brainpower you need to understand what it is puts a lot of people off.
Corporations may be mandated to preserve emails for auditing, ie. when Trump scammed the banks or violated national secrecy laws or paid for sex hush money from campaign funds, people need to prove it from emails. If your keys are privately held they'd have to come find you to audit what you sent on behalf of the corporation, or worse, you could lose or throw away the key.
Plus, publishing your public key assumes nobody else masquerades as your email address and publishes another public key to be a MITM.
Additionally, getting registered websites as trustable involves registering with certificate authorities who distribute their CA keys in all major browsers and operating systems. There's little chance the average person wants to pay and go through registering to publish their public key through a publicly trusted CA when most expect the provider do it for them.
Then when your email PGP key is conpromised you won't have any recourse on revoking what people already downloaded from when you posted it the first time.
Etc etc etc
The email industry have never had to become key authorities at the same time.
Upvote
1
(1
/
0)
This is the problem they are solving. People aren't wrong that this isn't making email truly secure but this isn't trying to sell that.
I'm sure y'all (in the US) have gotten emails from your healthcare provider that is just a link to a portal you have to then log in to. Only to log in to the portal to see a link to your lab result or some other reminder. This is because the healthcare provider is trying to comply with regulations and just doing something where they can guarantee the message was encrypted (i.e. viewed in an HTTPS only web portal) even tho the messages was innocuous and very low privacy risk.
That kind of business problem is what I'm seeing Google trying to resolve. Right now an organization may already be not be using Google Workspaces because they have to use some other "secure email system". Even tho I'd argue some of those company's security practices aren't even close to the level of actual security protocols and systems Google is using in the backend. Those other businesses are just compliant.
Upvote
1
(1
/
0)
The biggest pains with actually using PGP everyday is client support, the minimal (virtually nonexistent) validation done by the free key servers, and the lack of a standard way to auto-discover key servers other than the big public ones. Once you’ve got a client that can do it, setting up a key is straightforward, and using it can be set to be transparent, automatically encrypting where possible and/or signing everything.
Upvote
1
(1
/
0)
I'm doing the same. I'll take the subscription that includes a VPN and 500 GB storage, far away from Google prying eyes. They did drop their initial "don't do evil" motto for a reason.
Upvote
2
(2
/
0)
...passkeys and tokens...
Integration is the entire point of this. This is an intermediary step. This step places email systems one step removed from current nightmare-realm implementation, and moves toward a more robust and also much-less-safe for end users system.
Can't have both privacy and security. It's really one or the other. Keep the privacy and ditch the invasive and intrusive security, or keep the intrusions and invasions and lose the privacy.
We know how the USA's Founders felt about this...
Upvote
0
(0
/
0)
They already had a perfectly good name for this in "client-side encryption" -- why misuse an established term (E2EE) to market this?
I miss Old Google.
Edit: If CSE wasn't good enough, they could've just made it CSED for "Client Side Encryption and Decryption" and still not needed to misuse E2EE.
I miss Old Google.
Edit: If CSE wasn't good enough, they could've just made it CSED for "Client Side Encryption and Decryption" and still not needed to misuse E2EE.
Upvote
0
(1
/
-1)
WalterFrank
Smack-Fu Master, in training
Nice upgrade for Gmail security, but it’s not full end-to-end (maybe?), admins still got the keys.
Upvote
0
(0
/
0)
Mary can easily show the correspondence she received. It might even be signed with John's key!
Agreed on the Bob case.
Upvote
0
(0
/
0)
Because it is the exact same "end-to-end" encryption as in messaging apps. So they use the term the customers are most used to, since almost nobody has complained about the term in messaging apps.
Upvote
0
(0
/
0)
There's a reason the administration uses Signal for theri discreet comms. It's because they know everything else is compromised. Even their own in house apps.
Upvote
-1
(0
/
-1)
So this is E2EE-ish, but you have to trust the database in the middle and all the protections around that. Not so different to BlackBerry Messenger.
Though it's not so very different level of trust for apps like WhatsApp, Signal. With those you're not trusting a database in the middle, but you are trusting a source code repo and build system to be properly protected. If someone can change the source code for some and pump out a modified client, you're just as compromised in not so very a different way.
It's all a matter of how many eyes are on the source code, audit logs, etc, looking for stuff that shouldn't be there. And across the different apps, that varies between "good" and "who knows?!".
Though it's not so very different level of trust for apps like WhatsApp, Signal. With those you're not trusting a database in the middle, but you are trusting a source code repo and build system to be properly protected. If someone can change the source code for some and pump out a modified client, you're just as compromised in not so very a different way.
It's all a matter of how many eyes are on the source code, audit logs, etc, looking for stuff that shouldn't be there. And across the different apps, that varies between "good" and "who knows?!".
Upvote
0
(0
/
0)
True, but key escrow accessible my administrators is useful (although the non repudiation aspects are good for Mary if John is extra-stupid) for other situations. Lawsuits and evidence retention, for example.
Upvote
0
(0
/
0)
The issue is this is not good but ok, and it provides a false sense of security (which is kind of the point as they implemented it so that organizations that have to be compliant with whatever standard can use their services or use them without additional software/setup like s/mime).
Upvote
0
(0
/
0)
Upvote
0
(0
/
0)