3 ms·

> So you're opposed to TLS strengthening measures like certificate transparency? Because i think its pretty good for privacy. Considering that the cost of gett

by vaduz 6y ago

> So you're opposed to TLS strengthening measures like certificate transparency? Because i think its pretty good for privacy. Considering that the cost of getting CT was the removal of RFC 7469 HTTP-based PKP "dynamic pins" (aka HPKP), I am not sure if there was a net benefit to privacy - without hate or love for Google. I can't fail to notice that intent to removal was to also remove "static pins" (i.e. pins harcoded into the browser) after CT requirement for all certificates was implemented [0], Chrome started checking CT for new certificates [1] and CA Forum has limited the maximum validity of certificates issued to 39 months (2016) -> 825 days (2018) -> 398 days (2020) [2] (which means pretty much all certs from 2017 would have been reissued by now!), yet static pins for certain "favoured" organisations remain in the Chromium code [3]. That list of favoured orgs? Google, Tor project, Twitter, Dropbox, Facebook, Spideroak, Yahoo and Swehack. CT is great for transparency and tracking rogue certs - but privacy could have used a stronger model than current blind trust in the CAs (and only acting afterwards if the trust proves misplaced). [0] https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr... [1] https://chromium.googlesource.com/chromium/src/+/master/net/docs/certificate-transparency.md#Chrome-Policies https://chromium.googlesource.com/chromium/src/+/master/net/... [2] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-... [3] https://raw.githubusercontent.com/chromium/chromium/master/net/http/transport_security_state_static.json https://raw.githubusercontent.com/chromium/chromium/master/n...

bawolff 6y ago
A standard used by nobody does nothing for privacy. I also dont really see the connection - we could have both if that was desired, they solve similar problems but they don't conflict with each other. HKPK wasn't removed to make way for CT, it was removed because it did not work in practise.
- vaduz 6y ago
  The reasoning on this is a bit circular: it was "used by nobody" because Google did not use it, because it had a static pin in both Chromium-based browsers and in Mozilla [0], resulting in high success rate in tests (they note it in their blog post that very high sucess rate is reported if static pins are on, but very low if they are ignored). There is also the problem that MS and Apple never bothered to implement it. They had a chance to go forward and implement HPKP protocol in parallel with CT, they didn't. They had a chance to go with other proposals - e.g. checking the CAA records (a proposal they themselves have made in the deprecation post, especially as CA certs are also well-known and pinned), they didn't. They chose an option that works best for Google (and by extension: Facebook, Dropbox, etc), but not so much for everyone else. This means is there is no way to spot a mis-issued certificate before it has been used - and you need to trust that the specific CA that issues it both adheres to transparency (pinky promise!) and obeys CAA (also, pinky promise - LetsEncrypt got in hot water when it didn't). That is: unless you are Google or Dropbox or Twitter - then your browser will actually save you from connecting to any counterfeit site, as that is what was important for Google. End result? Privacy is enhanced if you are lucky enough to be on the list of statically pinned sites (see my parent comment, and see the Mozilla version as well), everyone else only gets more transparency, but not stronger privacy. [0] https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/StaticHPKPins.h https://hg.mozilla.org/mozilla-central/file/tip/security/man...

by vaduz 6y ago

bawolff 6y ago

A standard used by nobody does nothing for privacy. I also dont really see the connection - we could have both if that was desired, they solve similar problems but they don't conflict with each other. HKPK wasn't removed to make way for CT, it was removed because it did not work in practise.

vaduz 6y ago
The reasoning on this is a bit circular: it was "used by nobody" because Google did not use it, because it had a static pin in both Chromium-based browsers and in Mozilla [0], resulting in high success rate in tests (they note it in their blog post that very high sucess rate is reported if static pins are on, but very low if they are ignored). There is also the problem that MS and Apple never bothered to implement it. They had a chance to go forward and implement HPKP protocol in parallel with CT, they didn't. They had a chance to go with other proposals - e.g. checking the CAA records (a proposal they themselves have made in the deprecation post, especially as CA certs are also well-known and pinned), they didn't. They chose an option that works best for Google (and by extension: Facebook, Dropbox, etc), but not so much for everyone else. This means is there is no way to spot a mis-issued certificate before it has been used - and you need to trust that the specific CA that issues it both adheres to transparency (pinky promise!) and obeys CAA (also, pinky promise - LetsEncrypt got in hot water when it didn't). That is: unless you are Google or Dropbox or Twitter - then your browser will actually save you from connecting to any counterfeit site, as that is what was important for Google. End result? Privacy is enhanced if you are lucky enough to be on the list of statically pinned sites (see my parent comment, and see the Mozilla version as well), everyone else only gets more transparency, but not stronger privacy. [0] https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/StaticHPKPins.h https://hg.mozilla.org/mozilla-central/file/tip/security/man...