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

Things like key pinning are why control over TLDs doesn't equate to control over Gmail, which is my point.



How is that relevant to DNSSEC? Key pinning works indepedently of how you validate your certificates (against public CAs, against DANE, or a combination of both).


I'm lost. Why are we deploying DNSSEC again? I agree that HTTPS security comes down to things like key pinning, and not to giant PKIs.


Key pinning only works for players large enough to get pins in the client software itself. I can not do that, the best I have available is trust-on-first-use, which would carry a giant usability problem for the end user.

I can set up DNSSEC and DANE today, everyone who cares gets an alternative validation path to me, and the Internet is safer because of it.


That hasn't been true for ages, and, in fact, wasn't even true when you had to had to ask Google to add pins: many of the people that had pins were tiny.

You can set up DNSSEC and DANE today, but thankfully no browser gives a shit. Key pinning, however, will not only protect you, but will also get the CA that actually coughs up a forged cert for your site locked out of Chrome and Firefox.


Ok so I'm searching trying to work out how to get the cert for my blog pinned in Chrome or Firefox so that readers of my blog can detect the NSA MITMing them even on the first visit, but I'm not finding anything.

Maybe I'm just using the wrong terms, but as far as I can see the number of sites pinned in Firefox is tiny: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... and there is no process for getting sites added to that list.

Could you give the address for the form where I can get my site pinned in Chrome?


You don't ask Chrome anymore, since Google spearheaded HPKP. Now you just use HPKP to do this.


My understanding is that HPKP can't protect you on the first visit to a site since the browser doesn't know anything about it before it connects to the site for the first time.

You explicitly replied to a post about wanting something better than"trust-on-first-use" and said key pinning solved that problem, so I assumed there was another way. I don't understand what your post was trying to say if there isn't.

Is there some way that HPKP is able to work around the first visit problem?


All of TLS is already to some extent trust-on-first-use because of SSL-stripping.

But apart from the difficulty NSA will have actually isolating your first use to intercept it, the point of HPKP is that they have to get everyone's first use, because when a browser sees a broken pin, it doesn't just go "oh, whatever, pop up an error and move on"; it also gets to freak out and report the broken pin.

With widely deployed HPKP, every hit to a site being MITM'd by someone with a compromised CA is an opportunity for that CA to be forever burned, simply because someone who already had the right cert pinned will trigger an alert.


What do you think would happen under a DNSSEC-DANE TLS world if that started being detected via the same mechanism?

There is just no way the NSA is going to risk it except in very very specific circumstances they can easily control, (exactly the same situation as HPKP) because, they too will be forever burned, except now they cant just switch to one of hundreds of other CAs, they have burned the root keys to a tld. This will be obvious, this will be screamed about from the rooftops, the key will be rotated + a ton greater scrutiny applied to the process.

Its not like browsers and other people pinning certs are just going to shrug their shoulders and say "aw shucks, i guess we wont worry about it"


Except this greatly weakens key pinning because now anyone that controls a CA cert can get you on first visit from a new browser/profile/cleared private data/device.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: