3 ms·

And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies. So

And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies. So what? The server can't read it back out of the client store again. The comparison to cookies is completely spurious.

lucb1e 12y ago
> The server can't read it back out of the client store again. Actually it can, by making the client connect to various subdomains with various certificates (valid or not). Like with image caches and everything else that supercookies use, something that is meant to be cached between requests is always detectable. > spurious Nice day to you, too...
- sbierwagen 12y ago
  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: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#page-20 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#...
  - lucb1e 12y ago
    > 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...

lucb1e 12y ago

> The server can't read it back out of the client store again. Actually it can, by making the client connect to various subdomains with various certificates (valid or not). Like with image caches and everything else that supercookies use, something that is meant to be cached between requests is always detectable. > spurious Nice day to you, too...

sbierwagen 12y ago
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: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#page-20 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-20#...
- lucb1e 12y ago
  > 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...