News for hackers. Stuff that matters.
Re:Is HTTP Public Key Pinning Dead? by eganist on Tuesday September 06, 2016 @08:31AM (#12435451)
Literally:

1) raise your hand if you've heard of CSP (more than half the room at both talks)

2) raise your hand if you've heard of HPKP (half at def con. Probably a third at black hat)

3) raise your hand if you've heard of CAA (I gave this one something like 15 seconds for people to think. The number of hands v. attendees was a rounding error.)

Re:Is HTTP Public Key Pinning Dead? by JoshTriplett on Tuesday September 06, 2016 @08:51AM (#12435558)
Next time you're testing that, you might also include Certificate Transparency.

Mandatory CT seems like it solves the same problems HPKP does, without the risk. Now if we can just finish getting to mandatory CT...

Re:Is HTTP Public Key Pinning Dead? by pfg on Tuesday September 06, 2016 @09:06AM (#12435668)
Certificate Transparency (especially if mandatory) guarantees detection after the fact (if we assume the domain owner is properly monitoring known logs). It also adds a certain chilling effect that will probably cause attackers to look for other methods of compromising the target rather than risk sacrificing one of the CAs under the attacker's control (which, arguably, is what intelligence agencies are already doing as many high-profile sites have deployed HPKP).

It's not a real-time protection mechanism for targeted attacks and such - the mis-issuance event won't be noticed immediately, and revocation is both slow and, well, broken in general.

The existence of HPKP is still a good thing for the Gmail's of this world, but I agree that mandatory CT is probably good enough for 99 out of 100 sites out there.

Re:Is HTTP Public Key Pinning Dead? by JoshTriplett on Tuesday September 06, 2016 @09:51AM (#12435964)
I can imagine extensions to CT that would make it better at combating real-time attacks before they can affect anyone.

For instance, suppose a new certificate didn't become valid for a certain amount of time after the publication of the corresponding CT log, to give the domain owner (or rather, automated processing working on their behalf) time to shoot it down somehow? You could choose how much of a delay you wanted, trading off between security and potential downtime (if you lose all access to your existing certificates, can't revoke them, and have to issue entirely new ones).

If you use any non-automated CA, you should know when renewing your certificates, so you could open up a window to renew; in the absence of that, a fully automated process could notice a new certificate for your domain and automatically shoot it down.

If you use an automated CA, you (or the automated process) should similarly know the window of time you will renew in, though in that case someone could learn that and take advantage of that window. On the other hand, given sufficient confidence in the automated CA you could use CAA with it.