How does the E2EE happen if you're clicking a gmail link? One thought is the secret bit is tacked onto the anchor part of the URL, but the secret is in plaintext both on the senders sent email and on the recipient side.
Gmail E2E is as terrible as expected
61–70 of 70 posts
Re: Gmail E2E is as terrible as expected
#62Earlier quoted context omitted.
> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. It was never really solved, PGP email is a usability disaster. Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire c…
It’s a disaster because email providers don’t want to offer E2EE or make it easy. Is it that hard to generate a certificate for each email address client side and store that, and the private key encrypted with the user’s password, on the provider’s server? The majority of email is gmail and Google could make that E2EE by default. Countless products that have successfully implemented public key distribution (proton ma…
This would be a reasonable proposition if the entire Internet mail system was run by 3-4 operators, and there were no mail clients at all other than service provider webmail.
Unfortunately, the real world is much more complicated than that.
Re: Gmail E2E is as terrible as expected
#63People in China could not open a url sent in Gmail. I happened to be in China, I tried to open the webpage and it worked, no firewall. I hovered on the link in Gmail and Chrome told me left bottom it was just that exact url. But when I opened the url it got blocked by the great firewall. Why? Any link in Gmail secretly gets replaced by a link to Google that tracks you and then redirects you to the original link. The…
That’s a classic technique to track click through rates. Google.com has done this forever. The technique is to make an actual link in HTML ( ) then add an event handler which cancels the link’s default behaviour when you click it - and replaces it with javascript, or a tracking link. I understand why Google.com wants that data. But in an email client it’s extremely obnoxious.
I hate it even more in Google calendar where they don’t even bother to use that JS. I’ll copy a zoom join link from an invitation to send to someone, and I get some sh**y Google redirect URL.
Re: Gmail E2E is as terrible as expected
#64email is dead, even gov's use chat clients with emoticons ;)
That email is your internet id and majority countries digital id too ? Who cares, things usually need to be so broken that even elected officials families report problems :) Then we can have some "plans" announced. EU is especially good at this - announcing (and pushing for more centralization no matter what is happening) and not fixing anything, eg. sane CPU's, when ? Rhetoric question because not in this decade...
Re: Gmail E2E is as terrible as expected
#65Earlier quoted context omitted.
> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. It was never really solved, PGP email is a usability disaster. Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire c…
While I'm sure some of these flaws also apply to S/MIME, I feel like its client support (even in Apple iPhone native mail app) is far superior to PGP. Apple made S/MIME installation and use across its ecosystem, and I remember it being easy in kMail once upon a time when I used KDE; why didn't S/MIME ever catch on?
It did, but on enterprise level. S/MIME uses the CA hierarchical trust model, which is centrally managed and much more compatible with how internal enterprise structures are built. In a large enterprise you would have IT managing your AD/CS and therefore also managing the issuing, revocation and so on of employee certificates. But for the public this model of management isn't really practical.
Re: Gmail E2E is as terrible as expected
#66The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. Then there were a whole plethora of products were build around Lotus Notes Domino that provided a central place for securing outgoing E-mail using either S/MIME or GPG keys. All of this on premises. Then came the Cloud and obliterated these products. And for what? edit: typos
> The E2E problem has already been solved long time ago. We used to have Thunderbird with an OpenPGP extension and GPG keys. It was never really solved, PGP email is a usability disaster. Client support (especially on mobile) is limited. Headers, including the subject line remain in cleartext. Users forget to click the "encrypt email" button and so messages go out in the clear; sometimes in reply, and so the entire c…
Indeed using PGP for personal E-mail was never easy and required sufficient knowledge from end users. Using it in corporate setups was a piece of cake and I've seen it personally. I had been using and working on software that manages PGP keys centrally, end users did not have to do anything about encryption or signature verification. The problem was indeed solved. Arguably that is what Gmail tries to (poorly) do right now.
> Not to mention the extra issues caused by HTML in message bodies.
Proton Mail came out with a pretty good statement about this and I fully agree.
> Recommendations to disable PGP plugins and stop encrypting emails are completely unwarranted and could put lives at risk.
Re: Gmail E2E is as terrible as expected
#67Earlier quoted context omitted.
Yep, while I like moving all snail mail to email, I hate that (almost) every single service now just sends a "monthly/quarterly report now available in your account area!" email. A rare few of them at least offer the option of just sending it attached (with the default being a useless reminder email), but most are essentially a chore, because nearly everything here uses phone+2FA as login rather than a password or pa…
> because nearly everything here uses phone+2FA as login Here in the US we only wish things were that secure. Unless by 2FA you mean “code sent via SMS”.
Sadly I mean "code sent via SMS", which is one reason why I haven't automated much of the retrieval for these things.
Re: Gmail E2E is as terrible as expected
#68Earlier quoted context omitted.
While I'm sure some of these flaws also apply to S/MIME, I feel like its client support (even in Apple iPhone native mail app) is far superior to PGP. Apple made S/MIME installation and use across its ecosystem, and I remember it being easy in kMail once upon a time when I used KDE; why didn't S/MIME ever catch on?
It did, but on enterprise level. S/MIME uses the CA hierarchical trust model, which is centrally managed and much more compatible with how internal enterprise structures are built. In a large enterprise you would have IT managing your AD/CS and therefore also managing the issuing, revocation and so on of employee certificates. But for the public this model of management isn't really practical.
I've worked in an org that used S/MIME heavily.
In a managed environment, you also get the advantage of certificates stored in a central directory (LDAP etc), and so certificate selection for the client is seamless.
All you have to do is hit "encrypt" in your mail client, enter your smart card PIN and the machine does the rest.
Re: Gmail E2E is as terrible as expected
#69Earlier quoted context omitted.
For PGP keys to work, users also need to publicly broadcast who they know and personally trust. It’s a privacy disaster.
You can just send your PGP key to your correspondents attached to an email. There is even a mime type for it. There is no need for any public broadcasting. The big problem is verifying identities. The usability of that is an unsolved problem that plagues encrypted messaging of all kinds. So sure, signing PGP keys as a form of introduction is awkward, but at least it is possible. How do you vouch for, say, a Signal us…
If I attach a pgp signature in an email, it’s trivial for a MITM attack to replace my signature with their own. Without any way to verify who owns the key that was used to sign your message, what good is it? I suppose I could publish my key on my website too, but that’s a usability nightmare for everyone involved. A mitm attack could also just strip off the signature and alter the message I would be none the wiser.
Signal uses a much more complex key ratcheting system. It’s TOFU, but the key rotates with each message I send. The first message is vulnerable to a MITM attack, but because of the way signal works, if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure. The earlier keys are also published to make messages deniable. (Aka OTR).
Even then, if you want to verify who you’re talking to, you can click on someone’s name in signal and click “View safety number” and verify the code through a separate channel. Like, in person or over a text message or something.
Because your code is different for every conversation, it protects against correlation attacks. That is to say, a 3rd party watching the traffic can’t tell that all of the messages you send to different recipients came from the same person. Email+PGP doesn’t encrypt the most important information - which is the identity of the sender and receiver.
Signal is way better than pgp-over-email in every regard. The UI is better. There’s no encouragement to publish your keys or your social network. And the security ratchet is better than the static key that pgp uses. I’d pick it every time.
Re: Gmail E2E is as terrible as expected
#70Earlier quoted context omitted.
You can just send your PGP key to your correspondents attached to an email. There is even a mime type for it. There is no need for any public broadcasting. The big problem is verifying identities. The usability of that is an unsolved problem that plagues encrypted messaging of all kinds. So sure, signing PGP keys as a form of introduction is awkward, but at least it is possible. How do you vouch for, say, a Signal us…
If I attach a pgp signature in an email, it’s trivial for a MITM attack to replace my signature with their own. Without any way to verify who owns the key that was used to sign your message, what good is it? I suppose I could publish my key on my website too, but that’s a usability nightmare for everyone involved. A mitm attack could also just strip off the signature and alter the message I would be none the wiser. S…
We are talking about public keys here, not signatures.
>It’s TOFU, but the key rotates with each message I send.
You seem to be confusing the Signal long term identities with forward secrecy.
>...if I can ever send a single message to you which isn’t MITM-ed, every message sent thereafter will be secure.
This isn't true. Signal verifies identities the exact same way PGP verifies identities. As with PGP if you haven't checked your "safety numbers" you can't be sure your messages are actually ending up with your correspondent.
>Because your code is different for every conversation, it protects against correlation attacks.
PGP normally uses a different session key for each and every message ... but that isn't really relevant for either the Signal or PGP case if we are talking about correlation. For efficiency and convenience each message is normally tagged with the encryption key fingerprint of the recipient but you can turn that off if that might be a problem in your particular application. At that point there is nothing an observer can use to determine anything about the sender or receiver.
You probably meant to reference Signal's "sealed sender". It doesn't really work in practice:
>https://www.ndss-symposium.org/ndss-paper/improving-signals-...