5 ms·

4) We're using CloudFlare to redirect our naked domain to www.cyph.com. Re: the rest, assuming the user trusts that we haven't served up malicious code (which,

by buu700 12y ago

4) We're using CloudFlare to redirect our naked domain to www.cyph.com. Re: the rest, assuming the user trusts that we haven't served up malicious code (which, again, I acknowledge isn't completely trustless for now), I disagree that JS crypto is bad/useless. It definitely was bad/useless at one point in time, but with the introduction of the Web Crypto API I haven't seen a convincing argument that it's still strictly inferior to C/C++ crypto. (And, to be clear, Cyph will refuse to run in a browser without Web Crypto API support, e.g. any version of IE before 11.) I'd argue that a safe language like JavaScript running in as well-vetted a sandbox as in modern browsers has a lot of pretty favourable security properties (entire classes of exploits are impossible here, as opposed to in Pidgin/OTR whose implementation is known to be less than ideal for security[1]). 1: http://motherboard.vice.com/en_ca/read/secure-messaging-might-not-be-so-secure-otr-libpurple http://motherboard.vice.com/en_ca/read/secure-messaging-migh...

upperechelon 12y ago
4) So they can redirect all users to a non-HTTPS site. That's interesting. What youre saying is ridiculous, it's nothing to do with "completely" trustless, you're not trustworthy at all. The "we promise we wont serve malicious code" is the same securi Basically your users have to trust: -You -Your staff -Cloudflare -Google -Any computer used to design, build or login to your web app -Anyone with access to any of these computers -Every single CA in existence (including the US and Chinese government) -Anyone with resources to spoof a CA SHA-1 signature (anyone with ~$700,000 [0]) -The authors of the JS OTR library and any other code you use Do you see the problem here? There are literally millions of people in your trust chain. Libpurple sucks, but browsers are the #1 target for exploit writers, not to mention the HUGE attack surface they pose. There are just so many angles of attack for your service. Anything hosted on a shared server is not secure. The word cloud and security should not be in the same sentence. No offense, but you guys really do not seem like cryptography experts and there are so many pitfalls here that I would not recommend trying to promote this until you completely re-design everything. As far as WebCrypto.. I'm just going to leave this here: http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ [0] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html https://www.schneier.com/blog/archives/2012/10/when_will_we_...
- williamcotton 12y ago
  Oh, so an argument to authority? First off, that Matasano article was written before the Web Crypto API and is out of date. Second, Tony's article does make a good point... can you trust that the web site is going to be serving up code that won't spy on you? Well, can you trust that ANY code on any platform won't spy on you? People offer that Javascript doesn't have code-signing. Well, that's fucking bullshit. All that needs to happen is someone needs to just, sign all the checksums of the code served to the browser and publish it somewhere. You can then have a third-party site verify that the code is still what it says it is. Personally, I use this pattern internally. I run my server-side APIs on a different host than my static front-end code. My server-side API then checksums the front-end code and makes sure it is legit before proceeding in certain situations. Your arguments are weak and out of date.
  - schoen 12y ago
    I tried to submit an "Ask HN" item (motivated by this debate today) about what kinds of tools and best practices there are for doing this, but it didn't get voted onto the front page. I'm concerned about the "third-party site verify that the code is still what it says it is" if an important part of the threat model is that an attack would be deployed against only some users, not all. How can the third-party site tell if the site is attacking an individual user? How can the individual user compare the version of the web app they received with the version that the third-party server thinks is appropriate or current? I don't mean to dismiss this goal, because I really want infrastructure like this to work and become ubiquitous, I just think it might require a slightly more elaborate architecture with the addition of some kind of client-side component, if you're including the original developer in your threat model, and not just someone compromising the servers that host someone's copy of jQuery and giving everyone a backdoored copy.
    - williamcotton 12y ago
      Let's talk about targeting specific users in the scenario where you've kept your server-side API separate from your static front-end code. The compromised front-end code server would need to know that specific users host and client in order to target a specific user. Users are logging in to the server-side API. They all get the same front-end code. If a third party site tested from a variety of hosts using a variety of spoofed client information it would be very probable for it to detect code that targeted broader user fingerprints. You're right in that this wouldn't protect against targeted individuals. But neither does an executive order from the state. Web applications are an orchestration of two separate pieces of software that can work together using multi-factor authorization and signature schemes to offer a substantial amount of enhanced security when client-side crypto is properly utilized.

by buu700 12y ago

upperechelon 12y ago

4) So they can redirect all users to a non-HTTPS site. That's interesting. What youre saying is ridiculous, it's nothing to do with "completely" trustless, you're not trustworthy at all. The "we promise we wont serve malicious code" is the same securi Basically your users have to trust: -You -Your staff -Cloudflare -Google -Any computer used to design, build or login to your web app -Anyone with access to any of these computers -Every single CA in existence (including the US and Chinese government) -Anyone with resources to spoof a CA SHA-1 signature (anyone with ~$700,000 [0]) -The authors of the JS OTR library and any other code you use Do you see the problem here? There are literally millions of people in your trust chain. Libpurple sucks, but browsers are the #1 target for exploit writers, not to mention the HUGE attack surface they pose. There are just so many angles of attack for your service. Anything hosted on a shared server is not secure. The word cloud and security should not be in the same sentence. No offense, but you guys really do not seem like cryptography experts and there are so many pitfalls here that I would not recommend trying to promote this until you completely re-design everything. As far as WebCrypto.. I'm just going to leave this here: http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ [0] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html https://www.schneier.com/blog/archives/2012/10/when_will_we_...

williamcotton 12y ago
Oh, so an argument to authority? First off, that Matasano article was written before the Web Crypto API and is out of date. Second, Tony's article does make a good point... can you trust that the web site is going to be serving up code that won't spy on you? Well, can you trust that ANY code on any platform won't spy on you? People offer that Javascript doesn't have code-signing. Well, that's fucking bullshit. All that needs to happen is someone needs to just, sign all the checksums of the code served to the browser and publish it somewhere. You can then have a third-party site verify that the code is still what it says it is. Personally, I use this pattern internally. I run my server-side APIs on a different host than my static front-end code. My server-side API then checksums the front-end code and makes sure it is legit before proceeding in certain situations. Your arguments are weak and out of date.
- schoen 12y ago
  I tried to submit an "Ask HN" item (motivated by this debate today) about what kinds of tools and best practices there are for doing this, but it didn't get voted onto the front page. I'm concerned about the "third-party site verify that the code is still what it says it is" if an important part of the threat model is that an attack would be deployed against only some users, not all. How can the third-party site tell if the site is attacking an individual user? How can the individual user compare the version of the web app they received with the version that the third-party server thinks is appropriate or current? I don't mean to dismiss this goal, because I really want infrastructure like this to work and become ubiquitous, I just think it might require a slightly more elaborate architecture with the addition of some kind of client-side component, if you're including the original developer in your threat model, and not just someone compromising the servers that host someone's copy of jQuery and giving everyone a backdoored copy.
  - williamcotton 12y ago
    Let's talk about targeting specific users in the scenario where you've kept your server-side API separate from your static front-end code. The compromised front-end code server would need to know that specific users host and client in order to target a specific user. Users are logging in to the server-side API. They all get the same front-end code. If a third party site tested from a variety of hosts using a variety of spoofed client information it would be very probable for it to detect code that targeted broader user fingerprints. You're right in that this wouldn't protect against targeted individuals. But neither does an executive order from the state. Web applications are an orchestration of two separate pieces of software that can work together using multi-factor authorization and signature schemes to offer a substantial amount of enhanced security when client-side crypto is properly utilized.