12 ms·

Some bad signs: 1. Hosted in Switzerland is advertised as a security feature. The point of e2e is that the servers are untrusted. If you need a "good jurisdic

by moxie 11y ago

Some bad signs: 1. Hosted in Switzerland is advertised as a security feature. The point of e2e is that the servers are untrusted. If you need a "good jurisdiction" for your servers, it means they must be trusted. That's a problem, because sadly there are no good jurisdictions in today's world, and your jurisdiction doesn't help you if your servers are hacked. 2. It's webmail. That means the security of whatever e2e they're doing is based on the security of SSL. If you break SSL, you can break whatever e2e they're doing, and that means your e2e security is only as secure as the CA system. 3. Their 'threat model' documentation leads with: "From a high level, our premise is that a service like the now-defunct Lavabit does add value, despite some inherent weaknesses. We designed ProtonMail around many of the same principles..." Given what happened with Lavabit (the eventual compromise of everyone's email despite shutting down the service), considering it to have been "valuable" should really be off the table at this point: http://www.thoughtcrime.org/blog/lavabit-critique/ http://www.thoughtcrime.org/blog/lavabit-critique/ I can't find much in the way of technical documentation for ProtonMail, but from what little is available, 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.

rdl 11y ago
Even with e2e you have availability concerns, so picking a "good" jurisdiction makes sense. The rest of your criticisms are completely valid -- webmail is never going to approach the security of true e2e client crypto. The best possible system for webmail would be a browser extension or in the far future world, some kind of browser security extensions. Failing that, there's probably value in "best effort" secure webmail if users are explicitly aware of the limitations. The problem is even developers aren't really aware of the limitations (since they vary with threats and per user), so this is probably not a realistic goal.
- farfromright 11y ago
  Would you care to comment on Cyph [1]? They claim that they are able to approximate client side programs that provide e2e but in a non-plugin browser environment [2]. I know tptacek doesn't like it but he wasn't willing to go into a detailed account of why. [1] https://cyph.com https://cyph.com [2] https://docs.google.com/document/d/1XVh4ALXhbfxi70QSUY-xHclauob8O635bSySy6f1Ysk/edit?pref=2&pli=1 https://docs.google.com/document/d/1XVh4ALXhbfxi70QSUY-xHcla...
  - buu700 11y ago
    Cyph cofounder here; thanks for the mention! It'd be great to hear thoughts from Moxie or anyone else on WebSign. By the way, I think this was the doc you meant to link to for [2]: http://cyph.team/websigndoc http://cyph.team/websigndoc.
  - eganist 11y ago
    Hah. I had some time to think about that interaction and concluded (after a chat with a few peers at AppSec Cali) that he and I simply differ in mentality. I understand where he's coming from about the risks posed by that level of flexibility in the execution environment, but I'm also more prone to push for the idea that making encryption more convenient for all justifies taking some risks in terms of the execution environment so long as we can (to the best of our knowledge) sufficiently mitigate them. That and browser sandboxing helps a ton more than having someone break an app running in userspace. His objection might be at a more visceral level, which I understand but steadfastly disagree with.
    - tptacek 11y ago
      You guys seem to remember more about "this interaction" than I do. Someone want to bring me up to speed?
      - buu700 11y ago
        There was a thread a couple months back where I brought up WebSign (Cyph's TOFU in-browser code signing layer) in response to a story about MEGAChat, which you generally disapproved of but didn't go into detail on why. There was also some related back-and-forth between you and eganist. My impression was that you hadn't necessarily had the chance to fully digest the architecture due to time constraints on your end, and were coming more from a position of "the premise of this is scary and it's almost definitely broken in some way" than of having identified a specific flaw. Also, as eganist noted here, you may have held a different opinion than us on the drawbacks of the flexible execution environment (despite Cyph's partial mitigations of TypeScript for static typing and asm.js for pseudo-native crypto) vs the benefits of the well-vetted sandbox.
- drakenot 11y ago
  Speaking of e2e browser extensions, does anyone know what the status of Google's "End-to-End" chrome extension[0] is? They started the project in June of 2014 and the development pace on the project has been somewhat slow. I don't know if this is just a couple dev's 20% project or if it has dedicated resources, or what. [0] https://github.com/google/end-to-end https://github.com/google/end-to-end
deleted 11y ago
[deleted]
suprgeek 11y ago
Is there a "better" free alternative webmail?
- nickpsecurity 11y ago
  You should consider all of them insecure and big time snoops if free and/or webmail. If webmail, best you can do is use a paid service with antisnooping in terms of service and preferrably local laws. Just reduces number that will attack you. Anything further requires using something like PGP/GPG over that so they can't read it. Strong endpoint security, too.
  - suprgeek 11y ago
    Thanks for taking the time to reply. Non-webmail may not be accessible from everywhere, paid-email entails money exchange which maybe traceable. Lavabit seems to have been secure enough for Snowden (for a while). So the question remains: Yes Free and/or Webmail are bad - which one is the LEAST bad from a privacy & security perspective?
    - LeoPanthera 11y ago
      There's a good list here that should allow you to decide for yourself: http://prxbx.com/email/ http://prxbx.com/email/
      - nickpsecurity 11y ago
        That is a good list.
    - msh 11y ago
      I like mailbox.org They support pgp encryption.
nickpsecurity 11y ago
1. You still need a good jurisdiction to avoid being compelled by public or secret courts to damage your users. Switzerland is pretty reasonable about their privacy stance and LI requests. The flip is that, outside Five Eyes, the TAREX teams can target them along with whatever TAO wants to throw in. No restrictions. They better know strong INFOSEC. 2. Webmail complaint is probably legit. That does in nation-state's targets over time. Might be a compromise, though, to up baseline of those that absolutely refuse to use other stuff. 3. Most of the new services have this problem. It's like they have more enthusiasm or business savvy than actual INFOSEC skill. There's many schemes proven in field or pentesting they can copy. Yet, inspired by the one that failed? (Rolls eyes) I'm just using GPG over MyKolab for now. Keep them untrusted but in jurisdiction with lower availability risks from takedowns. I encourage you to keep up your own great work with addition of cross-platform desktop stuff. Maybe people like me will finally get off GPG for something less horrible to use but scares NSA just as much. ;)
ohthehugemanate 11y ago
> "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.
vabmit 11y ago
Disclosure Note: I'm with ProtonMail. Please note that I don't officially speak for the company. But, I'm a crypto guy and this is Hackernews so... 1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it goes much beyond the physical servers. Simply locating servers in Switzerland doesn't provide much protection for users if you're an American company with US bank accounts. For example, choosing to run on German or Irish AWS servers doesn't really buy you much. But, ProtonMail not only has all of its servers located in Swiss datacenters, it also: 1) Is a Swiss corporation fully under the jurisdiction of Swiss law (which also means it operates under strict customer data anti-retention requirements) 2) Holds its funds in a Swiss bank 3) Has corporate officers that reside in Switzerland 4) Offers .ch e-mail addresses and a .ch web interface that cannot be taken control of through US courts and that are resolved through Swiss DNS servers 5) Is using a non-US (Swiss) Certificate Authority (QuoVadis) for its certificates. 2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. It also includes any software that runs on platforms that have patches distributed over TLS. That is nearly everything. It's no more difficult to insert malicious code into web apps than it is to insert it into mobile phone apps, desktop apps, or operating system patches when working with a compromised trusted TLS connection. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. There are devices out there with trusted hardware and embedded keys and some groups are starting to make use of proper TPMs. But, high quality trusted platforms are beyond the reach of most consumers and developers. I know of no platform that would catch the insertion of malicious code by a determined third party with the ability compromise a TLS session in the release and/or development cycle. If webapps are faulted and everyone is using a webapp (github) to develop, well then, everyone is essentially equally compromised. The same goes for distributing updates or public keys for validation of code signatures. 3. The company did, in the early days, see Lavabit as a inspiration. But, our systems are very different. Our systems are "can't read your mail" not "promise not to read your mail". Proton has no need to avert its eyes. There is no "plaintext in and plaintext out". There is no transmission of the private key decryption passwords back to the server. I don't think your comparison holds. The way Proton works is that the encryption is done in the browser. A non-encrypted private key is not stored, or ever sent to, the Proton servers. An openPGP keypair is generated in the browser by the user. The public key is sent to servers and stored in a database. The private key is encrypted in the client's browser, with a passphrase the client enters, using the opensource openpgpjs library. That encrypted (with a password that is never sent back to the Proton servers) private key is sent to the Proton servers and stored in a database. When a user logs in, their encrypted openPGP key is sent down to their browser with their public key encrypted e-mail. Their web browser then decrypts their private key and uses it to decrypt their email on the local computer. We never have to avert our eyes from their passphrase because it never transverses our systems. The decryption is done locally. Obviously, it would be better for us not to store the private key (even though it's strongly encrypted). But, that's just not practical for a webmail application. So, I'm sure everyone is wondering: What would a TLS based ProtonMail compromise look like? Well, modified code (nefarious javascript) would be injected into the TLS stream that would send the user's decrypted private key and/or private key pass phrase to a third party or otherwise expose it (as invalid packets, etc) in the stream. Or, carefully selected cryptographic primitives would be inserted into the software. I contend that these are the same vulnerabilities someone faces downloading GnuPG from it's distribution sites, downloading Firefox/Chrome/IE, or even applying Windows/Linux updates. And, I'm also sure people are wondering: What would a US Government compromise of the ProtonMail servers look like? Well, I'll leave the details out on how the US Government might get their hands on Swiss domiciled servers... maybe something like the time they cut through a datacenter wall at MIT in the middle of the night to get the early PGP code. Let's just assume they have the servers. They'd first have to break the disk encryption. Once they broke the disk encryption, they'd have to break into the database. Once they did that, they'd basically have a bunch of AES encrypted keys that they'd have to run password guessing attacks on. ProtonMail is trying to bring cryptography to the general population to protect the basic human right of privacy. We are doing webmail the best possible way webmail can be done because webmail is the primary method of communicating for the vast majority of people today. We are not going to get our grandmas to sit in Faraday cages and work on trusted platforms with one time pads that they exchanged at their church groups and yoga classes. There is no security through obscurity in what we're doing. Honestly, I'd be honored if you took a look. We use Signal internally. I've read through the code and was very impressed. I couldn't find a single flaw that I could exploit. Perhaps, you'd even be willing to do a consulting engagement to audit us?
rbcgerard 11y ago
How (if at all) does this change if you only use their iOS/Android app to access their service?
duaneb 11y ago
So—run your own server with your own root CA?

