4 ms·

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

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.
  - schoen 12y ago
    In this threat model it seems unreasonable to me to rely on a particular front-end/back-end separation architecture as a main thing that protects users. If the two are not separated this way, or the back-end can cause redirects or can inject Javascript at all, the users won't be protected. I like the "test from a variety of hosts" approach better, and I wonder what kinds of tools exist or will exist that will facilitate this -- and whether some web app developers are willing to commit that their architectures will support it (that the front-end code doesn't do an eval, that the front-end actually architecturally treats the back-end as untrusted, and that users can expect to get consistent page contents every time they visit the service, even with a different user-agent or from a different netblock). I'm not trying to make fun; I want to see this happen. It seems like a big change from existing practice!
    - williamcotton 12y ago
      The front-end/back-end separation architecture that I'm referring to is used for internal systems checksums. We're using it to make sure that the front-end code is still what we think it is... the main threat model it protects against is a front-end developer on the team having their machine compromised and an attacker deploying front-end code that wasn't signed by someone with access to the back-end code. What I like the most about browser security is that it tackles this stuff head-on. There is no more thoroughly tested environment that runs untrusted third-party code. Code signing, checksums, signed software updates... all of these are most definitely issues on every other platform. They're the most difficult to protect against on the web which makes the web the best place to try and figure them out. I'd really like to see a few additions to the Web Crypto API. Some sort of key management mechanism would be wonderful. And of course some sort of native mechanism to deal with signed code and checksums. As well as getting FIDO U2F standardized.

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.
- schoen 12y ago
  In this threat model it seems unreasonable to me to rely on a particular front-end/back-end separation architecture as a main thing that protects users. If the two are not separated this way, or the back-end can cause redirects or can inject Javascript at all, the users won't be protected. I like the "test from a variety of hosts" approach better, and I wonder what kinds of tools exist or will exist that will facilitate this -- and whether some web app developers are willing to commit that their architectures will support it (that the front-end code doesn't do an eval, that the front-end actually architecturally treats the back-end as untrusted, and that users can expect to get consistent page contents every time they visit the service, even with a different user-agent or from a different netblock). I'm not trying to make fun; I want to see this happen. It seems like a big change from existing practice!
  - williamcotton 12y ago
    The front-end/back-end separation architecture that I'm referring to is used for internal systems checksums. We're using it to make sure that the front-end code is still what we think it is... the main threat model it protects against is a front-end developer on the team having their machine compromised and an attacker deploying front-end code that wasn't signed by someone with access to the back-end code. What I like the most about browser security is that it tackles this stuff head-on. There is no more thoroughly tested environment that runs untrusted third-party code. Code signing, checksums, signed software updates... all of these are most definitely issues on every other platform. They're the most difficult to protect against on the web which makes the web the best place to try and figure them out. I'd really like to see a few additions to the Web Crypto API. Some sort of key management mechanism would be wonderful. And of course some sort of native mechanism to deal with signed code and checksums. As well as getting FIDO U2F standardized.