5 ms·

Device to device. As you are aware, doing this in a browser in a manner that is not begging for failure is next to impossible.

by evgen 10y ago

Omnipresent 10y ago
Could you elaborate on why applying signal protocal in a browser is next to impossible?
- remy_ 10y ago
  Because if you serve the library responsible for the encryption from the server, an attacker can perform a man in the middle attack and change that library. This will change when browsers will start implementing the web crypto api. https://www.w3.org/TR/WebCryptoAPI/ https://www.w3.org/TR/WebCryptoAPI/
  - eganist 10y ago
    The concern is less MITM and more a compromise of the server, but close enough. Check my parallel response to Omnipresent's comment.
    - remy_ 10y ago
      Fair enough, whatever is the easiest for the attacker :). I'm checking Cyph and its "Trust On First Use" concept. Very interesting.
      - eganist 10y ago
        If you're dropping by defcon, you should catch the talk. There'll be very little focus on this mechanism specifically since we want to share a bunch of things people can actually freely use (and this isn't one of them), but you can catch Ryan afterwards and spark a conversation to find out more.
- eganist 10y ago
  Well, the keywords there are next to. Like @remy_ implied, you need a mechanism for guaranteeing that the logic you're executing in-browser is protected from server compromise. That's where the Cyph example came in, since as far as I can tell, Cyph is the team to have hacked together a solution to that dilemma, though Cyph also is not using the Signal Protocol right now. Anyway, there's an upcoming defcon talk which'll lightly touch on how web standards were mangled and viciously abused to make that happen, but since the talk is deliberately not vendor-specific, the focus on it will be brief. Disclaimer on my end is that I was involved in the initial review of their code-signing implementation. https://www.defcon.org/html/defcon-24/dc-24-speakers.html#Zadegan https://www.defcon.org/html/defcon-24/dc-24-speakers.html#Za...
  - DenisM 10y ago
    What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary? This always s gets brought up when discussing in-browser crypto and could never get a satisfactory answer.
    - remy_ 10y ago
      Because the binary is served from a marketplace that works with an app that you trust and that will verify the package signature. Or, the web browser does not behave like a package manager.
      - aurelianito 10y ago
        So it would need a browser plug-in instead of just a web page? That seems fair enough. Extra kudos if they manage to use a standard plug-in for several websites. Maybe we can even get some kind of standard for this.
    - eganist 10y ago
      For one, device-native binaries have to be signed in order to actually run on the phone (well, without introducing some other tweak such as explicitly permitting unsigned applications). Implementing this with JS is far, far, far more difficult, and the only solution known (touched on in my other comments) still pisses people off because it's running in a web context that, if improperly mitigated, can still facilitate disruption via code injection i.e. XSS. That said, we're all conveniently ignoring the fact that all of this assumes that the devices themselves haven't been owned. If you think you're a target of entities capable of getting into a fully patched phone, you've got bigger problems.
eganist 10y ago
I made the comparison to Cyph for a reason. Every time Cyph comes up, there's some amount of lively debate about whether they've actually got working in-browser code signing (which they filed a patent on). I'd argue they do, but I'm also one of the guys who reviewed the implementation.
- matheweis 10y ago
  Even if they have been able to successfully get in-browser code signing working, how can they possibly gaurantee no leakage of data? I mean, there are so many inroads, from mitm to rogue browser plugins... It seems (near) impossible to secure them all.
  - eganist 10y ago
    Rogue browser plugins can be discounted as that's tantamount to a compromised device in the context of a downloaded E2EE app. MITM, well it's E2EE with trust-on-first-use for the crypto logic and implements the works when it comes to web security protocols, such as HPKP. There's enough mitigation there. TOFU in this context would mean once you visit once, the logic that's pinned in the browser then performs signature validation on crypto logic from then on. No one's gonna get it perfectly right. Signal's probably the closest in terms of the cleanness of the protocol. It'd be neat to see Cyph implement the Signal Protocol in-browser as well, but that's neither here nor there. Ultimately, all of this will shift an attacker's focus away from owning the messaging application (or any component of it, be it the servers, the connection, etc.) to owning the devices and the users directly. Your next technical battles will be in device security and user-friendly secure authentication. Your existing wars against your users (think phishing) will continue to heat up.
    - tptacek 10y ago
      This is a weird response. The comment you replied to suggested (very accurately) that there are lots of different ways that browsers leak information, and gave the example of rogue plugins. You (accurately) dismiss rogue plugins, and then go on to write as if that were the only, or even the most important, vector for leaks. But, obviously, no. Can you cite some other ways browsers leak information besides browser plugins? It's you who are making the extraordinary claim, that Cyph has come up with a way to make browser crypto reliably secure. I think the onus should be on you to demonstrate how carefully you've thought this out. I'll make you a deal: if you name all the ones I know about, I'll tell you so. :)

Device to device. As you are aware, doing this in a browser in a manner that is not begging for failure is next to impossible.

