Hacker News Reader

Comment by sc68cal | Hacker News Reader

In previous instances (like Comodo), I can recall discussions on the Mozilla mailing lists about the so called "death penalty" of revocation for CAs who have demonstrated serious lapses.

I think this situation is even worse. Forgive me for sounding paranoid but this sounds like collusion between the government of Turkey and Turktrust, to intercept communications. I believe that the harshest penalty should be pursued, which is removal of the Turktrust root certificate from all trust databases. They cannot be trusted.

EDIT:

It appears that Mozilla is on the same page as I am.

https://blog.mozilla.org/security/2013/01/03/revoking-trust-...

https://groups.google.com/forum/?fromgroups=#!topic/mozilla....

Another good idea mentioned on the mailing list was to blacklist the auditor:

https://groups.google.com/d/msg/mozilla.dev.security.policy/...

View on HN

I'd agree. We have plenty of CAs - killing a few off here and there isn't going to harm our ability to manage certificates, and those that make these kinds of mistakes - intentionally or otherwise - aren't worth the trouble of having them around.

A couple of CAs being revoked for slipping the wrong certs to the wrong parties is only going to make other CAs triple check their work before handing out the keys to the kingdom.

No, it won't harm our ability to manage certificates. What it will do instead is create a point in time where suddenly a whole mess of websites that used to be protected with HTTPS are now no longer protected with HTTPS. If there's a graceful and safe way to provide effective advance notice for this, I haven't heard it yet.

I agree in spirit; I'd like to see more CA's get the death penalty. But the pragmatic argument against it is convincing.

This seems like a problem that could be pretty easily solved by the browser vendors, similar to how they do malware checks. Throw up a "this site's security certificate was issued by a compromised authority, and will no longer be valid in <x time at y date>. If this is your website, click here for more information." Run that for a sufficiently long period of time, then kill the CA.

It's not perfect, but we have a huge web of people using these affected sites on a daily basis who can serve as a very powerful driving force to spur change when necessary to minimize fallout.

As a future mitigation strategy, what about encouraging website owners to have certificates independently signed by multiple CAs? Perhaps require multiple CAs for EV certs, and maybe for certain HSTS sites?

This makes it easier to revoke a bad CA and harder to spoof a high-value certificate, and _also_ gives the CAs more revenue, which sounds like a win-win situation for everyone. :-)

Because that is more effort for much less benefit than TACK.

TACK only helps with clients that have seen a site before, right?

Yes, but that's most sites.

This leaves an attack vector against people doing first-time-ever connections (like fresh installs of new OSes that are grabbing their new security packages), but TACK pins can also be pre-loaded or shared between clients for those circumstances.

While I agree with you about pulling the rug out from users - if the CA is already forging certificates for important domains, then how much security do they really have?

More than they do if the whole CA is removed. Sorry, annoying but true. Promote TACK!

right now only the turkish government can do MITM - other parties can't.

> right now only the turkish government can do MITM - other parties can't.

First, if true that's a small comfort. Second, how do you know that is true?

It's in the Turkish government's to use these invalid certs as little as possible, so they are probably going to use them against people like Turkish dissidents.

(I don't mean to dismiss their interests, but they are distinct from other people's interests.)

Chrome could warn "XYZ CA is scheduled to be marked untrusted in 30 days". The sites large enough to have economic impact if they were unsecured would notice and scramble to get new certs. Other browser vendors would follow. A warning shot is fired paving a path for harsher penalties in the future.

I think a known subset of websites having their HTTPS broken as a result of their CA misbehaving is much more preferable to a single CA having effectively broken all HTTPS for all internet users since 2011.

It's not a clear dichtomy, though: harsh penalties rarely alter behaviours.

I don't quite understand the "no longer protected with HTTPS." If their certificates stop working as part of the CA's revocation, then they'll have to get new ones before they can continue operating over HTTPS, of course. But they won't somehow automatically revert back to HTTP or anything, they just won't be able to carry on business (or at least their users will have to click through scary warnings). So they'll be offline for, what, a few hours, days at most, while they get this sorted out? And never actually insecure, just inaccessible.

HTTPS without a verified certificate (ie, after clicking through the warning) is only cosmetically more secure than HTTP.

This is kind of funny. The connection is still encrypted from others that might see it in-flight (ie, coffee shop, etc). However, your right, you would not be able to verify that the person on the other end was really the one you wanted to. However, this discussion is here because someone had one that WAS perfectly valid for gmail.com, even if it was not actually owned by google.

The connection is still encrypted from others that might see it in-flight (ie, coffee shop, etc)

Not really. If you were using your laptop on wifi in a coffee shop, I could intercept your traffic and rewrap the SSL in my SSL. You then have no way to know if you're securely talking to me, or to the original site.

Yes, but in the current situation only a small subset of people were exposed to that certificate, whereas killing the CA outright exposes everyone to bogus certificates for the CA's domain.

Isn't HTTPS relying on a demonstrably insecure CA also only cosmetically more secure than HTTP?

It depends who has access to compromise the CA. If it was the Turkish government that did so, they probably aren't going to waste their ammo to try to decrypt Joe Random's banking information.

Wouldn't you get a "certificate revocation" banner of some kind though, as apposed to "certificate unknown"?

edit: read the update at the top of the linked article, which clarified that it is not just revocation, but also the inclusion of a new root cert for turktrust that has been suspended.

You can MITM any HTTPS site in the world with an invalid certificate right now. Killing this CA won't change anything in that respect, so I still don't understand what you're getting at, or how killing this CA would make some sites less secure for a period.

All of the sites with legitimate Turktrust certificates would suddenly have invalid certificates. That's all I'm saying.

If you are operating under the assumption that Turktrust is head-to-tail untrustworthy and actively subverting the HTTPS/TLS PKI, then sure, that doesn't matter.

You said "no longer protected" which is what I'm trying to understand. All of those sites would suddenly have invalid certificates, sure, until they fixed it. But the interim period where they have invalid certificates is no more dangerous or insecure than the period before or after. The sites become less accessible, but they remain equally safe (or unsafe).

The CA itself wasn't demonstrably compromised. They issued intermediate CA certs, which makes them untrustworthy as someone who holds the power to issue intermediate CA certs, but doesn't necessarily undermine the trustworthiness of certificates issued through them directly (rather than through their bad intermediate certs), as their bad certs are not part of the chain of trust for end-user certs issued directly through them.

I'd argue that as long as an intermediate is passing out BS certs, nobody (modulo cert pinning etc) who trusts that intermediate or its root is truly protected.

I don't think you are paranoid.

They went from a "mistake" in issuing a "testing" certificate that managed to propagate through their system that just "happened" to be sitting around and configured in a way to be ready to execute a MITM configuration. To me, the chances of that happening seem challenging at best. To have it happen automatically and without hitch or fail, seems highly improbable.

Reply on news.ycombinator.com