Certificate Authority change at HN from Comodo to Entrust. No warning?
I pin my TLS certificates with the excellent Certificate Patrol browser plugin because otherwise it is just not safe. I just noticed that the certificate of HN changed from Comodo to Entrust, but saw no prior warning. I don't expect it to be a hack, but can someone confirm?
(obviously I would have a problem trusting information posted back here as I'm questioning the potential veracity of the whole domain, but I'm willing to take the bet that I'm not really that interesting to mess around with)
9 comments
[ 0.45 ms ] story [ 38.1 ms ] threadSSLshopper has a neat little certificate chain checker:
http://www.sslshopper.com/ssl-checker.html#hostname=news.yco...
Surely, moving to another service provider is fully legit. However, a hijack with a rogue certificate (say from an undiscovered Diginotar) would not be visible to users - thereby exposing their credentials. So people use TOFU (trust on first use) mechanisms like Certificate Patrol:
http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/present...
The future is of course DANE with DNSSEC, where you put information about the certificate and/or the CA in the DNS.
http://tools.ietf.org/html/rfc6698
I agree that it would make things more secure if it were a best practise. However, it is currently not. Nobody actually does it, and I think you'd be fighting an unwinnable uphill battle to change this.
If you're going to fight this, you might as well deprecate the CA system as best practice while you're at it. Does this sound unlikely? The same problem applies to asking websites to publish a suitable warning.
And how would you securely broadcast such a warning, anyway?
If you're not looking at the whole chain, you're ripe for MITM, particularly with the cruft in default root certificate distributions as well as ongoing changes in entity alliances -- whether free or coerced.
this is just not true
"Browsers trust a very large number of these CAs, and unfortunately, the security of HTTPS is only as strong as the practices of the least trustworthy/competent CA. Before publishing this data, we attempted to notify administrators of all sites observed vulnerable to the Debian weak key bug; please let us know if your analysis reveals other classes of vulnerabilities so that we can notify affected parties."