Automatically enable or disable end-to-end encryption
bugzilla.mozilla.org
bugzilla.mozilla.org
2 years ago it was deliberately revived by Mozilla, then it devolved into bikeshedding about the design and now it's finally shipped.
I wonder how such human factors could be reduced/eliminated?
This is quite amazing, if you think about it. I'm not one to promote conspiracy theories, but if you look at how we horribly botched all implementations of E-mail encryption over the years (that includes lack of development, terrible UI, delays, bizarre and unimplementable in practice standards like S/MIME), it is quite an impressive story.
Meanwhile, the HTTP world mostly got things done, and instant messaging is in a pretty good shape (although I'm still amazed that so many people are willing to sync their entire phone book to Facebook for advertising purposes without a second thought).
HTTPS was already there and working more or less automatically, you just had to make it the default.
E-Mail end-to-end encryption is inherently more complicated to make work, as you need to put the user in charge of key management.
Browser vendors made a big campaign and invested effort into making HTTPS work. Noone did that for E-Mail.
Also it should be mentioned that the same level of security that HTTPS has almost exists in E-Mail. You have transport encryption, it is largely enforced on C2S connections. S2S is a bit more complicated, but even that is mostly solved by now via MTA-STS, which at least the larger mail providers support.
But that does fix the problem. That protects you against opportunistic tapping of wires. A bigger problem is the mass surveillance by POP, IMAP, SMTP and webmail providers (e.g. Google, Microsoft, Yahoo, Apple). They're not affected by HTTPS, because they're on one side of many of those HTTPS connections... and of course this is quite convenient for them.
If you want to be conspiratorial, you could note that Google funded Mozilla for quite a while, albeit only at a fraction of what it owed them in gained income due to having Mozilla / Firefox' default search engine be Google. And while TB was developed integrally alongside Firefox, it got a very small fraction of the resources.
---
BTW, Even E2E encryption doesn't resolve the surveillance problem properly, since those mass-surveillance operations get most of the headers / meta-data.
At first, the argument in favour of maximum encryption may seem compelling. However, upon closer inspection, it falls apart. Essentially, it only makes it harder to read your correspondence for those who give up early. Meanwhile, determined parties, such as large organizations and state actors, can still easily read your correspondence even with this type of encryption scheme.
You might ask yourself, “But Mozilla told me that they would try to encrypt as much as possible!” Instead, the fact is that sometimes they will also have to forgo encryption, because the scheme can only encrypt most of the time. And it’s in those instances that determined parties strike!
As such, this kind of “encryption” scheme really only serves to lull people into a false sense of security, and that is often more dangerous than simply letting people know that their e-mails aren't encrypted at all.
So, for those of you who are inclined to believe in conspiracy theories, the real issue is not that e-mails have remained unencrypted until now. Once you understand that your e-mails are sent in the open, you can take appropriate precautions and avoid sharing sensitive information through e-mail. Meanwhile, if you think that your e-mails are confidential, you might be more inclined to let slip important secrets, when it’s actually being fully disclosed to any determined third party.
The false maxim is that more encryption is better than no encryption. Meanwhile it does not follow that more encryption equals more security or better confidentiality.
Unfortunately, it seems that key exchange alone isn't enough to build a sustainable business on, and, after attempting to be both Slack and Dropbox, they ended up getting aquihired by Zoom to do something only tangentially related. So the product's mostly stagnated.
They were, S/MIME and PGP implementations are both god-awful. The standards leave too much up for interpretation and they leave a bunch of semantic security issues.
> It's simply a very hard problem to tackle, much harder than, say, end-to-end encryption over HTTP (which is of course HTTPS), simply due to the fact that the communication over HTTPS is one-to-one. [...] The consequence of that is that even a safely encrypted e-mail may easily be leaked the second it is forwarded through an unencrypted server, which happens surprisingly often.
This is mostly true. But I have to ask that people split up the technical challenges and the non-technical ones, the trust and encryption parts, the transport and message encryption aspects. All three pairs are very very different and pose different challenges.
It's technically totally doable to generate and distribute for example mailbox-validated S/MIME certificates. Vendors like Apple, Microsoft and Google could automatically request a certificate and store it in peoples' keychains or equivalent.
But with that there's the key storage part that's a bit more difficult though. Thanks to Passkeys/FIDO2 they're basically working on that, but this is the "technical trust" challenge.
It's not a technical problem however to verify the person behind a certificate. It takes a large enterprise or a country to verify someone's identity, not a trivial problem, though in either case some have done it. This is the "human trust" challenge.
Transport encryption is problematic, but you can in better configurations guarantee that letters until recipients are encrypted in transit. If a forwarder also respects MTA-STS, it solves that part.
However there isn't a MUA-STS standard that would force encryption on IMAP and SMTP like we have with HTTPS. This part is really quite dangerous and AFAIK no work is being done with that.
This is certainly not all there is to it, but these things can only be solved one-by-one and separate.
Sure, you might spend time on instituting complicated certificates and warnings. Of this you are of coure entirely correct. Except it's a lot harder to do right for many-to-many e-mail correspondences, that go through a multitude of different recipients and servers – some of which don’t use encryption at all – compared to the one-to-one browser communication, that goes directly to the end recipient, and stops there.
At that point the notion of “one-to-one encryption for e-mail” becomes completely meaningless, because it’s almost never actually one-to-one. The e-mail is frighteningly often sent to some intermediary party, inside or outside your organization, who you do not have any control over, and who will then forward that e-mail – encrypted or not – to the actual end recipient. What that means, is that no matter the amount of encryption schemes you throw onto an e-mail, the likelihood of a leak is still very high. And while undetermined or opportunistic third parties might not gain access to such a correspondence, a determined organization or state actor surely will.
As such, more encryption does not inherently make e-mail more secure. Especially when you know that there are multiple parties handling any given correspondence, with multiple clients and multiple servers – some of which do not use any form of encryption at all. You can never be sure that some user might simply forward the e-mail unencrypted – for whatever reason – down the chain of correspondence. For that reason, e-mail is inherently insecure and non-confidential, and it should be treated as such even if you strongly encrypt your own messages.
In fact, encrypting e-mail might lull you into a false sense of security, because the second that e-mail leaves your client, then the fate of that message is also completely outside of your control.
In order to fix this problem, you essentially need to create an entirely new e-mail system world-wide, with an entirely new protocol. Mozilla simply does not have that capability on its own, though motions to increase e-mail security is of course laudable.
Am I wrong to assume that our difference in perspective is how absolute of a confidentiality we're trying to achieve? The level I think you're describing is very difficult if not impossible even with the best we have right now. However I don't think that should be a showstopper.
I also disagree on the part about a "wholly new email", it's not really practically achievable.
Email is very unique in the sense that it's a massive ecosystem, but the components are really rather independent. Say if clients did S/MIME well we wouldn't have to care that much about MTA-STS for example, we absolutely should, but we wouldn't have to.
A bit of a tangent, but something like letter-strict-transport-security (LSTS) would be totally doable, we could add a header that makes email clients add additional safeguards against potential downgrades. "The letter you're trying to forward was requested to be kept confidential, are you sure you want to send it unencrypted to this recipient x?" After a decade passes we'll probably have a lot of clients that prevent basic mistakes.
Is it? Now, where the people no longer host their own websevers, but leave their content on services owned and operated by other people?
HTTPS isn't really E2E here.
Can I sign or encrypt some comment before posting it to make sure that only people I granted access to it can decrypt it or people can verify my signature on it with HTTPS?
Access control can also be done with mTLS when the connection is established, so, technically only the people you grant access can read it.
Encrypted email embodies an entire encrypted end to end messaging system with authentication of all the users involved in a discussion. The problem is harder and we have not settled on any good usability standard for this. The usability of end to end encrypted messaging is still quite bad for online connected media like instant messaging as well.
Actually the CA/B Forum S/MIME workgroup just recently agreed upon the baseline requirements for future S/MIME certificate issuance. This also means an ACME-like process for mailbox-validated S/MIME certificates is or will be possible in the future.
Identity validation is a much more difficult, human problem. Some countries have solved that for their citizens, but due to how shit S/MIME has been so far, encrypted/signed containers have been used (a lot) instead.
That said, the bigger issue is how messages are stored at rest. Basically all the major email providers support and use TLS at this point, which is plenty strong enough for most mail in transit if you're only worried about the body of the message.
I think we need to worry about mail at rest before trying to make in transit encryption stronger. What's the point of anything stronger than TLS in transit if GMail can just read the full unencrypted message?
I thought the point was to make it so that if GMail reads the message body they see something like this:
-----BEGIN PGP MESSAGE-----
hF4DiRYQNnty8w4SAQdAdiM2arHOheTBYTJriZZQOarZJy39Hs2Hl2tbAM/n5yMw
3DrQEjbJtP2LAm1oxaKPI3cyL05OFMU4p5ZMzbNIChEgNG7dxrUZJ9/0aS1P/8hl
0lkBHVB0DPdgxtLk7tl23iozcnoP4Heua1Lvqf891Cy51409FHk4UX/hUPwg2E/O
mRczP2UVrbBB90CA0L0wRFfXZpPTtq0UusAtPZ4evtzEgcH4pDK5LV7hog==
=vlQ3
-----END PGP MESSAGE-----
That seems pretty useful to me. Sure, they still get to see the subject, the sender, and the recipient list so they get important metadata about my communications. But most of the time my communications are with people that I'm already known to communicate with, and the subject just reveals that the message is about some topic that I'm already known to communicate with them about. All the stuff that would actually be new and interesting to a third party is in the body.
On the other hand I seem to recall tptacek saying that just encrypting the message body is worthless, and when it comes to cryptography that guy's smart. I mean like fuck-a-guy smart. Know what I'm saying? So it is possible I'm overlooking something.
https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
The possibility of E2EE messaging is there by default. Most, if not all, base the critical identity verification on the comparison of super long numbers (just like PGP email). Pretty much no one does that, mostly because they don't know the basic concept behind such numbers.
Relevant:
* https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
Part of this ended up coming from the fact that Thunderbird was not clearly showing the user that the email to a particular recipient was or was not going to be sent encrypted. I am not clear from skimming the discussion that this fundamental issue has yet been fixed.
Just like happened with HTTPS.
At the start not many noticed or cared if their connection was encrypted. Then companies started directing people to the encrypted site and pointing out the padlock icon browsers adopted.
Now we're getting to the point that browser's might fuss about unencrypted connections.
Same could have been done but they got caught up in well if we have any encryption. It should all be encrypted false dichotomy.
Or am I just adding to the bike shedding?
TLDR: people argued whether it is bad or good feature, this was sidelined as low priority, users 2 years ago made a last push to implement this feature, They came to an agreement that responsibility of encryption is on message thread members and having unencrypted only is a worse option than the application sending encrypted where possible, feedback was collected on how the user experience should be implemented, and lastly the automatic selection feature was implemented.
Users should still look into how this was implemented and give feedback on possible security/privacy concerns that may need to be implemented when the automatic feature is enabled. types of toggleable features that should be implemented and may not be is confirmation dialogues, message encryption per recipient/thread, visual indicators of received/sent messages being encrypted/unencrypted, and more. This is up to the developers to implement this to the GUI. I have not explored the new feature in its entirety.