3 ms·

> that doesn't mean G employees will go in and look at your emails There are two forms of this assurance. The first is running into some guy at a party, or on

by munin 9y ago

> that doesn't mean G employees will go in and look at your emails There are two forms of this assurance. The first is running into some guy at a party, or on an internet message board, who either works at Google or "knows a guy" who does, who then spends thirty or forty minutes semi-drunkenly rambling at you about how the security at Google is "military grade" and everything is "locked down" and they have some guy who used to run the Mossad in charge of internal security and he's the best guy ever and nothing or no one ever breaks in and that shit's a fortress. Trust the semi drunken ramblings of this guy you just met, your secrets are safe with the big G. The second form of this assurance is only giving the third party indistinguishable encrypted blobs of data. They can look at them all they want, it doesn't mean anything to them. You don't need to trust anyone, let alone some guy you found on the Internet and transitively a few hundred anonymous computer programmer and IT janitors spread across the world. Go figure, some people are more persuaded by the second argument. Even if you're reading this and you work at G and you know that the ex-Mossad security guys are digitally looking over your shoulder and you shake your fist at this screen muttering "you don't know how much we have it locked down here, clueless Hacker News commentator" you have to realize, somewhere in your heart of hearts, that a zero trust solution is preferable when you are trying to maximize for security.

3pt14159 9y ago
Email is a really dumb thing to put this to because 99.999% of the emails you receive will be sent by less paranoid people and 99.99% of the emails you send will be to less paranoid people. Just get a pretty locked down Gmail account and use pen and paper or OTPs or GPG for things that actually need to be secure.
- fixermark 9y ago
  Exactly. Concrete example: The only two sources of Clinton emails being made public were 1) Emails disclosed as part of a legal discovery process that compelled Clinton to hand over the emails herself. 2) Copies of her emails acquired from a correspondent with a much-less-secure configuration of their Gmail account than Clinton's configuration of her private server. Email is, by its nature, a distributed infosec problem.
- ubernostrum 9y ago
  For the average person in 2017, the threat of a breach of their email account is not that the contents of emails they sent or received will be published and used for nefarious purposes. Some celebrities, government officials and business people need to worry about that, but they're a tiny subset of the general email-using population. The threat of a breach of the email account is that it's the key to everything else -- pretty much any other account, with any other service, is instantly accessible the moment you're in someone's email, because the email inbox is where credential-reset requests are sent.
dpark 9y ago
> you have to realize, somewhere in your heart of hearts, that a zero trust solution is preferable when you are trying to maximize for security. There’s no such thing as zero trust for email unless you’re going to run your own server (even then it’s iffy because of communication with other untrusted servers). By using a mail service, you have to trust the people running the service. Even if they pinky promise to immediately encrypt every message with your public key a never never never look at it, you cannot know that they aren’t secretly redirecting a copy to the NSA and publishing another copy on the novelty Twitter account @muninmails.
- astura 9y ago
  Which was a criticism of lavabit's advertising of "so secure that even our administrators can’t read your e-mail." https://moxie.org/blog/lavabit-critique/ https://moxie.org/blog/lavabit-critique/ Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext. The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference. ... The operator can at any time stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext email...The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though they advertised that they “can’t” read your email, what they meant was that they would choose not to.
- munin 9y ago
  This is also true. I think the particular threat I was replying to was "can employees, on a whim, go into stored e-mail and view it?" You're right that there's another possibility, which is that on a whim the employees will engineer a system such that they can view all the plaintext that flows into and out of your inbox. There are maybe a few things that could be done to reduce your trust in "Honest Munin's Very Secure E-Mail Hosting and Used Cars", like, I could publish the code to the server and run it in SGX, allowing anyone in the world to use SGX attestation to verify* that the code running in SGX is the code that I publish, and that code could only initiate encrypted network connections with other mail servers. So even if I ran that in good faith and sat outside the SGX container listening to the network traffic, I'd still be getting a face-full of encrypted data. This is still a "verify*" because maybe something is funky with SGX. You're not really trusting me now though, you're trusting Intel and the SGX TCB. Maybe that's worse? I don't know. I still think that's an improved proposition over trusting the honesty of system administrators to not grep your INBOX on a whim, though. edit: I guess this also kind of breaks down because the story for TLS in SMTP land is kind of dire, so you could probably actively MITM the communication between the SGX blob and the outside and there's no practical way for anyone to know that this is going on. Maybe someone will fix that someday! Probably not though!
