Hacker News Reader

Comment by Roritharr | Hacker News Reader

This is especially funny to me as our PCI DSS Network Scan just started flagging not having a HPKP Header as something thats necessary to remediate. I've had to waste half a day on the phone and then to write a Risk Mitigation Plan that explains how we mitigate the risk of an MITM Attack in case our CA gets breached...

View on HN

It is deeply fucked up if a scanning checklist demands PKP, since most sites --- including most commerce sites --- shouldn't pin.

Well, try explaining that to the HSTS and HPKP folks. They already have answers littered on stack overflow and HN to advise to enable it for anything and everything. With exactly zero consideration for the potential to backfire.

It's only a matter of time before an intern or an audit guy have it deployed on majorcompany.com and result in a disaster. Symptom includes none of the client ever able to access the site again.

Last year I was contracting at an NGO where somebody decided to add our domain to an HSTS preload list. This worked great for the public facing site, which was already served over HTTPS, but we also had a load of internal apps on the same domain.

They were only accessible from our network (ethernet or VPN), so we hadn’t bothered with HTTPS before. Oh and we only found out about the issue when Chrome updated and everything broke - it was a fun few days!

HSTS should never result in "none of the client ever able to access the site again".

HPKP can, if you pin a key and then lose the key you pinned.

I know. But you shouldn't lump the dangerousness of HPKP on HSTS.

Also with HPKP you shouldn't just pin one key. You should pin several keys you own as well as several root and intermediate keys. But I agree it's very difficult to do right and there's still a risk of it failing.

does HSTS have potential to backfire?

Unless you're a static content site that is using TLS just to be an Internet Good Citizen to prevent passive traffic analysis, you absolutely should have HSTS enabled; it's not really a judgement call. Without HSTS, you almost might as well not do TLS at all; HSTS prevents a serious, effective, and easy attack.

By way of comparison, it has never been a good idea to default to HPKP. Privacy-sensitive sites should be pinned, and if you can't safely manage pinning, that's a pretty good sign that you're not mature enough to engineer privacy for the site either, so I don't have that much sympathy for the argument that it's a foot cannon (this is, of course, very easy for me to say). But if you're just selling coffee beans or scheduling laundry pickups, PKP has always been a very bad idea for you.

Why does being a static content site mean you should not enable HSTS? If anything, HSTS is easiest to roll out for static content sites.

One primary example would be sites like software repository mirrors, where the majority of content is signed already, and serving them over HTTPS provides negligible benefit to your users (other than the slight confidentiality increase in that an adversary wouldn't know what exactly you downloaded), as opposed to a site serving active content like JavaScript and CSS, which can have disastrous results to the users if an adversary tampers with them.

The latter example is where HSTS becomes an invaluable tool, since now the only way those resources could be delivered is through a trusted channel, verified by the PKI. The same value is not there for a software mirror, because of the other security safeguards already implemented, removing the need to trust the delivery channel. That said, most still do server their content over HTTPS as well.

The browser will completely block access to the site on any certificate issue. In practical terms, HSTS removes the "ignore certificate error" button that everyone got used to click.

It will backfire when the certificate expires, when some clients don't recognize the CA chain, when domains or subdomains don't match the certificate.

Are you using Qualys? It seems they are having major issues with header checks starting around Oct 1st. Tenable however still passes sites without HPKP. Getting our vendors, like fortinet, to implement all the security headers Qualys now demands will be impossible so we are checking other ASV's to see how they respond to our sites. Just for jollies you should go check pci.qualys.com's security headers.

https://twitter.com/eganist/status/920399513638133761

Glad there are more reports of this showing up.

... isn't the risk that HPKP mitigates the risk of a MITM attack in case some other CA gets breached?

HPKP also protects against your CA if you pin the direct private keys your servers use, but I bet it also is quite annoying to come up with a good plan for how you are not going to loose/delete all the private keys you have pinned...

Right. I'm curious which approach the auditors wanted - either one would be a weird thing to mandate!

In theory, pinning your servers' private keys is actually kind of reasonable, if you generate like two or three sets of backup private keys and put them in off-site storage. And I've long been an advocate of buying at least one backup certificate from another CA just in case your current one gets distrusted.

(And it makes sense from a technical perspective why HPKP supports both of these approaches, but the ambiguity probably didn't help it from a policy perspective).

Reply on news.ycombinator.com