1. 21
  1.  

  2. 5

    TL;DR “browser could serve malicious code”, “you could set your password to something very weak”, “you could reuse your password” and “someone could attempt to bruteforce your password”.

    As the paper points out the smartphone app is unaffected by the browser issue. The paper even concludes that “the browser could send malicious code” is unfixable for any webmail application. You need to trust the code the server is sending atleast once.

    The recommendation in regards to the encrypted private key is a bit weird, one of the goals of PM is mass appeal, having local-device-only keys that need to be shared via QR code and can be lost degrades the experience to that of GPG (which is beyond subpar).

    I don’t think this paper really explores anything interesting in regards to things that we didn’t already know (see my TL;DR)

    1. 16

      Hello, I’m the author of this paper. This TL;DR is not fully representative of the paper. Here are some of the things it missed:

      A crucial element of the work is to compare ProtonMail’s architecture against their own stayed security goals, cited from their specification and materials. ProtonMail’s stayed security model assumes that the ProtonMail server itself is compromised and this is cited in the text. In that context, it is indeed true that the webmail application simply cannot provide end to end encryption, as, again, defined by ProtonMail themselves.

      The results hence go beyond the browser sending malicious code and also show that ProtonMail’s “encrypt-to-outside” feature (which allows sending encrypted emails to someone who uses Gmail or Outlook or whatever and allows that recipient to also send a reply) renders the sent email and the reply both decryptable not only by ProtonMail but also by the third-party mail provider (Gmail, etc.)

      The paper also shows that ProtonMail’s claims of offering zero-knowledge authentication are not actually achieved and that ProtonMail’s servers retain a password oracle for the user.

      The findings in the paper were not meant to be “anything new” as much as they are meant to be the first formal analysis of what ProtonMail is actually achieving with regards to its stated security goals. The fact that no such analysis previously existed was what motivated this work.

      1. 3

        While I agree that PM probably overpromises a bit, it’s still not entirely new knowledge that the webbrowser has to trust the server at some point. Any webapp is vulnerable to this so I don’t find it very interesting or notable. There is the Bridge and the Phone Client which both avoid this issue.

        I’m not sure on what they promise on the symmetric feature, I’ve been using the PGP mode since it’s been released, so outgoing mail uses PGP instead of the symmetric mode if possible and signs all mail.

        I’m not sure how one would solve the password oracle problem in this case, since you have to somehow encrypt the PGP key unless you want to degrade usability.

        1. 1

          ProtonMail’s “encrypt-to-outside” feature (which allows sending encrypted emails to someone who uses Gmail or Outlook or whatever and allows that recipient to also send a reply) renders the sent email and the reply both decryptable not only by ProtonMail but also by the third-party mail provider (Gmail, etc.)

          Fortunately it’s possible to attach the recipient PGP key in ProtonMail and use proper OpenPGP encryption (and soon enough discover the external key automatically). I consider the “encrypt-to-outside” feature with PSK as a lowest common denominator solution, it works with everything but is fundamentally flawed.

      2. 3

        Great work, nadim! I warned people about them in the past. Hell, web mail in general since it’s definitely not secure against nation states due to its dependencies. Reminded me maybe I hadn’t submitted a post on principles for developing TLA-resistant email, esp against domestic TLA’s. Submitted that here.

        I’ll add some of my thinking was loosely based on NIPSOM Industrial Security Manual that gave me a start on security-focused, project management. It’s what DOD used to guide a baseline for black programs (SAP’s) with specialists filling in blanks for each activity. It seemed a little more thorough than the CISSP books. ;)