Okay, maybe not entirely spurious, but how much information can a malicious tracker actually extract using HPKP + invalid certs, and the resulting failed handshake?
1. The client is new enough that it supports HPKP
(information you get from the default UA string anyway,
but could be used to smoke out someone using a blank UA
string)
2. The client has connected to this server once before.
That's, what, one bit? A bit and a half?
You could add a new subdomain once a day, then invalidate the cert 24 hours later, to get more bits of information, but this is an attack that requires buying a new cert once a day, forever, which costs money. (StartSSL gives you one free cert, but only one) (It wouldn't cost a state sponsored attacker any money to create certs, of course...)
Is there even any way to implement PKP that wouldn't leak client information via failed handshakes? Is killing pervasive monitoring worth enabling an expensive supercookie attack?
(One dumb mitigation: ignore handshake failures due to PKP, proceed with the connection as normal, but throw away the data. You'd have to load and parse the requested page in the background, though, or else the attacker would notice that the client isn't requesting inline images/scripts...)
> EDIT: Ah, the draft mentions the supercookie attack
I didn't actually know that. Nice to see they thought of it while designing, but besides the attack scenarios I don't see anything to do about it, for users nor websites...
You could add a new subdomain once a day, then invalidate the cert 24 hours later, to get more bits of information, but this is an attack that requires buying a new cert once a day, forever, which costs money. (StartSSL gives you one free cert, but only one) (It wouldn't cost a state sponsored attacker any money to create certs, of course...)
Is there even any way to implement PKP that wouldn't leak client information via failed handshakes? Is killing pervasive monitoring worth enabling an expensive supercookie attack?
(One dumb mitigation: ignore handshake failures due to PKP, proceed with the connection as normal, but throw away the data. You'd have to load and parse the requested page in the background, though, or else the attacker would notice that the client isn't requesting inline images/scripts...)
---
EDIT: Ah, the draft mentions the supercookie attack: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#...