by evgen 10y ago

Device to device. As you are aware, doing this in a browser in a manner that is not begging for failure is next to impossible.

Omnipresent 10y ago

Could you elaborate on why applying signal protocal in a browser is next to impossible?

remy_ 10y ago
Because if you serve the library responsible for the encryption from the server, an attacker can perform a man in the middle attack and change that library. This will change when browsers will start implementing the web crypto api. https://www.w3.org/TR/WebCryptoAPI/ https://www.w3.org/TR/WebCryptoAPI/
- eganist 10y ago
  The concern is less MITM and more a compromise of the server, but close enough. Check my parallel response to Omnipresent's comment.
  - remy_ 10y ago
    Fair enough, whatever is the easiest for the attacker :). I'm checking Cyph and its "Trust On First Use" concept. Very interesting.
    - eganist 10y ago
      If you're dropping by defcon, you should catch the talk. There'll be very little focus on this mechanism specifically since we want to share a bunch of things people can actually freely use (and this isn't one of them), but you can catch Ryan afterwards and spark a conversation to find out more.
eganist 10y ago
Well, the keywords there are next to. Like @remy_ implied, you need a mechanism for guaranteeing that the logic you're executing in-browser is protected from server compromise. That's where the Cyph example came in, since as far as I can tell, Cyph is the team to have hacked together a solution to that dilemma, though Cyph also is not using the Signal Protocol right now. Anyway, there's an upcoming defcon talk which'll lightly touch on how web standards were mangled and viciously abused to make that happen, but since the talk is deliberately not vendor-specific, the focus on it will be brief. Disclaimer on my end is that I was involved in the initial review of their code-signing implementation. https://www.defcon.org/html/defcon-24/dc-24-speakers.html#Zadegan https://www.defcon.org/html/defcon-24/dc-24-speakers.html#Za...
- DenisM 10y ago
  What is the difference between compromising a web server that serves js library vs the one that serves device-native app binary? This always s gets brought up when discussing in-browser crypto and could never get a satisfactory answer.
  - remy_ 10y ago
    Because the binary is served from a marketplace that works with an app that you trust and that will verify the package signature. Or, the web browser does not behave like a package manager.
    - aurelianito 10y ago
      So it would need a browser plug-in instead of just a web page? That seems fair enough. Extra kudos if they manage to use a standard plug-in for several websites. Maybe we can even get some kind of standard for this.
  - eganist 10y ago
    For one, device-native binaries have to be signed in order to actually run on the phone (well, without introducing some other tweak such as explicitly permitting unsigned applications). Implementing this with JS is far, far, far more difficult, and the only solution known (touched on in my other comments) still pisses people off because it's running in a web context that, if improperly mitigated, can still facilitate disruption via code injection i.e. XSS. That said, we're all conveniently ignoring the fact that all of this assumes that the devices themselves haven't been owned. If you think you're a target of entities capable of getting into a fully patched phone, you've got bigger problems.

eganist 10y ago

I made the comparison to Cyph for a reason. Every time Cyph comes up, there's some amount of lively debate about whether they've actually got working in-browser code signing (which they filed a patent on). I'd argue they do, but I'm also one of the guys who reviewed the implementation.

matheweis 10y ago
Even if they have been able to successfully get in-browser code signing working, how can they possibly gaurantee no leakage of data? I mean, there are so many inroads, from mitm to rogue browser plugins... It seems (near) impossible to secure them all.
- eganist 10y ago
  Rogue browser plugins can be discounted as that's tantamount to a compromised device in the context of a downloaded E2EE app. MITM, well it's E2EE with trust-on-first-use for the crypto logic and implements the works when it comes to web security protocols, such as HPKP. There's enough mitigation there. TOFU in this context would mean once you visit once, the logic that's pinned in the browser then performs signature validation on crypto logic from then on. No one's gonna get it perfectly right. Signal's probably the closest in terms of the cleanness of the protocol. It'd be neat to see Cyph implement the Signal Protocol in-browser as well, but that's neither here nor there. Ultimately, all of this will shift an attacker's focus away from owning the messaging application (or any component of it, be it the servers, the connection, etc.) to owning the devices and the users directly. Your next technical battles will be in device security and user-friendly secure authentication. Your existing wars against your users (think phishing) will continue to heat up.
  - tptacek 10y ago
    This is a weird response. The comment you replied to suggested (very accurately) that there are lots of different ways that browsers leak information, and gave the example of rogue plugins. You (accurately) dismiss rogue plugins, and then go on to write as if that were the only, or even the most important, vector for leaks. But, obviously, no. Can you cite some other ways browsers leak information besides browser plugins? It's you who are making the extraordinary claim, that Cyph has come up with a way to make browser crypto reliably secure. I think the onus should be on you to demonstrate how carefully you've thought this out. I'll make you a deal: if you name all the ones I know about, I'll tell you so. :)