by moxie 11y ago

rdl 11y ago

Even with e2e you have availability concerns, so picking a "good" jurisdiction makes sense. The rest of your criticisms are completely valid -- webmail is never going to approach the security of true e2e client crypto. The best possible system for webmail would be a browser extension or in the far future world, some kind of browser security extensions. Failing that, there's probably value in "best effort" secure webmail if users are explicitly aware of the limitations. The problem is even developers aren't really aware of the limitations (since they vary with threats and per user), so this is probably not a realistic goal.

farfromright 11y ago
Would you care to comment on Cyph [1]? They claim that they are able to approximate client side programs that provide e2e but in a non-plugin browser environment [2]. I know tptacek doesn't like it but he wasn't willing to go into a detailed account of why. [1] https://cyph.com https://cyph.com [2] https://docs.google.com/document/d/1XVh4ALXhbfxi70QSUY-xHclauob8O635bSySy6f1Ysk/edit?pref=2&pli=1 https://docs.google.com/document/d/1XVh4ALXhbfxi70QSUY-xHcla...
- buu700 11y ago
  Cyph cofounder here; thanks for the mention! It'd be great to hear thoughts from Moxie or anyone else on WebSign. By the way, I think this was the doc you meant to link to for [2]: http://cyph.team/websigndoc http://cyph.team/websigndoc.
