7 ms·

I'd given this challenge some thought in the recent past, specifically the challenge that the big app store owners are each generally susceptible to coercion by

I'd given this challenge some thought in the recent past, specifically the challenge that the big app store owners are each generally susceptible to coercion by large nation-state actors in spite of being multinationally distributed. There was a project I was involved in rather heavily (cyph // resulted in a pair of neat conference talks) where we'd accounted for the risks of apps being banned by making the entire application operate exclusively in a web context. To at least somewhat mitigate the related risks stemming from having to trust the cryptographic logic delivered by a web server every time you use the service, trust-on-first-use was achieved by mangling the living daylights out of HPKP in tandem with service workers in order to persist barebones codesigning logic used for validating cryptographic packages delivered from the web service. Alas... All of this is to say that there have been multiple parties involved in addressing this challenge, each one thinking from novel angles in an effort to mitigate the risks posed by the threat of sanctions against secure messaging. As it stands, it appears there's now a rather glaring weakness: if a nation-state decides as much, they can just twist the arms of the walled gardens supporting your secure messaging client in order to: 1) deny access generally, reducing or eliminating the growth of the target space and improving target acquisition, 2) persist known vulnerabilities just long enough to exploit against a target. Telegram has been criticized again and again for their security hygiene and for their architectural decisions. Signal's seen some of that heat quite recently, and I raise both of these because they speak pretty strongly to the bullets above: there's a chance we're seeing a live demonstration by a preeminent world power against one of the few tools dissidents are using to literally stay alive. If this demonstration succeeds without any sort of significant blowback (in the form of corporate or popular resistance or some other subversion or mitigation of the attack), there's nothing to stop any other major party from trying it, regardless of whether they're a nation-state. --- Anyway, I'm keen on a deeper discussion here. Maybe the tinfoil hat's been a bit corrosive to my brain; counter-arguments are welcomed.

deleted 8y ago
[deleted]
lifeisstillgood 8y ago
I guess my brain is too small to grok this all in one go but are you saying that Russia is applying pressure to Apple (what pressure?) that prevents Apple App Stores in all countries from accepting a new update of Telegram I don't get this - why is Telegram not releasing updates in a UK or Japanese region? What pressure (besides the local russian court system) is being applied here --- In general yes I expect that app stores are the / a weak point in mobile encryption messaging, but it is only at the level of major player threat model. These things are good enough for use against all but a State level actor targeting you specifically (at which point leaving the country is probably good, if tardy, advice)
- JumpCrisscross 8y ago
  We don't have any evidence, apart from Durov's allegations, that Telegram's situation with Apple has anything to do with Russia.
  - lifeisstillgood 8y ago
    So this is Telegram saying "oh we forgot to update for GDPR because err ... umm ... err ... Russia!"? I mean we presumably do have Russian court Records from April, records that the Roskomnadzor went to court for encryption keys, and that there have been "shutting down entire segments of the Russian internet. Many small organizations, including language schools and museums, have been blocked as collateral damage." And evidence there was a demonstration with paper aeroplanes? I am happy to accept that Durov has an axe to grind but Russia does look like a good suspect to start looking at first.
    - JumpCrisscross 8y ago
      > So this is Telegram saying "oh we forgot to update for GDPR because err ... umm ... err ... Russia!"? There are reasonable explanations between "Telegram is directly responsible for the delay" and "Russia made Apple hold up the app worldwide." > Russia does look like a good suspect to start looking at first Start. The discussion I'm seeing treats this as a foregone conclusion. That's all I'm cautioning in respect of.
wellboy 8y ago
Skywire to the rescue. Can't wait dor it to go live.
wavefunction 8y ago
I'd be interested to see any slides or "work product" containing your conclusions if it's available and you don't mind. I'm working for a startup that has had to pivot to web-only applications specifically because of Apple and their frustrating nervousness around anything involving applied blockchains.
- j16sdiz 8y ago
  I think you can skip mentioning blockchain in the app description. If it is "applied blockchain", you don't have to tell everybody it's blockchain. App should look like natural (or, sometimes, magic) to non technical users. They couldn't care less. Just show them what your app can do.
