[HN Gopher] Privacy in email communication: we should use encryp...
___________________________________________________________________
Privacy in email communication: we should use encryption by default
Author : nicfab
Score : 159 points
Date : 2022-03-01 10:50 UTC (12 hours ago)
(HTM) web link (notes.nicfab.it)
(TXT) w3m dump (notes.nicfab.it)
| imwillofficial wrote:
| Email encryption is dead. And a stupid bolt on, poorly
| implemented fix that email wasn't designed to handle.
|
| Ditch email and move on to encrypted comms that are end to end.
| pSYoniK wrote:
| I wrote about email privacy in general a few days ago and after
| talking to a few friends who have read the article they asked
| about actual email privacy - what happens to the content (my
| article was mostly focused around obscuring your real address and
| I don't talk about securing the contents of the emails).
|
| 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.
| samwillis wrote:
| My accountant is now using the stupid "encrypted email" system
| Outlook has where it sends you a link to their server, which then
| emails you a password to login to read the email. It's so bloody
| clunky and annoying.
|
| 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.
| implements wrote:
| > I suppose it ensures that if the recipient isn't using TLS
| with SMTP then it's not sent unencrypted over the wire, ...
|
| 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).
| Karrot_Kream wrote:
| I went through this process just the other day, setting up
| Postfix on a Zerotier network. Postfix lets you specify a
| "mynetworks" config option that lets you allow certain IP
| ranges. I added the Zerotier IPv6 assigned ranges to this
| list, disabled any form of TLS on the smtpd end, and was able
| to effectively turn off TLS. It was more annoying than I
| thought it would be but it makes sense given how few real
| world deployments lack TLS these days.
| pabs3 wrote:
| Just use the browser dev tools to re-enable text selection?
| There must be a browser extension that can automate that too.
| Maybe even Greasemonkey would do.
| shakna wrote:
| In Firefox, you can simply set a preference and scripts won't
| be able to disable copy/paste.
|
| Go to about:config, and search for
| dom.event.clipboardevents.enabled and disable it.
| dbrgn wrote:
| This will probably break many other use cases as well (e.g.
| services that allow pasting formatted text and will convert
| it to unformatted text, or pages like GitHub where you can
| paste an image into the edit area).
| shakna wrote:
| It shouldn't break either of those usecases (I gave
| GitHub a go and it certainly seems to work). Those
| functions tend to be handled by a different preference
| (dom.allow_cut_copy).
|
| 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.
| samwillis wrote:
| That's exactly what I do, however I wouldn't want to try and
| explain how to do it to my Parents. They are meticulous with
| their filing system and this would make it impossible. They
| would ultimately probably print more stuff out to save.
| notriddle wrote:
| 1. Does Microsoft not disable printing, also?
|
| 2. If not, do your parents know how to print to PDF?
| jabroni_salad wrote:
| Unfortunately, Rights Management is the hot thing of the
| minute. It doesn't make since for you since you are the
| ultimate destination, but in many cases we need to transmit
| information and also take steps to ensure that the recipient
| does not forward that data anywhere else without our
| permission. If we are going to still be responsible for the
| data's privacy after it leaves our network then we are just
| going to never let it leave our network.
|
| 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.
| awinter-py wrote:
| yes or like how my kernel driver reverses the polarity of
| your webcam to emit an _infrared laser_ which makes it nigh
| impossible to photograph the screen,
|
| which our internal research shows is the typical way of
| exfiltrating information when right click is disabled by
| javascript
|
| wear eye protection
| samwillis wrote:
| So, I understand the motivation, it's the misguided
| implementation that's the problem. The only thing from your
| suggested requirements that actually works is the ability to
| "retract" an email before its been read.
|
| 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!)
| kasey_junk wrote:
| It would be extremely expensive to mechanize the dragnet
| stealing/modification of the post. I agree the current
| solutions for electronic communication are stupid but there
| is concern about the many vectors and attacker could get
| all the data.
|
| The fax only ones are the dumbest though because on both
| sides everyone is just using electronic documents.
| Brian_K_White wrote:
| To me that is all just unreasonable expectations in the first
| place. None of the reasons people want that kind of control
| and knowledge are valid excuses for the overreach. It's just
| something they want just like the countless things anyone
| wants.
|
| 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.
| FastMonkey wrote:
| I got a proposal last year from a vendor where I wasn't
| allowed to copy or download the text. They were one of a
| handful of proposals I got, so since I wasn't able to share
| they're stuff with other decision makers they put themselves
| out of the running. We do take steps ourselves ourselves for
| communicating sensitive data, but my point is that there can
| be costs to overusing systems like this.
| mkdirp wrote:
| > Therefore, in 2022 a daily email traffic of 333.2 billion
| emails is expected
|
| 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 $/PS/EUR 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.
| nonrandomstring wrote:
| > Your sysadmin, especially of the bigger orgs, do not want
| encryption on your emails.
|
| 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?
| Karrot_Kream wrote:
| You're starting down a very interesting/sanguine line of
| questioning, but you're leaving out another complication of
| "bad actors". The number of sysadmins and netops out there is
| very large. While some certainly are malicious or are
| motivated by privacy-violating desires (whether
| organizational or personal), many of them are just
| overworked, underpaid, or underqualified. When it comes to
| email, a single unencrypted link is all it takes to break the
| trusted chain of Email. Given the sheer multiplicity of the
| problem, IMO a GDPR-like approach would meet too much
| pushback from organizations who already don't want to hire a
| sysadmin.
|
| 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)
| nonrandomstring wrote:
| > many of them are just overworked, underpaid, or
| underqualified.
|
| 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.
| Karrot_Kream wrote:
| > Absolutely. I didn't mean to seem uncharitable to the
| average sysop. We've all been there.
|
| 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.
| upofadown wrote:
| >Even the US government have pretty much said PGP is a dead
| approach.
|
| I would be very interested in a reference to that...
| nonrandomstring wrote:
| So would I , but I can't find it so you'll have to do your
| own digging. It was posted here on HN about 3 weeks ago. It
| was a report by a major TLA announcing a significant
| revision of cybersecurity "best practices", one of which
| was to stop pushing email encryption as it's deemed more
| trouble than it's worth.
| mkdirp wrote:
| > 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.
| nonrandomstring wrote:
| I think one should not confuse support for the Rule of Law
| with exasperation at the parochial "lawmakers" who are
| poorly educated, motivated by power and money, and thus
| essentially traitors to the principle. That would be
| cynicism.
| jigarjain wrote:
| > their free tier is really not that great.
|
| 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)
| _wldu wrote:
| Organizations may use ADK (additional decryption key) when they
| want to access what users are emailing to each other (for
| compliance/security reasons). It can be done with vendor
| provided software or manually. Here is a short description of
| how it works:
|
| https://www.go350.com/posts/age-file-encryption/#additional-...
| charcircuit wrote:
| The only people who send me messages on email are recruiters.
| I'd honestly prefer if they'd just discord me so we could have
| synchronous communication instead of having to wait 24+ hours
| for a response.
| hkt wrote:
| Delta is also viable. I use it for IM and it is TOFU based PGP
| encryption. It works OK for general email too, though that's
| not the focus.
|
| See: https://delta.chat/en/
| flerchin wrote:
| It would be a start, and a decent one, for TLS to be required for
| all my email transmission. It seems like the providers can do the
| same thing that Chrome did, and put scary security warnings for
| emails that can't meet encrypted in transmission.
|
| Encryption at rest is another problem, one that I'm not even sure
| most users want.
| Ekaros wrote:
| TLS would be good start. It is insane that not using it would
| be allowed anymore.
|
| 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.
| upofadown wrote:
| Agreed that TLS between servers should be promoted and enforced
| more. In practice, something like 90%+ of email is so encrypted
| now[1]. Things could be better, but they are not bad.
|
| 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.
|
| [1] https://articles.59.ca/doku.php?id=pgpfan:starttls
|
| [2] https://articles.59.ca/doku.php?id=pgpfan:encryptonce
| hammyhavoc wrote:
| Is this not going to make stopping spam somewhat of a nightmare?
| prophesi wrote:
| Just an FYI for HN, you can add your PGP fingerprint to your
| profile (along with the keyserver(s) they're on) so that at least
| HN users who want to communicate with you can use E2E encryption.
|
| 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.
| fguerraz wrote:
| For me, everything has been said here already:
| https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
|
| > 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.
| yosamino wrote:
| There is a very good point about the difficult-to-impossibility
| of securing email.
|
| 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".
| thepangolino wrote:
| michaelt wrote:
| _> It doesn't matter whether or not these emails are safe,
| which is why they're encrypted so shoddily._
|
| 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)
| moviuro wrote:
| Does your bank at least use STARTTLS? I know banks that
| don't.
|
| https://try.popho.be/email.html#tests
| danShumway wrote:
| > So there is real-world demand for a properly secured e-mail
| system.
|
| 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.
| andi999 wrote:
| What seems to be the problem with pgp (apart from nobody
| using it)
| danShumway wrote:
| Not going to rehash what other people are writing about
| PGP, that could be a much longer conversation. But it's
| not just PGP that's the problem, PGP just happens to be
| what people are using to encrypt email.
|
| 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.
| michaelt wrote:
| https://latacora.micro.blog/2019/07/16/the-pgp-
| problem.html
| upofadown wrote:
| I have a canned response to this hoary old chestnut:
|
| * https://articles.59.ca/doku.php?id=pgpfan:tpp
| encryptluks2 wrote:
| I think most people complaining about GPG just don't want
| to be bothered with figuring anything out. They'd rather
| input their phone number into some cloud app that says it
| is secure and feel more secure than actually be bothered
| with understanding security in the first place.
| tptacek wrote:
| You also have a lot of weird cryptographic beliefs, like
| "authenticated encryption is a misfeature for tools like
| PGP, because unauthenticated ciphertext helps with data
| recovery", or "GPGME definitely doesn't just execute the
| GPG binary in order to perform PGP operations", or
| "forward secrecy is overrated because people keep all
| their old messages around" (also: "people should keep all
| their old messages around"). People that also believe
| these weird things will find your canned reply
| convincing. Cryptography engineers generally will not.
|
| The word "hoary" means "grey-haired". "Stop Using
| Encrypted Email" was published in 2020; even in dog
| years, it's not "hoary".
| md_ wrote:
| I think that's the biggest problem, but there are others.
|
| 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.
| encryptluks2 wrote:
| > 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.
|
| 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.
| md_ wrote:
| > 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.
|
| 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!
| upofadown wrote:
| >- PGP doesn't give forward secrecy.
|
| 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
| md_ wrote:
| The other person replying already pointed out why this is
| an apples-to-oranges sort of argument, but for one
| specific point:
|
| > 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?
| upofadown wrote:
| Forward secrecy is just forgetting the secret key
| material. The trick is the do it in a convenient way. In
| the case of something offline capable like OpenPGP over
| email, the inconvenience is in having to redistribute
| your keys before forgetting the secret key. You don't
| even have to reestablish any trust, that just works.
|
| I did a demonstration using GnuPG to provide a practical
| example:
|
| * https://articles.59.ca/doku.php?id=pgpfan:gpgburn
| md_ wrote:
| OMFG. This is the sort of thing that makes people not
| want to use PGP.
|
| "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..." ;)
| upofadown wrote:
| Of course no one is actually going to do that. The point
| is that it is trivially possible. The question is: why do
| PGP users/developers not bother?
| danShumway wrote:
| I suspect the answer you're looking for is that it's not
| necessary, but the much more likely reason is that the UX
| is horrible and it's error-prone, and even out of the few
| people who use PGP for this kind of stuff, a fairly
| sizable chunk of users probably don't even know what
| forward secrecy is. I would say the expectation that PGP
| users need to be informed enough about encryption to make
| a personal decision for themselves when to change their
| keys is itself a somewhat damning indictment of the PGP
| ecosystem. You shouldn't have to be an expert in this
| stuff to have good encryption.
|
| 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.
| danShumway wrote:
| > This sort of attack could not reveal any messages
| archived off the network due to Signal's forward secrecy.
| Let's compare the end result to an encrypted email client
| running on the same phone using traditional passphrase
| protection [...] So the encrypted email actually ends up
| providing a better result for the user. That is because
| 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.
|
| 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.
| upofadown wrote:
| >First off, you have no guarantee that anyone's client is
| storing PGP-encrypted mail only in its encrypted form,...
|
| 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.
| danShumway wrote:
| > 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.
|
| 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.
| tzs wrote:
| > PGP key discovery is hard to do securely. Do you just
| trust what's on the public keyserver? Do you use RFC
| 7929?
|
| 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.
| md_ wrote:
| Yeah, I think that's fair.
|
| 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.
| intothemild wrote:
| Yes... I agree that can work....
|
| 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.
| ekianjo wrote:
| > If you want security, use other messaging systems, like
| signal,
|
| signal is not decentralized and requires phone numbers tied to
| your real identity. no thanks.
| Demcox wrote:
| Try Session [0]. Decentralized, no phone numbers and adding
| contacts is done by either sharing your ID or an QR-code. It
| works well but, at this time, only texting. Does have pretty
| apps for iOS/Android and most desktops OS's
|
| [0]https://getsession.org/
|
| EDIT grammar
| chaxor wrote:
| Session is _fantastic_ - definitely the best messaging
| system I have seen so far.
|
| Signal in second place due to the phone number tracking and
| non decentralized status stated above.
| Rayhem wrote:
| Has session had a proper security audit anywhere?
| xfer wrote:
| I can also screenshot my device showing signal/whatsapp, that
| doesn't make them insecure.
|
| There is a lot of email based verification/authentication
| happening which would benefit if the email encryption was more
| widely accepted.
| bbarnett wrote:
| There are plenty of ways of doing email right, but we've lost
| what we had in the early days, the ability to form concensus,
| and enact change, via RFCs.
|
| Mostly because the big boys want control.
| phh wrote:
| > 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.
| bbarnett wrote:
| Mail providers never wrote rfcs. Nor are they expensive,
| just concensus requiring.
|
| 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.
| posterboy wrote:
| > 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.
|
| 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.
| OrvalWintermute wrote:
| The problem with that link is pretty clear:
|
| (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.
| harryvederci wrote:
| > Ordinary people don't exchange email messages that any
| powerful adversary would bother to read
|
| 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?
| posterboy wrote:
| > Do you have glasses? - Could've gotten you killed under a
| different regime in a different time.
|
| 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.
| rsync wrote:
| During the Cambodia genocide[1]:
|
| "... 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."
|
| [1] https://en.wikipedia.org/wiki/Cambodian_genocide
| fguerraz wrote:
| And that is exactly the point made in that article. If what
| you put in that email can get you killed, then don't put it
| in an email, even encrypted.
|
| 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.
| upofadown wrote:
| "Stop Using Encrypted Email" is mostly a weak restatement of
| "The PGP Problem". That anti-PGP rant has issues[1] that are
| relevant here.
|
| 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.
|
| [1] https://articles.59.ca/doku.php?id=pgpfan:tpp
|
| [2] https://articles.59.ca/doku.php?id=em:emailvsim
| tptacek wrote:
| Long-form asynchronous messaging is important and useful.
| It's just that SMTP email makes it virtually impossible to do
| so securely. As the author of both documents you cited, I
| take issue with the idea that one is a restatement of the
| other; that's obviously not true. The concerns in "S.U.E.A."
| are endemic to all forms of encrypted SMTP email, and the
| concerns in "T.P.P." are endemic to most possible uses of
| PGP. They're related sets of problems, but not even close to
| perfectly intersecting sets; the MasterCard logo, not the
| Toyota logo as you'd have it.
| IncRnd wrote:
| Except there are many other emails people don't want to be read
| by the wrong party. A powerful adversary or nation-state is not
| the only adversary.
| godelski wrote:
| >> Ordinary people don't exchange email messages that any
| powerful adversary would bother to read
|
| 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...
| dartharva wrote:
| How about we avoid using this archaic system altogether and
| switch to IM already?
| upofadown wrote:
| For more or less the same reasons that the invention of the
| telephone did not eliminate the use of memos and letters.
| Asynchronous long form communications is important and useful.
| jchook wrote:
| The email encryption tools available are not ergonomic or easy to
| set-up and maintain. It presents a steep learning curve that
| requires special plugins or email clients / search tools as the
| giants don't have good support for it.
|
| 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.
| sgjohnson wrote:
| There is no reasonable way to encrypt emails.
|
| It's far too easy to reply to the message without encryption or
| something of the sort.
|
| Email was never designed to be encrypted.
| dane-pgp wrote:
| There is no reasonable way to encrypt web traffic.
|
| 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.
| marwis wrote:
| Microsoft actually has ways of preventing that with
| information labeling. I used to work on company laptop that
| was using this extensively and it was not possible to copy
| something from higher to lower confidentiality. At least
| easily, there was a loophole involving cmd.exe.
| iggldiggl wrote:
| Web traffic reduced to its simplest case happens
| synchronously between two parties: Me, the client, and the
| server providing the resource I want to access. Encrypting
| the communication between those two points breaks various
| people in-between who want to listen in with varying degrees
| of legitimacy (others can't listen in on my traffic, but on
| the other hand I can't e.g. listen in on the traffic of IoT-
| devices in my home network any more, either), but it doesn't
| break anything a regular end user might immediately care
| about.
|
| 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
| jandrese wrote:
| There are reasonable ways to encrypt email, we just don't have
| them. PGP is not it, and I think PGP is at least partially
| responsible for actual working solutions never materializing.
| The PGP developers are too paranoid to develop a system that
| actually works. The web of trust is ridiculous overkill for
| most users, and should have been an option for really paranoid
| people, not the default. But because of the web of trust there
| is no good official scalable way to transfer public keys and
| thus the whole system doesn't work.
|
| 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.
| Ekaros wrote:
| Also if we actually care about privacy, maybe we should legally
| enshrine it universally like some countries do?
|
| Putting real legal barrier in place where at least some parties
| like employers could be swatted would already be improvement.
| throwaway984393 wrote:
| > It's probably worth asking why in 2022, people still don't use
| encryption systems to exchange emails,
|
| 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.
| jqpabc123 wrote:
| _I 'd send an encrypted zip file._
|
| 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.
| upofadown wrote:
| Attachments are always encrypted if the email is encrypted.
| So clients are already there...
| jqpabc123 wrote:
| What happens if the recipient doesn't have one of these
| clients?
|
| An encrypted Zip attachment works with any email client
| software.
| dspillett wrote:
| _> 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.
| samatman wrote:
| This is a non-starter because it doesn't, and can't, work the way
| you expect it to.
|
| 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.
| qwertox wrote:
| It would be nice if the page would stick to using HTTPS port 443
| exclusively, instead of reaching out to other ports as well and
| popping up the OS firewall.
|
| Also, Matrix TCP port 8448 is meant for federation, not for
| client communication.
| chrismorgan wrote:
| > _In fact, in the daily traffic, as described above, a large
| percentage of emails is sent "in plain text" without the adoption
| of cryptographic solutions that protect the content of each
| message._
|
| 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.)
| iggldiggl wrote:
| > 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.
|
| 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.)
| upofadown wrote:
| Non-anonymous encrypted emails are signed. So anonymous
| emails from people you don't know could be treated with great
| suspicion. In practice, widespread email encryption would be
| an almost complete solution to spam.
| iggldiggl wrote:
| What's to stop spammers from just making up identities?
|
| "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.
| born-jre wrote:
| is there any project (probably should be email server) which
| would use pubkey hash (secp256k1) as identity?
|
| 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.
| upofadown wrote:
| You could certainly do that with PGP. That would just be the
| key fingerprint. You would have to go look up the actual "PGP
| public key" after that. You could use web key directory (WKD)
| to make it transparent. Since secp256k1 doesn't support
| encryption there would have to be a lookup in that case as
| well.
|
| 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.
| sneak wrote:
| https://en.wikipedia.org/wiki/Zooko%27s_triangle
| xoa wrote:
| I'd absolutely love an email 2.0 with E2E encryption, but I doubt
| the ability of the industry/community to create something like
| that anymore as much as it depresses me. That email is so
| standard and federated despite pressure to the contrary is
| something of an accident of history and the time it was
| developed. The trend now is the opposite. It would probably also
| require a foundation of secured DNS which could then act as a
| transparent root of trust, but that hasn't been doing well
| either. Even a lot of "security experts" insist on stupid shit
| like Signal or the like being a replacement. So we'll continue to
| use email for highly sensitive and secure material and it'll just
| continue to be a window for a lot of adversaries I guess :(. It's
| not hard to envision a system with a few simple upgrades to make
| it both vastly more secure and help deal with spam at a much more
| root level, the pieces exist at the technology level. Yet I doubt
| it'll get out together and adopted. Path dependency is hard.
| patmorgan23 wrote:
| There's a handful of email hosting companies that have huge
| market share. If Microsoft and Google worked together they
| could implement any new email standard they want and everyone
| would have to follow.
| bombcar wrote:
| Exactly. If Microsoft or Google or both wanted to create a
| standard for Guaranteed Delivery and pile all sorts of stuff
| on it, they could.
|
| 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.
| m348e912 wrote:
| >>spam got "mostly solved" well enough.
|
| Did it though? Gmail is still having a tough time blocking
| all spam.
| seanw444 wrote:
| And most people with independently-run mail servers are
| screwed because it's "potential spam". Now you have
| almost no choice but to use a big tech platform if you
| want your email to be of any use. Which is ridiculous,
| and completely antithetical to a federated platform
| XorNot wrote:
| What's wrong with Signal? It works, it moves files, I don't
| have to jump through filtering hoops to do so. Signal is an
| excellent replacement for email when you need security.
| fsflover wrote:
| Signal is another walled garden actively trying to prevent
| decentralization. Expect that it will fail at some point in
| the future either due to too many users and too few money or
| something else.
|
| Consider Matrix instead.
| ekianjo wrote:
| Gotta love that someone always mentions Signal when it's
| obviously not a replacement for email.
| toastal wrote:
| Agree with sibling comments, but Signal is very much 'good
| enough' for a lot of people and use cases. I was able to
| covert my family to Signal, including grandparents, but I
| could not have done that with Matrix, Wire, PGP, etc. It's
| the entry point for decent encrypted chat.
| lkxijlewlf wrote:
| This. And _because_ it uses phone numbers, more people I
| know are less reluctant to switch to it.
| chaxor wrote:
| Use Session. It's just as easy, and more secure +
| decentralized. So it's better in just about every way.
| ericd wrote:
| Historical search is de facto absent on desktop since the
| messages get wiped regularly.
| agilob wrote:
| * History can't be synced into newly logged in devices
|
| * 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
| jonathanstrange wrote:
| I personally have no reason to encrypt my emails. I treat the
| vast majority of them as potentially public information since I
| work for a research institute and think that I should be and need
| to be accountable for anything I do at work. Whether private or
| work-related, I generally don't write anything in emails that I
| wouldn't also be willing to defend in person in front of an
| audience.
| zanethomas wrote:
| protonmail
| fjfbsufhdvfy wrote:
| Is this post some kind of a joke? First it complains that most
| users are unaware that emails even can be encrypted, and then
| goes off on a tangent about some command line garbage that 0% of
| these users will be able to use.
| olliej wrote:
| There are a few a real problems with encrypted email.
|
| 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.
| blibble wrote:
| do smtp clients validate certificates yet?
|
| my Debian postfixes with their default config certainly don't
| giuliomagnifico wrote:
| I totally agree, for that I'm sending encrypted emails also with
| my family and I wrote a quick tutorial on how to do it on Apple
| devices. https://giuliomagnifico.blog/tutorial/2021/01/13/ios-
| smime-a...
| grammers wrote:
| Just use Tutanota (EUR1/month) or Proton (EUR5/month) and be done
| with it. They even have free versions if you don't have your own
| domain.
|
| 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.
| jqpabc123 wrote:
| Ok, how do I force those I communicate with to do the same?
|
| 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.
| zoobab wrote:
| Rewrite the email protocol entirely, using crypto by default and
| MIXING.
| mixedmath wrote:
| What does "MIXING" mean in this context?
| Andrew_nenakhov wrote:
| No we should not. Logging in from anywhere and seeing all mail
| without problems, server side search improves the usability
| immensely. People who _need_ encryption for sensitive stuff
| should have this capability, but forcing mandatory encryption for
| everyone like various do-gooders do want to will lead to far too
| many problems for regular users.
___________________________________________________________________
(page generated 2022-03-01 23:01 UTC)