- eganist 11y ago
  Hah. I had some time to think about that interaction and concluded (after a chat with a few peers at AppSec Cali) that he and I simply differ in mentality. I understand where he's coming from about the risks posed by that level of flexibility in the execution environment, but I'm also more prone to push for the idea that making encryption more convenient for all justifies taking some risks in terms of the execution environment so long as we can (to the best of our knowledge) sufficiently mitigate them. That and browser sandboxing helps a ton more than having someone break an app running in userspace. His objection might be at a more visceral level, which I understand but steadfastly disagree with.
  - tptacek 11y ago
    You guys seem to remember more about "this interaction" than I do. Someone want to bring me up to speed?
    - buu700 11y ago
      There was a thread a couple months back where I brought up WebSign (Cyph's TOFU in-browser code signing layer) in response to a story about MEGAChat, which you generally disapproved of but didn't go into detail on why. There was also some related back-and-forth between you and eganist. My impression was that you hadn't necessarily had the chance to fully digest the architecture due to time constraints on your end, and were coming more from a position of "the premise of this is scary and it's almost definitely broken in some way" than of having identified a specific flaw. Also, as eganist noted here, you may have held a different opinion than us on the drawbacks of the flexible execution environment (despite Cyph's partial mitigations of TypeScript for static typing and asm.js for pseudo-native crypto) vs the benefits of the well-vetted sandbox.
drakenot 11y ago
Speaking of e2e browser extensions, does anyone know what the status of Google's "End-to-End" chrome extension[0] is? They started the project in June of 2014 and the development pace on the project has been somewhat slow. I don't know if this is just a couple dev's 20% project or if it has dedicated resources, or what. [0] https://github.com/google/end-to-end https://github.com/google/end-to-end

deleted 11y ago

[deleted]

suprgeek 11y ago

Is there a "better" free alternative webmail?

nickpsecurity 11y ago
You should consider all of them insecure and big time snoops if free and/or webmail. If webmail, best you can do is use a paid service with antisnooping in terms of service and preferrably local laws. Just reduces number that will attack you. Anything further requires using something like PGP/GPG over that so they can't read it. Strong endpoint security, too.
- suprgeek 11y ago
  Thanks for taking the time to reply. Non-webmail may not be accessible from everywhere, paid-email entails money exchange which maybe traceable. Lavabit seems to have been secure enough for Snowden (for a while). So the question remains: Yes Free and/or Webmail are bad - which one is the LEAST bad from a privacy & security perspective?
  - LeoPanthera 11y ago
    There's a good list here that should allow you to decide for yourself: http://prxbx.com/email/ http://prxbx.com/email/
    - nickpsecurity 11y ago
      That is a good list.
  - msh 11y ago
    I like mailbox.org They support pgp encryption.

nickpsecurity 11y ago

1. You still need a good jurisdiction to avoid being compelled by public or secret courts to damage your users. Switzerland is pretty reasonable about their privacy stance and LI requests. The flip is that, outside Five Eyes, the TAREX teams can target them along with whatever TAO wants to throw in. No restrictions. They better know strong INFOSEC. 2. Webmail complaint is probably legit. That does in nation-state's targets over time. Might be a compromise, though, to up baseline of those that absolutely refuse to use other stuff. 3. Most of the new services have this problem. It's like they have more enthusiasm or business savvy than actual INFOSEC skill. There's many schemes proven in field or pentesting they can copy. Yet, inspired by the one that failed? (Rolls eyes) I'm just using GPG over MyKolab for now. Keep them untrusted but in jurisdiction with lower availability risks from takedowns. I encourage you to keep up your own great work with addition of cross-platform desktop stuff. Maybe people like me will finally get off GPG for something less horrible to use but scares NSA just as much. ;)

