3 ms·

> 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 suc

by 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!
- dpark 9y ago
  Employees looking on a whim is generally solved by encryption at rest with shared keys. You don’t need a unique key per user. You just need to make it really hard for the employee to get the key. Key per user doesn’t gain much except difficulty indexing for search. (I have no idea if Google encrypts email at rest, by the way.) As for SGX, it doesn’t really solve for this problem. It would allow Google to verify what software is running, but with a Google-controlled network in between the server in question and the user, I’m fairly certain any assurances SGX could yield are gone. Google could publish their code publicly, allow users to request attestation, but send attestation requests to server A running the public code while serving the user’s email on server B running NSA-modified snooping code. And of course your email isn’t actually sitting on a single machine anyway. It’s probably stored redundantly on 3+ backend machines and served by any of thousands of front end machines. Verifying each of these would be infeasible even if technically possible. (I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here.) Also attestation is for binaries. I doubt you could actually verify a source match.
  - munin 9y ago
    > I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here. There is magic you are missing. I don't want to be the person that glibly says "you should read more about this" and then vanishes, but because I don't have time to write out what the magic is, that's exactly what I'm going to do :( The magic does allow users to verify that the software they're talking to is what it says. Specifically, it also allows users to set up an encrypted channel with the processor that is running the software that is attested, so you exactly can't do the attack you propose of shuttling attestation to one system and actual data to another. The technology is pretty cool, you should check it out!
    - dpark 9y ago
      I don't want to glibly dismiss your comment either, but I fail to see how this helps users at all. From what I can tell, you're correct that the SGX connection can be structured such that attestation cannot be spoofed by sending the data request to a different service (assuming you trust Intel), but that doesn't really help end users. 1. Intel does not bill the technology for this purpose, which makes me doubt its fitness. SGX is very specifically billed as being for developers who want to run secure software in an untrusted environment, not for end users who don't trust the developers. These are wildly different scenarios. 2. The "encrypted channel with the processor" implies direct access to individual machines, which is impractical at Google scale. 3. The attestation is for binaries and not source, so attesting that the binaries are unchanged doesn't help users verify that the binaries match the trusted source. (Of course Google also doesn't publish the GMail source anyway.)

by dpark 9y ago

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!

dpark 9y ago
Employees looking on a whim is generally solved by encryption at rest with shared keys. You don’t need a unique key per user. You just need to make it really hard for the employee to get the key. Key per user doesn’t gain much except difficulty indexing for search. (I have no idea if Google encrypts email at rest, by the way.) As for SGX, it doesn’t really solve for this problem. It would allow Google to verify what software is running, but with a Google-controlled network in between the server in question and the user, I’m fairly certain any assurances SGX could yield are gone. Google could publish their code publicly, allow users to request attestation, but send attestation requests to server A running the public code while serving the user’s email on server B running NSA-modified snooping code. And of course your email isn’t actually sitting on a single machine anyway. It’s probably stored redundantly on 3+ backend machines and served by any of thousands of front end machines. Verifying each of these would be infeasible even if technically possible. (I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here.) Also attestation is for binaries. I doubt you could actually verify a source match.
- munin 9y ago
  > I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here. There is magic you are missing. I don't want to be the person that glibly says "you should read more about this" and then vanishes, but because I don't have time to write out what the magic is, that's exactly what I'm going to do :( The magic does allow users to verify that the software they're talking to is what it says. Specifically, it also allows users to set up an encrypted channel with the processor that is running the software that is attested, so you exactly can't do the attack you propose of shuttling attestation to one system and actual data to another. The technology is pretty cool, you should check it out!
  - dpark 9y ago
    I don't want to glibly dismiss your comment either, but I fail to see how this helps users at all. From what I can tell, you're correct that the SGX connection can be structured such that attestation cannot be spoofed by sending the data request to a different service (assuming you trust Intel), but that doesn't really help end users. 1. Intel does not bill the technology for this purpose, which makes me doubt its fitness. SGX is very specifically billed as being for developers who want to run secure software in an untrusted environment, not for end users who don't trust the developers. These are wildly different scenarios. 2. The "encrypted channel with the processor" implies direct access to individual machines, which is impractical at Google scale. 3. The attestation is for binaries and not source, so attesting that the binaries are unchanged doesn't help users verify that the binaries match the trusted source. (Of course Google also doesn't publish the GMail source anyway.)