4 ms·

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.

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.