4 ms·

> "it does seem that (much like Lavabit), the service is built on the premise of "won't" read your mail rather than "can't" read your mail." Can you help me un

> "it does seem that (much like Lavabit), the service is built on the premise of "won't" read your mail rather than "can't" read your mail." Can you help me understand this comment? I get that the usual problem with webmail is that it's "plaintext in, plaintext out"... So you just have to trust the server operator that they're actually encrypting anything, doing it well, not compromised, etc. But if that's the problem, why isn't the answer to have client side code handling the encryption? From skimming the page source and reading https://protonmail.com/security-details https://protonmail.com/security-details, that's exactly what Protonmail does. First you use a username/password to authenticate with protonmail - that's cleartext in/out - this only determines which account you are accessing. Once you're authenticated, your browser runs an open source AngularJS application, which asks you for a separate, client-side-only password. Once you've authenticated, your browser only sends/receives cyphertext. I know you by reputation and I'm a big fan of your work... so I assume I'm missing something. Am I misunderstanding the problem? What am I missing here?

tptacek 11y ago
If you have an installable client that performs the encryption, yes. But if the encryption is driven by Javascript that is or can be loaded when you hit the website, then no: the application is only as secure as the HTTP connection you rely on to deliver the code to you every time you hit the site.
- ohthehugemanate 11y ago
  that's totally fair, but you are dependent on transport layer security implementation no matter what.
  - x1798DE 11y ago
    There are secure channels for delivering installable client software that allows protection of content even without transport layer security, and you only need to do it correctly during installation and intermittent updates, not at every access.
    - ohthehugemanate 11y ago
      what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any. It's a good point that you only have to trust both environments at install and update... but you can do the same thing for javascript in a browser: set a long cache time, and browsers will use their local copy until the remote is updated. Use a module loader pattern, and you can compare md5 hashes of the local and remote libraries before sensitive data is handled. I'm not saying it would foil a dedicated attacker - nothing would, anyway - but it would be good enough for protonmail's use case: protecting normal people against mass surveillance.
      - e12e 11y ago
        > what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any. Assuming you trust your hardware: I could hand you a bootable CD. In practice, there's a bootstrap problem: the general way is to trade the insecure CA system (will always be insecure, there are too many trusted parties, all the CAs) with a web of trust and/or widely distributed hash'es of ISO images/install files. While surely your cd writer software theoretically could be backdoored so that it will compromise all bootable iso's (all bootloaders?) that contain a gpg executable - that is something quite different from having a rouge CA sign a cert, allowing the individual replacement of js code on a single connection. Ultimately, one can only trust people, web-of-trust is an attempt at widening that network geographically with the help of technology. It's not perfect, but I think it's hard to argue that it's not better and more flexible than the CA system. [ed: Note that getting an iso file over an insecure channel; bittorrent, ftp, http -- isn't a problem if you can verify a signature. Now, you still need to have a way to trust the signature (by way of well-known, trusted, cross-signed keys). But compromising the server and the transport now becomes a denial of service, not a compromise of the client. And again, yes there are some bootstrap issues here too.]
      - Freak_NL 11y ago
        The benefit of installable client software is that the encryption software and the relaying party (your e-mail provider) are completely unrelated and separate. So if I use GMail and encrypt my messages to Bob with GnuPG, than no matter what GMail does with the encrypted message, it either gets delivered securely (and is verifiable by Bob as having been written by me) or not. Any adversary would have to compromise the source of my operating system's GnuPG version (or Bob's), and have access to the messages themselves. The browser model explicitly trusts the remote server to provide whatever JavaScript code it sees fit, so if your e2e webmail provider is compromised, you get a backdoored crypto library that works as far as your browser and you can tell. It all comes down to trust of course, but the separation of concerns adds a very real layer of security, and I trust Debian and its maintainers (and the experts who scrutinize these things) more than a single commercial e-mail provider.
buu700 11y ago
The problem is that they're trusting the integrity of that client-side code to their servers on each use, which is in practice not meaningfully different from a traditional non-E2EE email service. The only difference in attack pattern, in the event of a server compromise, would be that the attacker would have to send you a line of JS to steal your password/key before reading your emails.

tptacek 11y ago

If you have an installable client that performs the encryption, yes. But if the encryption is driven by Javascript that is or can be loaded when you hit the website, then no: the application is only as secure as the HTTP connection you rely on to deliver the code to you every time you hit the site.

ohthehugemanate 11y ago
that's totally fair, but you are dependent on transport layer security implementation no matter what.
- x1798DE 11y ago
  There are secure channels for delivering installable client software that allows protection of content even without transport layer security, and you only need to do it correctly during installation and intermittent updates, not at every access.
  - ohthehugemanate 11y ago
    what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any. It's a good point that you only have to trust both environments at install and update... but you can do the same thing for javascript in a browser: set a long cache time, and browsers will use their local copy until the remote is updated. Use a module loader pattern, and you can compare md5 hashes of the local and remote libraries before sensitive data is handled. I'm not saying it would foil a dedicated attacker - nothing would, anyway - but it would be good enough for protonmail's use case: protecting normal people against mass surveillance.
    - e12e 11y ago
      > what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any. Assuming you trust your hardware: I could hand you a bootable CD. In practice, there's a bootstrap problem: the general way is to trade the insecure CA system (will always be insecure, there are too many trusted parties, all the CAs) with a web of trust and/or widely distributed hash'es of ISO images/install files. While surely your cd writer software theoretically could be backdoored so that it will compromise all bootable iso's (all bootloaders?) that contain a gpg executable - that is something quite different from having a rouge CA sign a cert, allowing the individual replacement of js code on a single connection. Ultimately, one can only trust people, web-of-trust is an attempt at widening that network geographically with the help of technology. It's not perfect, but I think it's hard to argue that it's not better and more flexible than the CA system. [ed: Note that getting an iso file over an insecure channel; bittorrent, ftp, http -- isn't a problem if you can verify a signature. Now, you still need to have a way to trust the signature (by way of well-known, trusted, cross-signed keys). But compromising the server and the transport now becomes a denial of service, not a compromise of the client. And again, yes there are some bootstrap issues here too.]
    - Freak_NL 11y ago
      The benefit of installable client software is that the encryption software and the relaying party (your e-mail provider) are completely unrelated and separate. So if I use GMail and encrypt my messages to Bob with GnuPG, than no matter what GMail does with the encrypted message, it either gets delivered securely (and is verifiable by Bob as having been written by me) or not. Any adversary would have to compromise the source of my operating system's GnuPG version (or Bob's), and have access to the messages themselves. The browser model explicitly trusts the remote server to provide whatever JavaScript code it sees fit, so if your e2e webmail provider is compromised, you get a backdoored crypto library that works as far as your browser and you can tell. It all comes down to trust of course, but the separation of concerns adds a very real layer of security, and I trust Debian and its maintainers (and the experts who scrutinize these things) more than a single commercial e-mail provider.

buu700 11y ago

The problem is that they're trusting the integrity of that client-side code to their servers on each use, which is in practice not meaningfully different from a traditional non-E2EE email service. The only difference in attack pattern, in the event of a server compromise, would be that the attacker would have to send you a line of JS to steal your password/key before reading your emails.