lostboys67 9y ago
An CNI company employs non USA nationals in sensitive roles I would hope not this isn't NCIS (the TV Show)
fixermark 9y ago
If you're trying to maximize for security, you'd never send email. ;)

by munin 9y ago

3pt14159 9y ago

Email is a really dumb thing to put this to because 99.999% of the emails you receive will be sent by less paranoid people and 99.99% of the emails you send will be to less paranoid people. Just get a pretty locked down Gmail account and use pen and paper or OTPs or GPG for things that actually need to be secure.

fixermark 9y ago
Exactly. Concrete example: The only two sources of Clinton emails being made public were 1) Emails disclosed as part of a legal discovery process that compelled Clinton to hand over the emails herself. 2) Copies of her emails acquired from a correspondent with a much-less-secure configuration of their Gmail account than Clinton's configuration of her private server. Email is, by its nature, a distributed infosec problem.
ubernostrum 9y ago
For the average person in 2017, the threat of a breach of their email account is not that the contents of emails they sent or received will be published and used for nefarious purposes. Some celebrities, government officials and business people need to worry about that, but they're a tiny subset of the general email-using population. The threat of a breach of the email account is that it's the key to everything else -- pretty much any other account, with any other service, is instantly accessible the moment you're in someone's email, because the email inbox is where credential-reset requests are sent.

dpark 9y ago

> you have to realize, somewhere in your heart of hearts, that a zero trust solution is preferable when you are trying to maximize for security. There’s no such thing as zero trust for email unless you’re going to run your own server (even then it’s iffy because of communication with other untrusted servers). By using a mail service, you have to trust the people running the service. Even if they pinky promise to immediately encrypt every message with your public key a never never never look at it, you cannot know that they aren’t secretly redirecting a copy to the NSA and publishing another copy on the novelty Twitter account @muninmails.

astura 9y ago
Which was a criticism of lavabit's advertising of "so secure that even our administrators can’t read your e-mail." https://moxie.org/blog/lavabit-critique/ https://moxie.org/blog/lavabit-critique/ Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext. The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference. ... The operator can at any time stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext email...The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though they advertised that they “can’t” read your email, what they meant was that they would choose not to.
munin 9y ago
This is also true. I think the particular threat I was replying to was "can employees, on a whim, go into stored e-mail and view it?" You're right that there's another possibility, which is that on a whim the employees will engineer a system such that they can view all the plaintext that flows into and out of your inbox. There are maybe a few things that could be done to reduce your trust in "Honest Munin's Very Secure E-Mail Hosting and Used Cars", like, I could publish the code to the server and run it in SGX, allowing anyone in the world to use SGX attestation to verify* that the code running in SGX is the code that I publish, and that code could only initiate encrypted network connections with other mail servers. So even if I ran that in good faith and sat outside the SGX container listening to the network traffic, I'd still be getting a face-full of encrypted data. This is still a "verify*" because maybe something is funky with SGX. You're not really trusting me now though, you're trusting Intel and the SGX TCB. Maybe that's worse? I don't know. I still think that's an improved proposition over trusting the honesty of system administrators to not grep your INBOX on a whim, though. edit: I guess this also kind of breaks down because the story for TLS in SMTP land is kind of dire, so you could probably actively MITM the communication between the SGX blob and the outside and there's no practical way for anyone to know that this is going on. Maybe someone will fix that someday! Probably not though!

lostboys67 9y ago

An CNI company employs non USA nationals in sensitive roles I would hope not this isn't NCIS (the TV Show)

fixermark 9y ago

If you're trying to maximize for security, you'd never send email. ;)