- eganist 8y ago
  Well the basic premise was to use a security protocol to deny service locally to a domain after that domain will have loaded client-side code into the browser as a service worker. It's described with more detail near the end of the deck: https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Bryant-Zadegan-Ryan-Lester-Abusing-Bleeding-Edge-Web-Standards-For-Appsec-Glory-UPDATED.pdf https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre... -- but the practical implementation of the aforementioned is to cause local DoS by means of rapid key rotation on a domain protected by HPKP. By rotating keys (cyph.ws does this just about once every twelve hours, for instance), you can trap a service worker in the browser for up to 60 days, the length of time pins are permitted to be valid with supported browsers. I'm pretty sure we coined "HPKP suicide" for publicity's sake, but should any other ultra-footgun-prone client-side TLS-impacting security protocols emerge, this same pattern should be feasible with those as well. Local DoS was briefly described as a risk in the HPKP RFC, and we further fleshed it out and reduced it to practice as a tool for engineers to achieve the goal described in my last comment (equal credits to Ryan Lester and Jann Horn as well). The specific device we put into production (and patented because of its criticality to Cyph) worked through the use of localized denial of service to pin signature validation logic into the local store of the browser to verify payloads received from other endpoints; in our case, we pin bad keys for the maximum permitted duration. That said, there are many different ways to use HPKP suicide that don't have to do with adding signature validation for client-side application logic, and they still come fairly close to achieving the goal of reducing how often you have to trust the server. The pattern described in this paragraph allows for Cyph to deploy new builds of the full messaging application whenever by just signing new builds such that they're validated by the pinned service worker, but if that flexibility is not a necessity, keep reading. Since you can effectively pin any code into the browser through HPKP suicide, one different approach might be to pin a key for a more reasonable amount of time, such as two weeks, in order to stick e.g. critical application logic in the browser and rest assured that each user will use a certain build for at least two weeks time. This has the effect of reducing the exposure of an application's userbase in the event of a service compromise—at the expense of possibly committing some users to a bad build (or possibly even a compromised build) unless they manually clear pins. If you're writing a light application, this'll serve you pretty well. If you're writing a heavier application, you can outsource most of the heavier dependencies through SRI (the code pinned as the service worker would use SRI to validate the supporting libraries). The nuance here is that you're not implementing signature validation; you're just relying on that local DoS to ensure that certain code stays in the browser for as long as the bad keys are pinned and just confirming that any separate resources hash as what you'd expect them to. You're still certain to see that code--and any hashes you bake into it for SRI, should you choose to go this route--persist for as long as the invalid pins are live in your users' browsers. HPKP still works in Firefox, so we intend to continue to research this pattern and related implementations of it. However, considering the browser with the largest market share just deprecated it while publicly mentioning the risk of footgunning via the standard, I'm not sure how much you stand to gain by implementing anything like the pattern we fleshed out two years ago. I'd love to build support to keep/fix the protocol rather than bin it, but the team that created is the team that gave up on it. If you're curious, the private reason I've heard voiced to others by a person closely connected to the standard is that the protocol was not anticipated to be used in any manner other than what was documented, hence why termination of support for HPKP was preferred in Chrome over revision of the standard. I'm deliberately delicate with my words here because 1) it's hear-say, 2) it was expressed both off the record and in confidence to someone other than myself, and therefore 3) I can't be certain that it was expressed at all. However, key pinning--or any other TLS DoS--should always support what I described above as long as the DoS doesn't interrupt local code from executing in-browser, a behavior I doubt will change for the foreseeable future. You wouldn't want a TLS error to forcibly refresh an offline Google Docs instance just to show you said TLS error (resulting in loss of data from that offline GDocs instance), would you? TL;DR: you can research alternatives based on the general pattern we described, but using HPKP specifically might be a dead-end for you. But if you're keen on talking about it in more depth, I'm on keybase.io/bryant
