Privacy in email communication: we should use encryption by default(notes.nicfab.it) |
Privacy in email communication: we should use encryption by default(notes.nicfab.it) |
In fact, we don't need to rewrite the email protocols to add E2E encryption, as Delta Chat has shown; and if backwards compatibility isn't a goal, then everyone could just move over to Matrix, instead of reinventing email.
Implementing something like a mix net for email is actually not that difficult once PGP encryption can be assumed. Basically you'd just need each mail provider to offer a "switchboard" address in a .well-known location (or in the DNS), so that Alice can wrap her message to Bob in an outer layer message that's encrypted using Bob's provider's switchboard address's public key.
This prevents Alice's provider from knowing who specifically she was sending the message to (it would only know which provider). Also, as Alice's message would contain her signature to authenticate it, her provider could use its own switchboard address as the sender, so that Bob's provider wouldn't know it was Alice specifically who sent it.
my Debian postfixes with their default config certainly don't
It’s particularly stupid as I then don’t have a copy of the email myself, and they have disabled text selection on the webpage so I can’t even copy and paste it (easily)!
I suppose it ensures that if the recipient isn’t using TLS with SMTP then it’s not sent unencrypted over the wire, but I suspect the vast majority of email servers are using TLS now. If someone hacks my email they have access to it anyway. I wish the system was intelligent enough to turn itself off if the recipient server has TLS, then I could almost support it as a concept.
But if someone is watching your unencrypted connection to your mail server they can just follow the link and then watch the password being sent. So meh, stupid pointless thing.
Go to about:config, and search for dom.event.clipboardevents.enabled and disable it.
These unfriendly encryption mechanisms also let us actually retract a message if it was sent to the wrong person, a feature that is on the honor system in traditional implementations.
On the user end all they know is that if they put [encrypt] in the subject they won't be written up by their compliance department. People really like not getting fired over clerical stuff so they over-use it.
It can still be forwarded (after extracting from a badly implemented site). The "ensure the right person got it" password is stupid as its literally sending it to the same email address.
The thing I find so bizarre about this is that lawyers/accountant etc. have been seeing out letters in the post forever and never had the desire to implement this level of security. Post can be intercepted, read by third parties and modified at will, just like unencrypted email. The only thing that's changed is that because there is supposedly the ability to do it someone has lobbied for there to be a mandate for it.
Just because it "can be done" doesn't mean is should or that it achieves what the motivation was.
If there is something that important that it can't be in the wrong hands then either do it in person or sent a courier with the signed for letter that requires id on delivery.
These systems are nothing other than security theatre that's sold to the unknowledgeable as something they need, when the reality is it's a complete waste of everyones time. (except for the person selling it!)
This is pretty much impossible. It's DRM. It's a pain in the ass for everyone while still not preventing the thing that it is supposed to. The analog hole (https://en.wikipedia.org/wiki/Analog_hole) is always there if nothing else.
Please don't encourage the use of broken software that is fundamentally flawed. I'm not unsympathetic to the goal of controlling the spread of certain information, but when the product plain doesn't work (preventing selecting the message text isn't stopping a cell phone pic for example) and it gets in the way of regular rule-following folks who have to take their time to get around it that's not helping anyone. It's just a total waste of time/money for all involved.
which our internal research shows is the typical way of exfiltrating information when right click is disabled by javascript
wear eye protection
All across the board MS picks the wrong people to say 'No, tough shit, gtf over yourself." to. They say it to normal users who want to do reasonable things, instead of to business owners and managers who want powers they have no moral right to.
It's fundamentally impossible to control information after it is communicated, no matter what technical gimmicks you concoct, and so it's invalid to even try in the first place. It's barking up the wrong tree and only harming the innocent and not even hindering the criminal.
If something is that precious then keep it in an airgapped lab and frisk people for cell phones at the door, and get nothing much done with that data that's so inconvenient to access.
If you need other people to access the info, then get over yourself and simply have people sign standard legal agreements. If the recipient gets hacked or something then they get hacked. That will still happen regardless. The annoying special access didn't change anything. A hacked client machine can siphon that same data.
MS just doesn't ever say "get over yourself" to the right people. They say it to you & me but treat the most offensive ideas from buisiness owners as very serious and valid needs.
It's made them a lot of money so it's not changing of course. I don't mean to pretend that there is any way or any remotest hope to change that. Only to point out how it's fundamentally wrong, and one of the reasons to simply try to avoid using any of their products and services as much as you can manage.
Goes all the way back to read receipts. The knowledge of when exactly I viewed a correspondence is obviously useful to a sender, but that usefulness does not make it something they have any right to, no matter what the excuse or rationalization is, no matter how much you try to invoke important sounding things that the message might have been about or how important sounding the consequenses like if a court case hinged on proving that you received a message or something. Not only does no one have the right to that knowledge, the mechanism doesn't even prove what it claims to prove anyway. A read receipt still does not prove that I read a message, only that an email client performed the transaction. If you really need an ack for a message, then you have the recipient, the person, send an ack, as in send another message back. Or send the message via a process server. If it's not important enough to justify a process server, then it's just not that critical and you should just get over yourself and accept that the recipient will get to it when they get to it, and you will survive not having this bit of control and visibility into someone else's life.
I discovered setting up an old IP camera recently that it’s now very hard to send an unencrypted email via SMTP. Nearly all servers refuse to relay unauthenticated emails (no username and password), and only permit authentication if the connection is SSL or promoted to SSL via STARTTLS (ie encrypted).
(I mention it because the camera wouldn’t cooperate or tell me what the problem was - ended up having to learn Wireshark and read the relevant RFCs re Authenticated SMTP).
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read, and for those people, encrypted email is LARP security. It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
Totally agree that there is no way of doing email right. If you want security, use other messaging systems, like signal, for all the reasons explained in that post.
Email can be thought of as an encrypted communications protocol where the parties can negotiate down to plain text. In other words, it isn't encrypted communication, it's bare communication over which the user might choose to send encrypted information.
Something with the ergonomics of email, but built over a platform with enforceable E2E such as Matrix, would be quite welcome. But it can't be an extension of mail protocols, or reuse the email address space, so it won't be email.
And it'll be harder for your email address to be harvested by bots since they'd have to actually download the key to see what address it's for.
Encryption at rest is another problem, one that I'm not even sure most users want.
With encrypted email, encryption at rest and encryption in flight are the same process. It uses an encrypt once scheme[2] which simplifies things immensely. As a result you only have one level of security to worry about.
At rest also a decent idea. Even if provider have the keys.
End-to-End however in system where you need to be able to send message to anyone and expect it to work is rather big can of worms.
I mean, sure, but let's be honest, a big majority of that is going to be spam, the next step down from that are silly little things like email verifications, password resets, notifications, newsletter spam, and other similar crap. As a millennial who doesn't touch emails for work or for personal reasons (because there is Slack, Signal or some other alternative to those two), I could very well be out of touch, but I'd be surprised if actual legitimate emails (both business and consumer) are more than 5% of that number.
I suppose 5% is still a big number, putting it at a comfortable ~16 billion emails.
Anyway, yes, we should be using encryption by default wherever possible, but honestly, encryption isn't easy for the common folk, which is going to be the majority of those 333 billion. Heck, I migrated away from PM and I struggled with a lot of it. As someone who mostly lives in the CLI, GnuPG is not easy to use. Something like MailVelope makes it easier, but still not that easy.
Then there is the matter of administration. Your sysadmin, especially of the bigger orgs, do not want encryption on your emails. Especially when the business you're in is regulated. Imagine being able to casually leak something without anyone knowing what's in the content? I know regulation is usually not a good answer for why not, but within a business, yes, it totally is. As a customer of Big Bank Corp, I do not want employees to be able to mess with my data, money, or worse, the money of the bank so that it can fail and for my money (or the tax payer's in case of govt protections) to be gone because everyone's emails were encrypted.
The only viable solution here is something like ProtonMail, which actually makes it easier to use, at $/£/€ 5 per month, not many are able to afford to part with that. And no, their free tier is really not that great. But regardless, even PM doesn't really help if a non PM user sends you an email.
- it's about time people rediscover that emails are not webmails, even if except for few "geeky" modern MUA the real development of MUA is stuck at '90s level emails can and should be perfectly locally synced, accessed, sent and used in the more broad sense;
- I do not care about "secrecy" of my mails simply because I do not mail myself normally but third parties, since I have no control on them, no knowledge of their systems I can only assume that my messages will be public anyway. Yes, as many I have few friends with GNUPG keys, cross-signed in various occasions etc, but that's just "for fun", not for real usage simply because if GNUGP/PGP became a widespread habits anyone took it's almost useless: I do not have to discuss anything really secret via mail with some friends. At maximum I might have to privately contact third parties signaling a vulnerability, but in most cases those parties do not have a public key either...
- even if we arrive en masse to local/classic mail usage, with IMAP sync-ed maildirs, locally indexed, locally used etc, encryption can be useful ONLY if the system it live on can be trusted. Using a "safe" system on a proprietary OS on top of proprietary hw is not much different than mounting a super-strong door on a very fragile wall, a thief just need to detach the door from the wall without really facing it.
Spam detection is much more effective when you have access to the plain text of email as you can both build out better models of "this is spam" based on your entire customer base marking things that you miss or get wrong.
You also get to more trivially go "oh this email is only (say) 60% likely to be spam, but it was also sent to 200k people who have no relationship, so maybe it's closer to 90% spam".
The real killer is financial, all the "free" mail providers are making money from hosting your email. Gmail is especially egregious in this regard, and scans the content of inherently private communication in order to build out it the google surveillance infrastructure. Gmail's scanning is why companies like amazon no longer include actual order information in the emails that they send out.
A true E2E mail system (in which email was decrypted on the client side), would run counter to the googles goals for gmail.
What I'd love to see, though, is that organizations (banks, authorities, etc.) start using such systems as well so that they can actually send documents e2e encrypted.
Email encryption needs to be standardized and available in common email clients. A few proprietary providers is not a real, effective substitute.
But of course, the privacy invading "free email" providers would never play along with this.
The problem when approaching the issue especially with not-so-technical people is the difficulty of explaining how encryption would work in this scenario. Unlike Signal where a user A sends a message to a user B and the transmission is encrypted because they are using the same protocol, email is a bit trickier to explain. It would be like sending a Telegram message to Signal. Someone needs to do some conversion from one to another. Even when they use encryption, the methodology applied to encryption can be different.
So while I agree with "we should use encryption by default" for non-technical users, this isn't as straightforward. The top comment highlights an issue of the current "send a link to their server" approach, which is what Tutanota uses for example. Everyone moving on to encrypted emails would entail a mass education of users to use PGP keys for example, managing the keys themselves, understanding encryption at rest and the list goes on...
Finally, users are horrible at remembering/maintaining their passwords. Fully encrypted services such as Protonmail and Tutanota (I know proton doesn't encrypt the subject line) do not really offer password resets in the classical way - "Oh I forgot my password, well, here's my phone number give me a new password" or "just send me a reset link to this other email". This means that there is a very real risk of losing complete access to your email address or potentially losing a lot of emails. I believe Protonmail allowed password resets but it would wipe your inbox and Tutanota only allows reset using the account key that you have to generate and save somewhere, but again, a user would need to be aware of this and manage it well...
Great idea. We should. We won't, or at least, the majority won't.
example: `0x9be5d213245be984c0fb806a1d92c03a05448a4d@example.com`
It would still accept SMTP as backward compatibility and also implement e2e protocol without leaking metadata on side. It could implement other endless cool stuff on top of that (roaming with notifying addresses that you moved to new @example2.com. Send some crypto for better ranking in inbox as optional spam protection.
i did Ask HN about the idea few weeks ago but it did not get traction but there were people who liked idea and dm me in tg/discord, feels like this might be good place to resubmit it.
I like this idea. Eventually we are going to have to come to terms with the fact that there is going to be a ridiculously long number and that number is the identity. We can't hide this fact from the user and hope that things are going to work out.
Also, Matrix TCP port 8448 is meant for federation, not for client communication.
I have a feeling that Gmail could virtually single-handedly make E2E email encryption a standard practice with good UX, but they would rather be able to read your email.
Because mail MITM is extremely rare. It's much more likely your cell phone texts will get intercepted during 2FA rather than your mail.
And actually, if I had to send an encrypted email, I wouldn't use PGP. I'd send an encrypted zip file.
That itself has a standards problem. Most people don't have anything more than the archive reader installed with the OS which for Windows means nothing better than ZipCrypto is supported IIRC. ZipCrypto can be broken so trivially, that it isn't worth bothering with. 7zip and other tools support stronger methods, even with .zip archives, but many people can't read the result.
There is also the good old key exchange problem as you are using symmetric encryption: you need a second channel to send the key over. Fine for friends and others you already have more than one contact route between, there are a number of ways to communicate after all, but not for general comms. It is scary how many people in a supposedly security aware industry I see sending encrypted archives by mail then sending the password in another mail, or sending the password and a link to the content hosted elsewhere in the same email.
Good idea but too complicated for the average Joe.
It could be made much easier by building all the necessary steps right into the email client. Just select "Encrypt attachments".
Most of the attempts to address the issue have missed the boat by trying to encrypt the entire email in some non-standardized way.
I would not expect this to be true. TLS adoption is not universal (and it would be nice to make it so), but I don’t believe it’s that far off it. This hop-by-hop encryption protects the traffic from all but your own email service provider.
Yes, I am misconstruing the article’s intent, which seems to be talking about end-to-end encrypted message content, so that your email service provider can’t see it either, but what it actually says here is just flatly wrong. The messages are sent encrypted (conditions apply), and promptly decrypted by the receiving mail server, so that it can do useful stuff with it rather than just treating it as an opaque blob.
The article completely fails to note the harsh compromises that must be made if you want to further encrypt messages with PGP or S/MIME or whatever. For most people, the most obvious one is that any form of webmail is crippled and you lose all server-side search, meaning that you need to fetch all the mail locally and index it locally. This is normally infeasible for phones.
Fastmail explains the compromises well in this article on why they don’t offer PGP: https://fastmail.blog/advanced/why-we-dont-offer-pgp/. It boils down to (a) it crippling the service, and (b) not actually being useful anyway, because first-party encryption is pretty much unavoidably broken.
Most of what ProtonMail sells as privacy in their encrypted messages stuff is snake oil, plain and simple. As long as they provide the software that holds the keys, they can obtain those keys (this is a style of attack Fastmail refers to in that article—though Fastmail assumes you’d send the key with each request, rather than the email service provider being just a blob store and decryption happening on the client, but changing the code makes exfiltrating that trivial). This is a systemic failing of first-party encryption in the presence of automatic software updates (which is the default on almost all platforms, and fundamental to the web). The only path to real success requires that the platform and the encryption provider be distinct. To ProtonMail’s credit, they have done at least some pushing in the direction of what’s essentially reproducible builds for the web, so that clients can actually reliably detect when something’s changed (subresource integrity is a starting point, but insufficient as it doesn’t protect the top-level resource). I don’t think anything has actually come of it (it’s a fairly tiny niche that there’s not much interest in), but they are trying.
(Disclosure: I worked on Fastmail’s webmail in 2017–2020. I do not believe this has significantly influenced my position on these matters, save that my opinions are better informed than they were before; but I already saw and understood the problems of first-party end-to-end encryption. I find Fastmail’s position in this matter to be eminently reasonable and well-expressed.)
Putting real legal barrier in place where at least some parties like employers could be swatted would already be improvement.
Ditch email and move on to encrypted comms that are end to end.
It’s far too easy to reply to the message without encryption or something of the sort.
Email was never designed to be encrypted.
Right now my bank, pension fund, utility supplier etc regularly e-mail me to inform me that a new statement is available. But they don't attach the statement to the e-mail... because "it isn't secure"
So there is real-world demand for a properly secured e-mail system. If we could jump in a time machine, go back 50 years and add end-to-end encryption to e-mail, I'd be getting my bank statements by e-mail.
(The chance of my bank deciding to deploy PGP is approximately one in a billion - which is why we'd need a time machine)
There is real-world demand for a properly secured messaging system (either real-time or asynchronous) that is as ubiquitous, as accessible, and as technologically neutral/decentralized as email.
I think you hit the nail on the head that if we could go back in time and email was encrypted from the start, it would be great, and there is a demand for that. But people keep trying to do that time travel by adding encryption after the fact, and like you I just don't think PGP works for that, I think it's throwing duck tape on top of a technology that is just not designed to handle it.
I'm not saying we should drop all email and move to something like Matrix, I still use email today for a lot of stuff. And I'm definitely not saying everyone should use Signal as a full email replacement (the phone number requirement and centralization problems make it unsuitable). But in the long, long term it would very likely be easier to drop email and move everyone everywhere to Matrix (or something else, it doesn't have to be an instant messenger), than it would be to try and retroactively make email encryption work well.
But look at it from the banks perspective. If they email you and ask for you to log in the bank can see who you are, and capture any info in case of fraud.
If they sent it as a secure message, they cannot capture any info on who saw it... They just know it was sent.
The new bit is the idea that someone will leak an email with an unencrypted CC: or forward. That's an easy to resolve user factors issue. If we were actually encrypting our emails then attempts to send unencrypted emails could easily be highlighted and discouraged.
Long form asynchronous messaging is important and useful, particularly in business. You can't just wave it away. By nature it can be made much more secure than something like an instant messenger[2]. The Cellebrite attack against Signal is a good example of that. Cellebrite gets all the archived messages in the case of Signal and none of the PGP messages.
Do you have glasses? - Could've gotten you killed under a different regime in a different time.
Do you own foreign books? - Could've gotten you killed under a different regime in a different time.
Do you have a mental disorder? - Could've gotten you killed under a different regime in a different time.
Is your religion not the majority in your country? - ...
Now consider the fact that regimes change. How uninteresting are your emails?
There are just too many ways things can go wrong, and of course they will go wrong at some point.
If you need confidentiality you need, at the minimum, disappearing messages, and for that to be the case all the way, you can't rely on decentralisation systems with various implementations.
Sorry for interoperable decentralised lovers, that includes myself, but you need control over the whole chain. And email is just the opposite of this.
Really, where then?
Suppose today it's opposite: Eye Sight will detoriate when not wearing proscription glasses, which gives actual minus points on sight and maybe three pedestrian red lights worth in negative social credit.
Wait, what? Adversaries do read emails of ordinary/average people. From Google[0] to the NSA[1]. Are we just pretending this doesn't happen?
[0] https://web.archive.org/web/20190331015638/https://www.wsj.c...
[1] https://www.theverge.com/2017/4/28/15474828/nsa-surveillance...
signal is not decentralized and requires phone numbers tied to your real identity. no thanks.
EDIT grammar
(1) SMIME/x509, and national security variants are incredibly popular for intra-organizational secure email (2) Secure Webmails have came on the scene in a big way.
Where SMIME/x509 fails, web-of-trust based solutions succeeds, and vice versa.
Working across both areas means we need solutions to bridge between the two worlds, and to buttress each other respective weaknesses in the trust model.
BUT:
> Ordinary people don’t exchange email messages that any powerful adversary would bother to read,
This just one hundred percent incorrect and it completely misstates the problem.
The problem is not that Alice and Bob are the focus of intensely focused surveillance, in the sense that they are up against a powerful adversary themselves.
The problem is that Alice and Bob live in a society where those who can and want to make such decisions, are implementing drag-net surveillance at every possible corner of society that they can get away with.
There is a powerful adversary and it would very much like to to read any and all of our communication.
In almost all cases this is consequence-free for Alice and Bob - but this is not Freedom.
My communication is mine it's not there for google so scan for ways to sell me useless shit, and it's not there for Big Brother for training their precog-ML models on it.
The threat model is not "The CIA wants to rubberhose me into revealing information" it's "The NSA routinely opens all of my letters, just to make sure I am not a terrorist/commie/vagrant/etc".
There is a lot of email based verification/authentication happening which would benefit if the email encryption was more widely accepted.
Mostly because the big boys want control.
I'd rather say the issue is that the big boys' business is NOT mails, so their goal is to provide the minimum viable mail service, and not spend one dollar more on it.
While once upon a time, when companies were actually providing email service, they had to innovate to keep on top.
If they did it right, it might even be a good thing. But there's not really much desire/push for it, because spam got "mostly solved" well enough.
You'd want it to be a feature-add (if enabled and used, your bank can send you secure statements direct to your email box that nobody else can read, etc) so you actually gain something; but then you have the whole "Google and Microsoft have MITM themselves on almost all email" problem anyway.
Consider Matrix instead.
* Requires phone number
* How do I run my own server?
* Doesn't have good spam protection
* Individual messages can't be categorised into folders and/or archived, then searched by category
Why do you think that their free tier is not great? AFAIK, it works like any other free tier email service but with encryption. Though it does have a limited storage space (which has increased recently). Anyone who would need more than that & has chosen to use PM probably also understands the cost of free products available & will be willing to get paid service
Disclaimer - I am a paid PM user (converted from free tier after using it for few years)
https://www.go350.com/posts/age-file-encryption/#additional-...
This is the nub of it. People don't know what they want from technology. Or rather, they are conflicted. Our collective illusion that rational technical concerns drive technology hides the reality that all digital technology is a set of power relations that help or hinder different spheres of interest - often within the same group or individuals. Many people want to do bad things and we have even created laws that insist people do bad things (as piss poor solutionism to the original bad things). Hole, spade, keep digging.
The problem of email can be seen two ways:
1. Bad protocols.
2. Bad actors.
Naturally, as techies we attack (1). Just encrypt it all. Zero trust. Train everybody to use encryption. Enforce it. Let's call that the "Rule of Tech".
By contrast, let's call (2) the "Rule of Law". There are already more than enough laws that deal with the fundamental immorality of reading someone else's private correspondence. However we have carved out so many exceptions, including those in the interests of our own profits, that we now just assume (2) is an intractable feature of the world. It isn't.
Email has shown us time and time again that the solutionism of getting people to use encryption is nigh-on impossible. Even the US government have pretty much said PGP is a dead approach.
So let's ask the question nobody wants to hear; Would it be economically wiser to enter into more layers of solutions, securing email at the technical and policy level (1), or to take a GDPR-like approach of bolstering the rule of law?
Let's be clear - this would mean taking NSA, GCHQ, Google, Microsoft etc to court, fining and if necessary dismantling the assets of those who interfere with private communication. It would mean stripping ISPs of listening taps, and auditing server rooms. It would mean something approcimating to a civic cyber police force acting IN THE INTERESTS of the public, rather than against us.
I realise how naive that sounds in this cynical epoch. But I think the ultimate cost of 'zero-trust' society may greatly outweigh the political cost of using the Rule of Law to re-establish 'trusted' networks.
Can't we give the law a chance?
No because law makers have at every turn attempted to undermine encryption. What makes you think they'll suddenly fine and/or dismantle the assets of the NSA/GCHQ? These are the agencies that have been central to both countries' security in times of war. Times of war that seemingly has never ended.
I would be very interested in a reference to that...
In this case the reason why I think it's worth focusing on the protocol is that, when an E2E encrypted protocol is designed properly, it removes an entire attack surface and significantly decreases the amount of possible human error. I think encrypted L7 overlay networks are a good solution to step aside these problems at the cost of a bit of overhead (wrapping packets, etc)
Server-side (spam-)filtering would be another victim. (Okay, so in my case my personal filters mostly operate only on the From:/To:/... headers and so wouldn't be affected, but the effectiveness of spam filtering would definitively be reduced somewhat if the spam filter didn't have access to the message text as well.)
Really it should have been integrated into DNS with a MXKS record that points at the keyserver for a domain or something similar. There could even be a default for domains without the MXKS record that you can fall back to (use MX server on a well known port). The keyservers could be verified the same way we verify HTTPS, which is the part where we drop web of trust into the dumpster and switch to a system that has already proven to be scalable and safe enough for regular users. All of this could be seamlessly integrated into mail clients. If you are worried that your keyserver will leak your email addresses you can have it return bogus key material for addresses that don't exist.
It's far too easy to copy-paste text from a web page into an unencrypted file or something of the sort (like an email).
The web was never designed to be encrypted.
Mail traffic is different: So that the sender and the receiver don't have to be online a the same time, we also need another intermediate party, i.e. the mail server. (In practice both sender and receiver utilise a mail server as an intermediate party, but here I'm mainly interested with "my" mail server on the receiving side.)
If the mail server's role was purely restricted to being a dumb store-and-forward store to hold any mails that arrive when I'm not online then, that'd be the end of the story, but in practice the mail server also fulfils a few additional functions that only work if the server actually has access to the message contents:
- Easy access from various sorts of mail clients ranging from full computers to phones to (especially for regular users these days) webmail, without having to worry about anything complicated like key management or whatnot - Server-side spam filtering - Server-side search, especially for mobile clients and webmail
And this has about the same number of possible failure points than PGP encrypted emails.
Trick a user into installing a root cert? Game over.
Find an exploit in one of the default, super trusted CAs and get them to issue you a certificate for a domain / with flags you have no business having in (like this has never happened before, I couldn’t quickly find this, but I clearly remeber the day when some major CA issued certificates and let you issue further certificates down the chain, for which the intended use was to allow you to do subdomains on your own, but they worked for any domain at all)? Game over
Nation state? Game over (except Kazakhstan, they chose the path of most resistance with a method that’s trivially defeatee)
Not to mention DPI, which can’t reveal contents, but can reveal what kind of content it is, and from that possibly identify exactly what it is.
HTTPS prevents only the most dumbed-down MITM attacks. Anyone with enough resources and determination will be able to find out exactly what you’re doing on the web without too much trouble.
"... people who were stereotypically thought of as having intellectual qualities, such as wearing glasses or speaking multiple languages, were executed out of fear that they would rebel against the Khmer Rouge."
Signal in second place due to the phone number tracking and non decentralized status stated above.
The only service I am aware of that it does break is Google Docs, because they handle things in an odd manner. But as they received several bug reports for that since 2017, I wouldn't get your hopes up that it'll ever be fixed.
The fax only ones are the dumbest though because on both sides everyone is just using electronic documents.
Plenty of money was spent criminalising crypto by the big boys.
Even disregarding that fact, your equation makes no sense because AOL or whatever big BS you have in mind has null interest providing a product they have to spend money on with zero realistic ROI.
Since arpa net arose eventually from the same party poopers, nothing of this should come as a real surprise.
If email was encrypted at rest, gmail would disappear overnight. Gmail's whole purpose is end user data gathering, for profit.
Many other mail providers are the same.
An encrypted Zip attachment works with any email client software.
It's back on the front page of HN
https://news.ycombinator.com/item?id=30530592
It's the Whitehouse.
"people you don't know" would would work for whitelisting (i.e. people I don't know wouldn't get whitelisted), but as I need and want to receive the occasional email from random strangers, it's not all that useful a criterion for marking something as certainly spam.
Which is why you would only mark it as probably spam.
Did it though? Gmail is still having a tough time blocking all spam.
Absolutely. I didn't mean to seem uncharitable to the average sysop. We've all been there. In fact this state of affairs means that clear legal frameworks, simple messaging that everyone understands, could be powerful. Bad actors mainly exist at a higher level. Over-stretched people in moral grey areas benefit from clear reasons to act decisively, which is why we make sure soldiers get unambiguous orders.
If all sysadmins and developers knew they could go to jail for reading or enabling another to read private communications sent with a reasonable expectation of confidentiality, we'd be in a very different place.
Unfortunately we've let this slip, and entered a cultural interregnum in which we kinda expect emails to be read by others, and even assume they will be. That's not okay. Because even if we fix-up the protocol level there's a residual expectation that it's alright to work around it "because we need to read peoples' emails", right?
> I think encrypted L7 overlay networks are a good solution to step > aside these problems at the cost of a bit of overhead (wrapping > packets, etc)
Yes, I absolutely agree with you. If email can be fixed it has to happen at a whole new "Tor for email" level. Hell, maybe we could all start running our servers as open relays again, given that we'll not know exactly what we are routing.
But I think the law has a part to play. If only to kick-start the initiative to secure email, because right now the surveillance capitalists and spooks are entrenched in a criminal mind-set. Caveat Dolev-Yeo notwithstanding, one can't build trustworthy systems on that culture however good the tech.
Hehe I've met some pretty self-important sysops so let's not be too charitable here ;) (just a joke!)
> Unfortunately we've let this slip, and entered a cultural interregnum in which we kinda expect emails to be read by others, and even assume they will be. That's not okay. Because even if we fix-up the protocol level there's a residual expectation that it's alright to work around it "because we need to read peoples' emails", right?
Is this specifically an email thing? There's a weird culture I've encountered in older organizations that place a lot of emphasis on networks owned by an organization. The organizations themselves seem to have almost a fetish for controlling data that goes across their networks and likewise their net/sysops partake in this culture of absolute control. Maybe it's the same people who are incensed today that social media can act like a safe harbor. Maybe it comes from a time where the cost of sending/receiving a packet was legitimately quite expensive. I'm not sure. I'm glad that most modern attitudes on network management have given up the idea that owning a network means total control of every packet that enters and exits it.
> Yes, I absolutely agree with you. If email can be fixed it has to happen at a whole new "Tor for email" level. Hell, maybe we could all start running our servers as open relays again, given that we'll not know exactly what we are routing.
There are a whole bunch of projects in this space. Everything from overlay networks (Yggdrassil, Zerotier, Tailscale) to mixnets (like Nym) to remailers (like Bitmessage.) We just need to spread the word.
> If all sysadmins and developers knew they could go to jail for reading or enabling another to read private communications sent with a reasonable expectation of confidentiality, we'd be in a very different place.
> But I think the law has a part to play. If only to kick-start the initiative to secure email, because right now the surveillance capitalists and spooks are entrenched in a criminal mind-set. Caveat Dolev-Yeo notwithstanding, one can't build trustworthy systems on that culture however good the tech.
I'm a big fan of this idea FWIW. I just think, realistically, adoption will be slow as small ISPs and organizations throw temper tantrums about how they're being steamrolled by Big Tech and use than as an excuse to both read/intercept traffic and to offer subpar QoS to their customers. There's only so much to be gained by suing a tiny ISP in Florida that is sending mail in the clear because they downsized their netops staff years ago and now they still serve 5 elderly customers who don't want to switch through the occasional contractor.
It has a desirable side-effect of getting me into IPv6 with a positive attitude after successfully putting it off for 20 years. Cheers.
Off the top of my head:
- PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.
- PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
- PGP doesn’t encrypt metadata.
- PGP doesn’t give forward secrecy.
I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
Transport layer security (and enforcing that) is definitely good for email, and we’ve moved the state of the art beyond where it was in the ‘70s, but I think the quest for true e2ee in SMTP-based email is probably not worth the effort.
Email should be thought of as having certain tradeoffs (like messages living unencrypted on servers, and relying fully on server to server trust), and for things that need e2ee, you should use something like Signal instead.
Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret key material will be compromised. With an asynchronous, offline capable medium like encrypted email the secret key material can be protected very very well. A message archive accessible to the user for all practical purposes negates the value of forward secrecy. Most people like to keep their old emails around. Most people like to keep any form of messages around so that forward secrecy has little practical value in most forms of E2EE messaging.
There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
More discussion: https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
In the case up above in this thread branch of the poster's bank not emailing statements because it is not secure, key discovery would be easy. The bank would have a form available only when logged in to their online banking site to enable statements by email with a way to upload your public key.
My guess is that for most people who could benefit from emailing encrypted documents it is similar. They have a good secure channel to give the other party their public key.
I'd rather that something better than PGP be used though.
That is what WKD is for and is already implemented by multiple providers.
> PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
> PGP doesn’t encrypt metadata.
What metadata are you concerned about here? Subject lines? GPG is quite versatile so I'm not sure what metadata you are worried about.
> PGP doesn’t give forward secrecy.
Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
> I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them.
If it was just PGP that was the problem, we'd use something else to encrypt our emails and it would be fine. But the problem is that any system that works like PGP where we're primarily encrypting message contents, where we're not thinking about stuff like forward secrecy -- that's not good for email. Email itself isn't good for that because email doesn't really lend itself to E2EE, regardless of what you use to do the encrypting and key validation.
So you could have a version of PGP that was amazing and brilliant, and it still wouldn't really be a good fit for encrypting email, because email is not a good fit for encrypting email. The entire structure of how email works makes it difficult to do encryption in a user-friendly, accessible way.
I am also pretty skeptical of PGP (see some of the other comments), but that's not specifically why I mentioned it in my original comment. I only brought it up because most email encryption schemes I see are using PGP, and I don't think that PGP miraculously solves the problem. It's not good enough to paper over the fundamental flaws in email itself.
As a nerd, it does seem to me like I should be able to give the bank a public key and let me worry about my own security. But I don’t think this is actually what the bank or the user wants—they don’t want encryption per se, they want authentication, and an HTTPS link in an email (that you have to login to view) achieves that.
Surely it’s on me, if I wanted the content to be secret?
> What metadata are you concerned about here? Subject lines?
I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
> Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
> I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them
I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
No matter what encryption you use, if your recipient gets compromised there is nothing you can do except don't sign the message with a published public key and send the message anonymously. Then, at least, it would be more difficult to trace back to you unless you include personally identifiable information in the encrypted message.
> I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
First, when it comes to traffic patterns I have no clue what that means. You can hide the recipient with GPG, so they have some plausible deniability as long as someone else doesn't have their secret key and passphrase.
You can encrypt the subject line pending email client support to decrypt, but really it seems pointless. Might as well just say `hello` or `secure` in the subject line. I imagine you could also create an RFC to add an encrypted subject to the header if one doesn't exist already.
> As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
It doesn't have to be a lot of hassle. If I remember correctly, Keybase may have had something similar for messaging. It just hasn't been done because instead of using GPG, a lot of people want to implement something else, which is fine as long as it is secure. GPG is secure though which is why people throughout the intelligence community use it frequently and journalists that want security.
Maybe for PFS something like age makes more sense, but GPG has been around and is more tried and tested.
> think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
GPG is usable and usably secure, if you know even some of the basics of what you're doing. Really, just looking through the docs on GPG's website provides a vast resource of information. It can be overwhelming for grandma, and yes sometimes the docs are confusing in certain areas, but it is not challenging for people in tech that have a little patience (doesn't require a lot).
There certainly isn't anything stopping GPG from being the default except competing solutions. It has been pretty much the default for email security for some time.
My claim was never that, though. My claim is that in the “normal” usage of PGP, it’s substantially less secure than modern alternatives, and that this is a mostly inherent byproduct of the use cases for which PGP appears to be constructed.
Succinctly: it’s hard to use PGP securely.
Can you do it? Probably. Could PGP be the default if everyone gave up on the easier to use, more secure alternatives? Well, on this point I am skeptical: before Signal, Wire, Threema, WhatsApp, etc—some of us remember those days!—the “default” was plaintext email. Not PGP.
PGP had 30 years to become the norm. During the first twenty or so, it had no real competitors other than S/MIME. And, here we are.
There are a lot of areas—fountain pens, for example, or vintage sports cars—where old technology has its own appeal, but encrypted communications isn’t one of them.
The word "hoary" means "grey-haired". "Stop Using Encrypted Email" was published in 2020; even in dog years, it's not "hoary".
I’ve spent a decade working in the industry, most of it unwinding complex infrastructure and codebases. I don’t hate GPG because I can’t be bothered to figure it out. I understand it and it’s bad at handling the problems it claims to solve.
> There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it.
Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm?
The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?
I did a demonstration using GnuPG to provide a practical example:
"It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
I have some issues:
First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated.
Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device.
Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients.
Just to make this point more clearly:
> it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption.
----
> Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.
No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
>...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous.
I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that.
You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that.
> They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to.
They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever.
----
There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.
“You can use ed25519” kindof flies in the face of the point being made in the post, which is that sure, you can use modern crypto, but you’re bounded by the lowest common denominator, and GPG’s lowest common denominator is horrible broken crypto selections.
Zooming out a bit, we could ask the same question that you've posed about email more broadly: why do most email users not bother with PGP encryption at all? Why do many client developers decide to not even add support to their apps?
If you take the perspective that lack of mainstream adoption of a security technique is evidence that the security technique has no value, then it's hard not to conclude that SMS and Facebook Messenger are both fine and we're all wasting our time with encrypted messaging of any kind. But my perspective is that people use more secure tools (in part) only once they're at least as accessible and usable as the other tools/platforms that they already have.
----
From your linked article:
> This process is very manual. There are no GnuPG --preburn and --burn commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system.
PGP does not have a generally accessible, vetted way to automatically create those subkeys and distribute them that any non-technical (or even reasonably technical) user can take advantage of: if it did then the blogpost wouldn't exist. So of course people don't do that stuff, it's not surprising that people don't manually edit keys. The problem is when developers and proponents then respond to that by saying, "we don't need a generally accessible, vetted way to automatically create and distribute subkeys because people don't do that." Then the whole conversation starts getting really circular.
People use forward secrecy in Signal because it's on by default and works even if they don't know what forward secrecy is. Of course sometimes we can look at an ecosystem and we can take cues about user needs based on what they currently use. However, you have to be very careful about that. Don't fall into the same trap that (just as one example) Mozilla falls into, where they'll move an option into a buried preference menu and then say, "no one is clicking this anymore, guess we should remove it from the browser entirely." Sometimes users don't use features purely because they're not convenient, or accessible, or because they don't know the features exist.
It's also worth noting that broadly, most E2EE messaging platforms are moving towards forward secrecy, and PGP encrypted email is somewhat of an outcast in saying that forward secrecy doesn't matter. So it's not really like forward secrecy is easy everywhere and people go and turn it off because they don't need it. Increasingly, it's just older systems like PGP where people have decided not to approach messaging this way. I would posit the reason for that split is because PGP has bad UX for forward secrecy and most people using it or building around it know that doing unconventional things in PGP is a recipe for accidentally shooting yourself in the foot.
It’s not clear why it’s desirable to keep bolting things onto email in an attempt to somehow make it eventually match the security profile that we can already get by just using other existing options.
So, why not just use Signal or WhatsApp?
‘Cause they’re not PGP.