4 ms·

This all seems to be a web-based application (https://github.com/ProtonMail/WebClient https://github.com/ProtonMail/WebClient). How are the security issues reg

This all seems to be a web-based application (https://github.com/ProtonMail/WebClient https://github.com/ProtonMail/WebClient). How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? The arguments against server-supplied, js-in-the-browser crypto have been done to death. Why is this any different, and why am I wrong to dismiss it out-of-hand as (in)secure as simply sending unencrypted data to the server? Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server). > we choose our own primes rather than those used by TLS Does TLS specify any primes? You can use your own DH primes, SRP primes, and your key is your own prime. Those RFCs recommend primes, but allow the server to use different ones. TLS, SRP, or DH doesn't "use" a single prime, any prime satisfying the requirements in the RFC is acceptable. know it's nitpicking but something about how it was said rubbed me the wrong way. I would love to know how they communicate between their TLS-SRP layer and their authentication layer. Most implementations are file-based. Did they write a plugin for gnutls or openssl? Did they write their own TLS layer? I would love for TLS-SRP to be more wide-spread, but this is always the biggest hurdle to adoption in my case.

ComodoHacker 10y ago
>Why is this any different Nobody says it's different >Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server). OK, let's suppose you're using a native app. One day vendor issues an update with some critical vulnerability patched. Unfortunately, another vulnerability (or even backdoor) sneaks into this update for whatever reasons. How is this any different?
- icebraining 10y ago
  An update to the native app must be the same for everyone, and being open source, the chances that someone will find out about it are much greater. In a web app, they can send a backdoored copy of the code just to you and just a single time, which is much harder to detect.
- jimktrains2 10y ago
  > Nobody says it's different They why do all the extra work for no gain in security? I think the sibling comment address your next comment well.
  - bartbutler 10y ago
    There's a difference between an active attacker and a passive MITM attacker. Doing this for the web app in addition to the native apps helps prevent a passive MITM attack from stealing login credentials.
    - jimktrains2 10y ago
      A mitm is an active attacker. If TLS fails, then the mitm could modify the code sent to the end user.
      - bartbutler 10y ago
        That's a limited definition of MITM. That would be an active attack, and yes, this does nothing for that for the web app--the native apps are a different story. However, there are plenty of corporate PCs and other machines with root certs installed in a way that a third party could, and often does, passively record traffic without modification for analysis later. SRP prevents those dumps from containing information that can be used to compromise an account.
        jimktrains2 10y ago
        That is exactly what I'm describing though. The corporation could edit the page to do what they want. To claim otherwise is foolish and really makes me question proton's understanding of security.
SquareWheel 10y ago
>How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? A unique solution might be to use service workers to handle content "updates". The assets could be cached locally, and a single network request could be fired to check for updates. If one exists, the user is prompted to update. This would at least alert you to review the code being sent to your browser if you're so inclined. Ultimately though it comes down to yet another tradeoff of security vs convenience. Such a feature might be better off as an opt-in extra security feature.
bartbutler 10y ago
Sorry for any confusion. We don't use TLS-SRP, we use certificate TLS, and SRP on top of it. The short discussion on TLS-SRP was trying to address any potential questions about different choices we made with respect to TLS-SRP.
bartbutler 10y ago
Also, yes, the application is web-based, but we also have native mobile clients which use the same API, and are working on two more native options for desktop.

ComodoHacker 10y ago

>Why is this any different Nobody says it's different >Why isn't this only an open-source, native app (where I can load a specific, known version instead of whatever is on the server). OK, let's suppose you're using a native app. One day vendor issues an update with some critical vulnerability patched. Unfortunately, another vulnerability (or even backdoor) sneaks into this update for whatever reasons. How is this any different?

icebraining 10y ago
An update to the native app must be the same for everyone, and being open source, the chances that someone will find out about it are much greater. In a web app, they can send a backdoored copy of the code just to you and just a single time, which is much harder to detect.
jimktrains2 10y ago
> Nobody says it's different They why do all the extra work for no gain in security? I think the sibling comment address your next comment well.
- bartbutler 10y ago
  There's a difference between an active attacker and a passive MITM attacker. Doing this for the web app in addition to the native apps helps prevent a passive MITM attack from stealing login credentials.
  - jimktrains2 10y ago
    A mitm is an active attacker. If TLS fails, then the mitm could modify the code sent to the end user.
    - bartbutler 10y ago
      That's a limited definition of MITM. That would be an active attack, and yes, this does nothing for that for the web app--the native apps are a different story. However, there are plenty of corporate PCs and other machines with root certs installed in a way that a third party could, and often does, passively record traffic without modification for analysis later. SRP prevents those dumps from containing information that can be used to compromise an account.
      - jimktrains2 10y ago
        That is exactly what I'm describing though. The corporation could edit the page to do what they want. To claim otherwise is foolish and really makes me question proton's understanding of security.

SquareWheel 10y ago

>How are the security issues regarding knowing that you're always running that code and that the server isn't compromised and sending altered code? A unique solution might be to use service workers to handle content "updates". The assets could be cached locally, and a single network request could be fired to check for updates. If one exists, the user is prompted to update. This would at least alert you to review the code being sent to your browser if you're so inclined. Ultimately though it comes down to yet another tradeoff of security vs convenience. Such a feature might be better off as an opt-in extra security feature.

bartbutler 10y ago

Sorry for any confusion. We don't use TLS-SRP, we use certificate TLS, and SRP on top of it. The short discussion on TLS-SRP was trying to address any potential questions about different choices we made with respect to TLS-SRP.

bartbutler 10y ago

Also, yes, the application is web-based, but we also have native mobile clients which use the same API, and are working on two more native options for desktop.