3 ms·
Technically, this is very nice work. But as a security generality - email is vastly less secure* than human nature wants to assume that it is. Human nature us
by bell-cot 2y ago
Technically, this is very nice work.
But as a security generality - email is vastly less secure* than human nature wants to assume that it is. Human nature usually wins.
*Outside of a carefully run org's own network, and a few other edge cases
- xmodem 2y agoYeah, so I guess there's no point in picking any of the low hanging fruit to make it more secure.
- sam_lowry_ 2y agoEmail is actually quite secure, just in a different way that web. For instance, once you disregard so called transactional mail and spam, real email is almost all encrypted for all practical purposes. DKIM and DMARC also work quite well for spoofing protection, aside from the corner cases like the above. Average Software Engineers have an outdated idea of email, formed by 1990 era Internet.
- tredre3 2y agoI think your view of email is romanticized, or perhaps skewed because of your social circle. Email servers sometimes use TLS to talk with eachother, and emails are signed. But that's the extent of encryption when it comes to "real email". Email content is not encrypted in "almost all" of "real email" because almost nobody uses PGP.
- sam_lowry_ 2y agoI don't know what social circle I should be part of to consider email unsecure. Even Russian spies use mail.ru and their emails are compromised not by SMTP MitM but by weak passwords, google for "moscow1 moscow2 password" to see what I am talking about ) Anyway. Back to the technical point. Email servers pretty much always use TLS to talk to each other. The connection may degrade to non-encrypted for backwards compatibility, unlike HTTPS. But it's vanishingly rare. So, for all practical purposes that affect ordinary citizens: injection, scanning and sensitive information extraction, email in transit is quite secure.
- bell-cot 2y agoDepends on context. If you're in IT at a carefully run org: You ditched 512-bit keys years ago. This article is nothing but a 20-second story, to help explain to PHB's and noobs why they got an error message, or what sorta important stuff you're always busy keeping your org safe from. If you're in IT at a scraping-by org: Maybe today's a good day to ditch 512-bit keys. And if you get push-back...gosh, here's a how-to article, showing how a "forged corporate signature stamp" can be made for only $8. If you're trying to teach senior citizen how to avoid being scammed on the internet: You've got zero visibility or control, so you're stuck with "sometimes these can be forged, depending on technical details" generalities.
- xoa 2y ago>But as a security generality - email is vastly less secure than human nature wants to assume that it is. I don't think this has to do with "human nature" anymore than http did. It's a very important, powerful form of communication without any secure replacement. Just as we switched to https, ideally an "xmail" or the like would get created as an open standard with open software that was email with better security by default. Sadly I'm not sure we collectively have the ability to do that kind of thing any longer, powerful entities have realized it's just too attractive to lock it up. But even many open source organizations don't seem to feel like bothering. Plenty of security experts even just prefer new shiny and will spout ridiculous "move to instant messaging". So status quo rules for the foreseeable future.
- immibis 2y agoEmail is one of a great number of internet communication systems. It happens to be one that was created before security was much of a concern (and before it was a problem we could solve), and also one that is highly asynchronous. Newer systems have their own different sets of tradeoffs. None of them happen to be email plus security. But that makes sense: now that everyone is online most of the time, why would you design a highly asynchronous store-and-forward-ish system? Of course you want a recipient to receive a message as soon as you sent it and the sender to confirm the recipient received the message. Designing a new system any other way would be leaving value* on the table. (*actual value not economics value) We can extend email, though. Why isn't there an SMTP GETKEY command to return a PGP key corresponding to an email address? Sure, the sender might not support the same version of PGP, and sure, the connection might be intercepted (hopefully you'd not trust the output of this command except over TLS), but like most of the email system, it would be a big improvement and good enough most of the time.
- avian 2y agoAs a small mail server admin I see this less about security of messages originating from me and more about the possibility of spammers sending DKIM-authenticated mail as coming from me (and resulting in shadow bans at gmail, etc. which is a huge pain to deal with)