mirimir 8y ago
If users could install Telegram from third-party sources, without rooting their phones, this issue wouldn't be so serious. Or if users could install from trusted friends, even. That is, if iOS apps could be shared. There's a similar issue for Android apps. But it's my understanding that it's easier, and doesn't require rooting. But of course, this would break Apple's "we are the only app source, because you can only trust us" security model. Or maybe it's "... because we can only trust us, and we don't want increased support load".
- Zak 8y ago
  Installing apps from third-party sources is trivial on most Android phones. It only requires turning on a setting that's off by default and exposed in the regular settings app.
- lysp 8y ago
  On android it's very easy. Settings, developer, "allow installation from 3rd party - on". Alternatively on my phone when I try to install an app, it'll allow me to change that setting just for that single installation and then turn it off again.
- nicky0 8y ago
  If Telegram released the source code, people could compile and install it on their own iOS devices.
  - saagarjha 8y ago
    Which they do, to some extent. They're in a weird limbo right now where they're pushing updates but not updating the publicly available source, which is something I find vaguely off-putting.
    - reitanqild 8y ago
      They also provide their own "build-your-own-Telegram-client"library, at least for Android. I never though of that before but the current situation might be a very good reason for making that library available.

deleted 8y ago

[deleted]

lifeisstillgood 8y ago

I guess my brain is too small to grok this all in one go but are you saying that Russia is applying pressure to Apple (what pressure?) that prevents Apple App Stores in all countries from accepting a new update of Telegram I don't get this - why is Telegram not releasing updates in a UK or Japanese region? What pressure (besides the local russian court system) is being applied here --- In general yes I expect that app stores are the / a weak point in mobile encryption messaging, but it is only at the level of major player threat model. These things are good enough for use against all but a State level actor targeting you specifically (at which point leaving the country is probably good, if tardy, advice)

JumpCrisscross 8y ago
We don't have any evidence, apart from Durov's allegations, that Telegram's situation with Apple has anything to do with Russia.
- lifeisstillgood 8y ago
  So this is Telegram saying "oh we forgot to update for GDPR because err ... umm ... err ... Russia!"? I mean we presumably do have Russian court Records from April, records that the Roskomnadzor went to court for encryption keys, and that there have been "shutting down entire segments of the Russian internet. Many small organizations, including language schools and museums, have been blocked as collateral damage." And evidence there was a demonstration with paper aeroplanes? I am happy to accept that Durov has an axe to grind but Russia does look like a good suspect to start looking at first.
  - JumpCrisscross 8y ago
    > So this is Telegram saying "oh we forgot to update for GDPR because err ... umm ... err ... Russia!"? There are reasonable explanations between "Telegram is directly responsible for the delay" and "Russia made Apple hold up the app worldwide." > Russia does look like a good suspect to start looking at first Start. The discussion I'm seeing treats this as a foregone conclusion. That's all I'm cautioning in respect of.

wellboy 8y ago

Skywire to the rescue. Can't wait dor it to go live.

wavefunction 8y ago

I'd be interested to see any slides or "work product" containing your conclusions if it's available and you don't mind. I'm working for a startup that has had to pivot to web-only applications specifically because of Apple and their frustrating nervousness around anything involving applied blockchains.