ohthehugemanate 11y ago

> "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.

vabmit 11y ago

Disclosure Note: I'm with ProtonMail. Please note that I don't officially speak for the company. But, I'm a crypto guy and this is Hackernews so... 1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it goes much beyond the physical servers. Simply locating servers in Switzerland doesn't provide much protection for users if you're an American company with US bank accounts. For example, choosing to run on German or Irish AWS servers doesn't really buy you much. But, ProtonMail not only has all of its servers located in Swiss datacenters, it also: 1) Is a Swiss corporation fully under the jurisdiction of Swiss law (which also means it operates under strict customer data anti-retention requirements) 2) Holds its funds in a Swiss bank 3) Has corporate officers that reside in Switzerland 4) Offers .ch e-mail addresses and a .ch web interface that cannot be taken control of through US courts and that are resolved through Swiss DNS servers 5) Is using a non-US (Swiss) Certificate Authority (QuoVadis) for its certificates. 2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. It also includes any software that runs on platforms that have patches distributed over TLS. That is nearly everything. It's no more difficult to insert malicious code into web apps than it is to insert it into mobile phone apps, desktop apps, or operating system patches when working with a compromised trusted TLS connection. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. There are devices out there with trusted hardware and embedded keys and some groups are starting to make use of proper TPMs. But, high quality trusted platforms are beyond the reach of most consumers and developers. I know of no platform that would catch the insertion of malicious code by a determined third party with the ability compromise a TLS session in the release and/or development cycle. If webapps are faulted and everyone is using a webapp (github) to develop, well then, everyone is essentially equally compromised. The same goes for distributing updates or public keys for validation of code signatures. 3. The company did, in the early days, see Lavabit as a inspiration. But, our systems are very different. Our systems are "can't read your mail" not "promise not to read your mail". Proton has no need to avert its eyes. There is no "plaintext in and plaintext out". There is no transmission of the private key decryption passwords back to the server. I don't think your comparison holds. The way Proton works is that the encryption is done in the browser. A non-encrypted private key is not stored, or ever sent to, the Proton servers. An openPGP keypair is generated in the browser by the user. The public key is sent to servers and stored in a database. The private key is encrypted in the client's browser, with a passphrase the client enters, using the opensource openpgpjs library. That encrypted (with a password that is never sent back to the Proton servers) private key is sent to the Proton servers and stored in a database. When a user logs in, their encrypted openPGP key is sent down to their browser with their public key encrypted e-mail. Their web browser then decrypts their private key and uses it to decrypt their email on the local computer. We never have to avert our eyes from their passphrase because it never transverses our systems. The decryption is done locally. Obviously, it would be better for us not to store the private key (even though it's strongly encrypted). But, that's just not practical for a webmail application. So, I'm sure everyone is wondering: What would a TLS based ProtonMail compromise look like? Well, modified code (nefarious javascript) would be injected into the TLS stream that would send the user's decrypted private key and/or private key pass phrase to a third party or otherwise expose it (as invalid packets, etc) in the stream. Or, carefully selected cryptographic primitives would be inserted into the software. I contend that these are the same vulnerabilities someone faces downloading GnuPG from it's distribution sites, downloading Firefox/Chrome/IE, or even applying Windows/Linux updates. And, I'm also sure people are wondering: What would a US Government compromise of the ProtonMail servers look like? Well, I'll leave the details out on how the US Government might get their hands on Swiss domiciled servers... maybe something like the time they cut through a datacenter wall at MIT in the middle of the night to get the early PGP code. Let's just assume they have the servers. They'd first have to break the disk encryption. Once they broke the disk encryption, they'd have to break into the database. Once they did that, they'd basically have a bunch of AES encrypted keys that they'd have to run password guessing attacks on. ProtonMail is trying to bring cryptography to the general population to protect the basic human right of privacy. We are doing webmail the best possible way webmail can be done because webmail is the primary method of communicating for the vast majority of people today. We are not going to get our grandmas to sit in Faraday cages and work on trusted platforms with one time pads that they exchanged at their church groups and yoga classes. There is no security through obscurity in what we're doing. Honestly, I'd be honored if you took a look. We use Signal internally. I've read through the code and was very impressed. I couldn't find a single flaw that I could exploit. Perhaps, you'd even be willing to do a consulting engagement to audit us?

rbcgerard 11y ago

How (if at all) does this change if you only use their iOS/Android app to access their service?

duaneb 11y ago

So—run your own server with your own root CA?