Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Good riddance.

We really need a "zero tolerance" system for CAs: As soon as you fuck up, you're out. There has been too much forgiveness and too little enforcement so far. Browser vendors, especially those with deep pockets such as Google, Apple, and Microsoft, should not be afraid to leverage their influence to make rogue CAs go out of business. Seriously, there are too many CAs already. 90% of them need to go bankrupt asap.

We also need some way to restrict what certificates "less trustworthy" CAs can sign. Even if CNNIC is one day reinstated, I wouldn't want them to sign any certificate for any domain that doesn't end with .cn. Ditto for various other government-sponsored CAs, which my browser also seems to trust for whatever reason. Even if TLS as we know it has no mechanism to enforce such restrictions, nothing stops browsers from doing it on their own.



> We also need some way to restrict what certificates "less trustworthy" CAs can sign. Even if CNNIC is one day reinstated, I wouldn't want them to sign any certificate for any domain that doesn't end with .cn. Ditto for various other government-sponsored CAs, which my browser also seems to trust for whatever reason. Even if TLS as we know it has no mechanism to enforce such restrictions, nothing stops browsers from doing it on their own.

Aren't you asking for "name constraints" to be enforced? If they could do this, they could fix the whole CA fiasco, but actually delegating domains rather than have a system where Root CAs are trusted for all domains.


Yes, "name constraints" is what I was suggesting. (I vaguely remembered that there was something in the relevant standards that allow such constraints, but I couldn't remember the name and wasn't sure that it was actually in the standards. So I just tried to explain the idea.)


https://tools.ietf.org/html/rfc5280#section-4.2.1.10

It does exist. Now do I trust the existing certificate validation code to do the right thing in all cases in presence of the extension? Not one second.


There are tons of edge cases here.

Let's assume, and this is not unlikely, that your favourite three-letter agency in is possession of a handful of trusted CA keys, acquired with extralegal methods.

What happens when there is leak? This may be the result of a whistleblower, or some mistake somewhere, which leads us to have a stronger confidence that these keys are out. Do we still blacklist? Only the intermediary, or all the way up to the CA?

I think we've seen from the past years that both root and intermediaries can follow every rule in the book and still get owned by intelligence agencies. We simply cannot pretend this is unacceptable for doing business.


I think that this is a perfect case where tech giants can increase "cost of doing business" for NSA. NSA is having it too easyfucking over citizens. Now let them try fucking over businesses and still get away with it.

I think that this is a great reason to have zero-tolerance policy to CAs fuckups.


My thoughts exactly. The world is not a chess board. The rest of the pieces don't just stay where they are and watch passively while you make a move. It may take a while for the full effects to be felt, but sooner or later the board as a whole will find a new equilibrium.

Browser vendors publicly announcing a zero-tolerance policy would effectively be a warning to the governments of the world: "Do not fuck with our PKI, or else." This will have far-reaching consequences even before any CA officially gets banned.


We bust the certs all the way to the CA. If it's been acquired through "extralegal" methods (an interesting word to not say "illegal", even though we all know it is), no matter who did it, security is compromised.


> As soon as you fuck up, you're out.

That would create an even bigger incentive than today to cover any misuse up. Not sure that's what we want.


Heh, let the arms race begin!

When every browser ships with verified fingerprints for a lot of important websites, it will be nearly impossible to use fraudulent SSL certificates on any significant scale without triggering a worldwide alarm.

Chrome already reports home when it encounters a forged certificate for any Google property. Firefox has started to use Chrome's HSTS preload list too, and Microsoft said they would use it in IE & Spartan on Windows 10. The future isn't looking good for would-be certificate forgers.


I was thinking of relaxing Mozilla's root inclusion requirements (I suggest to the same as Microsoft's) for government CAs in exchange for name constraints.


Do you honestly believe that government organizations don't already have their own people in these CAs that are issuing certificates whenever they want?


Depends on which government we're talking about.

Until a couple of hours ago when I manually went through my browser's CA list, there were a lot of national and even subnational government agencies in there. Japan, Taiwan, South Korea, Catalonia, Valencia, and even Hong Kong Post has its own root CA.


> As soon as you fuck up, you're out.

You would have no CA's then. I love when people criticize others without offering a anything in return.


No, GP actually has a point. Once you do things like this, you're out. Once you're out, you become a nobody.

Of course, you can reapply to get in (haha, good luck getting a response from Mozilla before a couple of years) but you have to start from scratch all over again. This puts a tangible cost to shenanigans. I highly doubt Verisign would be caught making the mistake these guys did.


Not a good comparison technically, but everyone makes mistakes. And the 2010 event was promulgated by "untrustworthy" employees. The system is risky, and change will have to come sooner or later.

http://www.reuters.com/article/2012/02/02/us-hacking-verisig...


CAs are supposed to be in the business of trust. We are supposed to hold them to the highest standard of machine trust. If they screw up and fix the error in a matter of hours or days... alright. But CAs who charge money for making certificates need to earn our dollars.

Sure, everyone makes mistakes. And if you're in the business of trust, you find ways to uncover and correct those mistakes. Also, you insure against those mistakes, and some of that insurance buys another set of eyes.


Nah, we'd still have plenty of CAs at any given time. After all, it's highly unlikely that all of them will fuck up at the same time. If you buy from a reputable CA, there's at least 90% chance that you won't have any issues during the life of your certificate (1-2 years).

If the requirements for becoming (and remaining) a CA become stricter than they are now, the market will adjust after a while. Peace of mind has always been, and will always be, a very strong selling point. How about this: "We'll sell you three certificates for the price of one! One signed by Comodo, one signed by Verisign, and one signed by GlobalSign! And here's an Apache module that detects when one of your CAs get discredited, and automatically replaces it with a good one!"


Or just create a TLS extension that allow all of the chains to be served as part of the TLS Certificate message.


There's even an SSL extension for the client to mention its list of trusted root CAs in its side of the handshake. It's very rarely used on desktop / on the public Internet because people tend to trust more CAs than would fit in a TCP packet, but it's apparently useful enough in embedded scenarios to standardize.

https://tools.ietf.org/html/rfc6066#section-6

You could imagine a variant for, say, pointing out that you explicitly distrust certain CAs that the server is likely to assume you trust.


Unfortunately, that's not valid per the RFCs (from rfc 5246, TLS 1.2):

"certificate_list

      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case."
I would be super happy if I could send multiple certificates though (provided all my clients magically got tls client library updates to handle it)


Just edited my comment.


> You would have no CA's then.

Would you? We've seen, what, a dozen (at most) CAs do inappropriate things in the last several years? And there are hundreds of CAs? I think things would be fine.

In particular, there are lots of intermediates. My personal website's cert is from Gandi, which uses an intermediate chained off USERtrust. Gandi could arrange to have a second root CA sign their intermediate, so that if USERtrust gets kicked out, browsers can still construct valid chains. And I would gladly pay for such a feature from an intermediate, if the alternative were either my site being at risk of being marked untrusted, or SSL becoming meaningless.


I think the proper number of CAs is a lot closer to zero than it is to the current hundreds.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: