Hacker News new | past | comments | ask | show | jobs | submit login

Best next step would be to get some non-browser user of TLS to rely on TACK.



I may not be understanding it clearly but won't a non-browser app be better off simply pinning whatever certificates/public-keys etc. directly in the binary of the app?


The key idea of TACK is that it puts controls of pins in the hands of the site operators. The goal is to protect trustworthy site operators from rogue or compromised CAs (e.g. Diginotar, Comodo). The site operators have a better idea than anyone of what keys and certificates are correct for their site.

Pinning directly in the app puts trust in the developers of the app instead, which is indirect and prone to lag. It is also generally fragile (have to issue app updates for cert revocations) and can be hard to scale. How many secure sites does your app need to connect to? Is it flexible, unknown? How are you, the app developer, going to validate those certs beyond relying on the CA PKI? (and then you're back to square one).


What are these "site operators" that you speak of? If facebook or google or twitter is publishing a native app, they can embed any credentials/certs/keys etc. they want into their app. It's not a great leap to think of a cert/key renewal mechanism via DNSSSEC or some other proprietary mechanism. Essentially, it's the same as google pinning their certs in the chrome browsers. Except, since you control both end points (your app and your own servers), you don't have to participate in the broken (trust based) PKI system at all.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: