4 ms·
> In the meantime if any UC Berkeley people want to learn how to use GPG for encrypting email Could you explain why this should be necessary when email communi
by wfunction 11y ago
> In the meantime if any UC Berkeley people want to learn how to use GPG for encrypting email
Could you explain why this should be necessary when email communication between the servers and clients is already encrypted via SSL/TLS? Can they bypass that? (And if so how?)
- abstractbeliefs 11y agoBecause the operators of the servers cannot be trusted. SSL/TLS protects the data in motion, from people monitoring the networking by illegitimately MITMing users. GPG protects data at rest from server operators reading things they should not.
- dorfsmay 11y agoHow do you know that all your recipients' mail server aren't monitored (or webclient and the NSA pumps the data between the ssl termination and the web server, eg: google)? As a rule of thumb, if you care enough that it should not be seen by others, encrypt before it is sent, before it is written to disk. You have no control over a stolen laptop, over what the backup servers (assuming remote backup), etc... If it is private, encrypt. There's a bit of a learning curve, but once you do it often enough it just becomes part of the workflow. Good tools you should use on a regular basis: KeepassX, gpg, Enigmail
- wfunction 11y agoThat's always true though and it has nothing to do with this situation in particular.
- dorfsmay 11y ago> it has nothing to do with this situation in particular. Please read the parent's question, asking why it would be necessary to encrypt when using SSL/TLS. I explain why, and yes I do go a little bit further to more general cases, because I am assuming that if they don't understand the need to encrypt in this specific case they could benefit, and hopefully appreciate, to understand the more general cases as well.
- deleted 11y ago[deleted]
- pdkl95 11y ago> servers You're trusting the server too much. While TLS servers an important role, it is only protecting the link, not he data. End-to-end encryption (which PGP/GPG provides) is important for the same reason bittorrent is so successful: it protects the data, not the host. When bittorrent was new, a common concern was that you might be getting the data form anybody, including people who are malicious. This concern was a product of traditional download methods where you had to trust the person sending the data ("only download from reputable sources"). Bittorrent bypassed that problem by providing hashes, so the data itself could be verified regardless of how you got it. Securing of a host or connection suffers from the same problem. Just like how reputable fileservers can still be hacked or strong-armed into serving incorrect data, the server at the end of the TLS connection can be compromised. > how That depends on the people at the TLS endpoints who see the plaintext. If they are collaborators, they simply build in access to the plaintext and we call it "Prism". If they are refuseniks, it might be necessary use a national security letter.
- prdonahue 11y agoNot to mention the fact that they're probably installing their own root certs on the endpoints and then just MITM'ing everything with their own certs.
- zrm 11y ago> Could you explain why this should be necessary when email communication between the servers and clients is already encrypted via SSL/TLS? Can they bypass that? (And if so how?) RFC2487 Section 5: A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address. In other words, internet mail servers are required to allow a trivial downgrade to plaintext by a MITM attacker.
- btgeekboy 11y agoAnd if you don't follow the RFC, the internet police will come after you! Yes, I am aware of the RFC2119 meaning of "MUST NOT." In reality, nothing prevents the servers from disallowing that downgrade, except that they may not be interoperable with other servers on the internet. If the operator of the server wishes to make that tradeoff, then requiring STARTTLS is an option.
- zrm 11y agoIf you don't follow the RFC then people will email you from gmail saying "I tried to send you mail from my company's mail server and it didn't work", other people will submit a github issue to your project saying they couldn't email you, and when you try to subscribe to one of djb's mailing lists you'll get a response from your mail server saying it couldn't deliver the message. That is what actually happened when I tried it.
- spc476 11y agoAnd I subscribed to a mailing list years ago that suddenly went TLS-mandatory (for incoming email---it doesn't demand TLS when sending email) and now I can't even unsubscribe from the list.
- LinuxBender 11y ago
- throwaway72727 11y agoI think this point has been made in some way or another in the thread, but I want to try to restate it. Suppose Alice (alice@gmail.com) emails Bob (bob@yahoo.com). If Alice sends Bob an email without PGP encryption, the text of those emails is stored on both Google's and Yahoo's servers, allowing either of those companies to read the email (or a government if served with a subpoena, or others -- possibly the general public -- in the event of a data breach). This is true regardless of whether it was sent with TLS at every point in the chain. On the other hand, if Alice uses PGP to actually encrypt the text of the email with Bob's and her public key, nobody except Alice and Bob themselves (not even Yahoo or Google, who have the message stored on their servers) can read the message. It's an important distinction -- as major consumer messaging products like Apple's iMessage, WhatsApp, etc. have recently started to implement this end-to-end encryption where even the company themselves are unable to read the message their users are sending, the FBI and other federal agencies have started to actually complain about their newly limited ability to spy, unlike when only TLS was used and they could just serve an NSL to Apple/Google/etc. to make them give up your message without your knowledge (with their only other option being shutting down their business, more or less).