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)
3 comments
Why would there have to be a prior warning? Certificates are re-issued all the time and sometimes a customer decides to move their business to a new provider.
SSLshopper has a neat little certificate chain checker:
http://www.sslshopper.com/ssl-checker.html#hostname=news.yco...
SSLshopper has a neat little certificate chain checker:
http://www.sslshopper.com/ssl-checker.html#hostname=news.yco...
I think it is a best practise.
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
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 think it is a best practise.
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?
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?
I do it, for sites that particularly concern me. For example, it's been... interesting, to watch the ongoing changes in Google's cert chains. And when, many months ago, I commented on these, I received a number of silent (no comment) upvotes.
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.
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.
[deleted]
> because otherwise it is just not safe
this is just not true
this is just not true
https://www.eff.org/observatory
"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."
"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."
People from Iran would disagree. Something should also be said about problems of CAs security.
Cloudflare. On and off.