1. 22

  2. 8

    I am a bit worried after reading the replies from “Admin”: https://protonmail.com/blog/protonmail-open-source/#comment-8926

    “The security risks of open sourcing the back-end code is too high. It would let an attacker know how our infrastructure is set up or let spammers get insight into how to circumvent our anti-spam measures.”

    “Because of spam issues, it is not secure to open source the backend code. Open sourcing the backend also does not increase trust because the software runs on our servers.”

    1. 9

      The thing is, “spam filters rely quite heavily on security through obscurity”. That’s from Mike Hearn who worked on Gmail: https://moderncrypto.org/mail-archive/messaging/2014/000780.html

      Sadly we don’t yet have a spam filter that is secure to open source. It is harsh to criticize ProtonMail on this point.

      1. 2

        Fair enough, regarding the configuration of the spam filter. Mike Hearn’s mail is an amazing read by the way, thanks for that!

        But it seems they argue that they cannot release the server code because of the (specific) spam filter/infrastructure configuration, “It would let an attacker know how our infrastructure is set up”.

        Releasing the code is not the same as making the spam filter data set on which the spam score is based (assuming that is part of how ProtonMail anti spam works), or what IP address server X and Y have, how many backend servers there are etc., publicly available, nor would anyone ask for that.

        1. 2

          If Protonmail’s spam filter is so tightly coupled to “the back-end code” as to prevent opening the parts that handle encryption, well, that’s just as scary IMO.

          1. 1

            Sadly we don’t yet have a spam filter that is secure to open source.

            That doesn’t mean spam filters must rely on security through obscurity. Truth is people could write an open source version that worked really well, but for some reason (lack of time/interest/$) they haven’t yet. Reason is: if a human can identify spam quickly, a machine can too. Today’s OSS spam filters use the wrong techniques, and that’s why they’re terrible. Would love to see an OSS spam filter using modern AI techniques.

            1. 3

              That’s why I said “don’t”. We probably can, but we don’t at the moment. And this is not the problem ProtonMail is trying to solve. Note that even Gmail, which uses modern AI techniques, does rely on security through obscurity.

              My point is, “Because of spam issues, it is not secure to open source the backend code” is not a strange statement. It is probably a statement of the fact without anything fishy about it.

        2. 4

          The hard core security peeps that I know get raised eyebrows when I tell them about ProtonMail. They find the idea of doing in browser encryption using Javascript highly suspect.

          I need to needle more details out of them as to precisely what their issues are.

            1. 1

              I guess a browser plugin is the best bet for doing an end-to-end encrypted web mail? Although I’m not sure how much one can trust something like Chrome extensions…

            2. 1

              My (very) uneducated guess would be that it all eventually relies on SSL with each new connection, and if any link in the SSL chain of certificates is breached, then a person in the middle would have access to everything.

              Although that’s true of anything acquired through one’s browser.

              1. 1

                You can implement public-private key encryption within the page, giving the public key to them and you keep the private key locally. Any mail sent to your address is instantly encrypted with the key and only you, the private key holder can decrypt. It doesn’t matter if a mitm happens and takes a copy of the public key.

                At least that’s how I think it works. Typing from a phone is not easy to keep train of thought, ugh.

                1. 1

                  As far as I know, if I can pretend to be you, I can see what you can see. Evil Eve in the middle can pretend to be you, you need but to receive a fake page that’s good enough to seem legit. Any keys you have for decryption, javascript / the browser would need normally to decrypt, and if the attacker can insert malicious JS, they can simply send it on over to themselves.

                  Also, from the very little I know, public/private keys work both ways so as to both let a person encrypt something with their private key and have it be verifiably theirs, and let them decrypt the messages that they receive encrypted with their public key. So it doesn’t matter which is which, the little I know about this tells me that public and private are but words we attach to keys, one we like to keep secret, the other spread out as far as possible.

                  If I’m wrong, would somebody please correct me?

                  1. 3

                    You are right, ProtonMail won’t protect you from an HTTPS MITM or a breach of their servers, though I think they might do better than some others thanks to HPKP (if they implement it). Not enough though. This is fundamental to all centralized “solutions”.

                    1. 1

                      The method I’m talking about could use HTTP even. The text is all coming to you encrypted via public key.

                      Someone with a public key cannot decrypt a message.

                      If this isn’t how it’s done…maybe I’m onto a business idea, although I can’t imagine being the first to think of this (this is the ENTIRE raison-etre for GPG.).

                      1. 1

                        You are indeed right in saying that if the message is encrypted with the public key, then you cannot decrypt it with the public key, you can only decrypt it with the private key.

                        However, the problem isn’t with the fact that GPG/PGP is broken, it isn’t. Both they, and their systems, work very adequately. The problem is with the fact that ProtonMail cannot send everything encrypted. The one, very crucial, thing that has to be sent first is the JavaScript code that manages the encryption and decryption. The problem with sending it over HTTP, or with somebody cracking the HTTPS, is that anybody in the middle could easily hijack that code to do whatever they wanted it to do. They could make it send any keys and password that the user has to anyone, anywhere (themselves, their friends, to Twitter, etc). HTTPS prevents that by wrapping it up in lots of “trust me, these people are who they say they are, and nobody’s managed to crack their certificate, the person from who they requested their certificate from, and so on up the chain”.

                        The crucial difference between tools such as GPG and ProtonMail is that ProtonMail would load this javascript code with every page load! This means that if you check your email this morning, then close the tab, then open ProtonMail again, you’ve downloaded the code twice already. Check your email twice a day for a month, and you’ve downloaded it 60 times, each of which is considered to be a safe connection due to only one thing prevent people in the middle from tampering, HTTPS. GPG, on the other hand, revolves around the idea that you download it safely once, you only provide one chance for the attacker to hijack you (which you, of course try, to minimize using HTTPS, etc), and then you have it downloaded offline for use multiple times. For updates, you can now use your most likely secure GPG installation to make sure that the new file is indeed being sent by the right people, of course, this is assuming that nobody’s given you a fake public key for the creators of GPG and that they haven’t been hijacked, but this is far less of a chance of hijacking than sitting in a coffee shop and checking your email with ProtonMail. Even if you would save the javascript locally from the first time it was downloaded, you still end up needing to send javascript telling the browser to use that saved version, which could be intercepted and simply disable/removed.

                        Basically, broken HTTPS, or equivalently simply using HTTP, means that if I’m in the middle of your connection, I can always pretend to be ProtonMail from your point of view, and you from ProtonMail’s point of view, and nobody will find out.

                        Also, with regards to public-private key encryption, as far as I know you can encrypt and decrypt both ways, it just serves different purposes. You can encrypt with the public key, and decrypt with the private keys, which is called encryption. This makes sure that only the person with the private key can decrypt. You can encrypt with the private key, and decrypt with the public key. This, in effect, is pretty much what signing is. Other people, who have access to the public key, can decrypt what has been sent encrypted with the private key so as to make sure that it was you who wrote it. When combined, it can be used to make sure that a message only came from person A and was sent to person B.

                        At least, I think that’s how it works.

                        I also recommend a glance at the links that tedu commented, and the ProtonMail specific links commented by itistoday. They say stuff I said and a lot more, but also much better.

              2. 1

                Awesome! I’ve had a protonmail account from the start as a second account to my posteo one.