3 ms·
You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to
by Kadin 10y ago
You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency.
(And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
- tptacek 10y agoHPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
- agwa 10y agoThe end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.