j16sdiz 8y ago
I think you can skip mentioning blockchain in the app description. If it is "applied blockchain", you don't have to tell everybody it's blockchain. App should look like natural (or, sometimes, magic) to non technical users. They couldn't care less. Just show them what your app can do.
eganist 8y ago
Well the basic premise was to use a security protocol to deny service locally to a domain after that domain will have loaded client-side code into the browser as a service worker. It's described with more detail near the end of the deck: https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Bryant-Zadegan-Ryan-Lester-Abusing-Bleeding-Edge-Web-Standards-For-Appsec-Glory-UPDATED.pdf https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20pre... -- but the practical implementation of the aforementioned is to cause local DoS by means of rapid key rotation on a domain protected by HPKP. By rotating keys (cyph.ws does this just about once every twelve hours, for instance), you can trap a service worker in the browser for up to 60 days, the length of time pins are permitted to be valid with supported browsers. I'm pretty sure we coined "HPKP suicide" for publicity's sake, but should any other ultra-footgun-prone client-side TLS-impacting security protocols emerge, this same pattern should be feasible with those as well. Local DoS was briefly described as a risk in the HPKP RFC, and we further fleshed it out and reduced it to practice as a tool for engineers to achieve the goal described in my last comment (equal credits to Ryan Lester and Jann Horn as well). The specific device we put into production (and patented because of its criticality to Cyph) worked through the use of localized denial of service to pin signature validation logic into the local store of the browser to verify payloads received from other endpoints; in our case, we pin bad keys for the maximum permitted duration. That said, there are many different ways to use HPKP suicide that don't have to do with adding signature validation for client-side application logic, and they still come fairly close to achieving the goal of reducing how often you have to trust the server. The pattern described in this paragraph allows for Cyph to deploy new builds of the full messaging application whenever by just signing new builds such that they're validated by the pinned service worker, but if that flexibility is not a necessity, keep reading. Since you can effectively pin any code into the browser through HPKP suicide, one different approach might be to pin a key for a more reasonable amount of time, such as two weeks, in order to stick e.g. critical application logic in the browser and rest assured that each user will use a certain build for at least two weeks time. This has the effect of reducing the exposure of an application's userbase in the event of a service compromise—at the expense of possibly committing some users to a bad build (or possibly even a compromised build) unless they manually clear pins. If you're writing a light application, this'll serve you pretty well. If you're writing a heavier application, you can outsource most of the heavier dependencies through SRI (the code pinned as the service worker would use SRI to validate the supporting libraries). The nuance here is that you're not implementing signature validation; you're just relying on that local DoS to ensure that certain code stays in the browser for as long as the bad keys are pinned and just confirming that any separate resources hash as what you'd expect them to. You're still certain to see that code--and any hashes you bake into it for SRI, should you choose to go this route--persist for as long as the invalid pins are live in your users' browsers. HPKP still works in Firefox, so we intend to continue to research this pattern and related implementations of it. However, considering the browser with the largest market share just deprecated it while publicly mentioning the risk of footgunning via the standard, I'm not sure how much you stand to gain by implementing anything like the pattern we fleshed out two years ago. I'd love to build support to keep/fix the protocol rather than bin it, but the team that created is the team that gave up on it. If you're curious, the private reason I've heard voiced to others by a person closely connected to the standard is that the protocol was not anticipated to be used in any manner other than what was documented, hence why termination of support for HPKP was preferred in Chrome over revision of the standard. I'm deliberately delicate with my words here because 1) it's hear-say, 2) it was expressed both off the record and in confidence to someone other than myself, and therefore 3) I can't be certain that it was expressed at all. However, key pinning--or any other TLS DoS--should always support what I described above as long as the DoS doesn't interrupt local code from executing in-browser, a behavior I doubt will change for the foreseeable future. You wouldn't want a TLS error to forcibly refresh an offline Google Docs instance just to show you said TLS error (resulting in loss of data from that offline GDocs instance), would you? TL;DR: you can research alternatives based on the general pattern we described, but using HPKP specifically might be a dead-end for you. But if you're keen on talking about it in more depth, I'm on keybase.io/bryant

mirimir 8y ago

If users could install Telegram from third-party sources, without rooting their phones, this issue wouldn't be so serious. Or if users could install from trusted friends, even. That is, if iOS apps could be shared. There's a similar issue for Android apps. But it's my understanding that it's easier, and doesn't require rooting. But of course, this would break Apple's "we are the only app source, because you can only trust us" security model. Or maybe it's "... because we can only trust us, and we don't want increased support load".

Zak 8y ago
Installing apps from third-party sources is trivial on most Android phones. It only requires turning on a setting that's off by default and exposed in the regular settings app.
lysp 8y ago
On android it's very easy. Settings, developer, "allow installation from 3rd party - on". Alternatively on my phone when I try to install an app, it'll allow me to change that setting just for that single installation and then turn it off again.
nicky0 8y ago
If Telegram released the source code, people could compile and install it on their own iOS devices.
- saagarjha 8y ago
  Which they do, to some extent. They're in a weird limbo right now where they're pushing updates but not updating the publicly available source, which is something I find vaguely off-putting.
  - reitanqild 8y ago
    They also provide their own "build-your-own-Telegram-client"library, at least for Android. I never though of that before but the current situation might be a very good reason for making that library available.