3 ms·

I think this hardcoded revocation list will grow out of control pretty soon. Are any browser vandors working on a more secure protocol than TLS/SSL that is not

I think this hardcoded revocation list will grow out of control pretty soon. Are any browser vandors working on a more secure protocol than TLS/SSL that is not as vulnerable to a single point of failure? Not exactly trivial, though it seems direly needed...

pmjordan 16y ago
This isn't a weakness in the protocol, but in the way certificate trust is handled. This is a bug in policy, not code.
- wladimir 16y ago
  The policies are implemented in code, in this case. But, let's rephrase my question then: are they working on a better way of handling certificate trust, in which a random compromised CA cannot do as much damage? The current model is clearly broken security-wise, and I'm sure this is only the start of the abuse.
  - pmjordan 16y ago
    I don't know if there's such an effort underway, but I hope so. Unfortunately, the entrenched players don't really have much of an incentive to change things, they're making billions from the current certificate model. The CAs don't even need to be compromised, there are quite a few that are maybe not 100% trustworthy (China's CNNIC is one that springs to mind) that are trusted by browsers by default. I agree it's a huge problem. I was merely pointing out that the problem does not lie within TLS/SSL. The PGP "web of trust" is an existing distributed trust model; it never really caught on, though.
JoachimSchipper 16y ago
Alternate designs have lots of issues. The most prominent alternative, PGP's web-of-trust, quietly failed in the market (seriously, even most of my cryptographer colleagues don't have (up-to-date) keys). There is some talk of using DNS to authenticate servers - just stuff a public key into DNSSEC authenticated records - but it'll be a while before that is actually ready. And someone will still have the key to the DNS root, and all of this stuff only works if DNS fails closed (i.e. breaks if there are no signatures), which won't happen anytime soon.

pmjordan 16y ago

This isn't a weakness in the protocol, but in the way certificate trust is handled. This is a bug in policy, not code.

wladimir 16y ago
The policies are implemented in code, in this case. But, let's rephrase my question then: are they working on a better way of handling certificate trust, in which a random compromised CA cannot do as much damage? The current model is clearly broken security-wise, and I'm sure this is only the start of the abuse.
- pmjordan 16y ago
  I don't know if there's such an effort underway, but I hope so. Unfortunately, the entrenched players don't really have much of an incentive to change things, they're making billions from the current certificate model. The CAs don't even need to be compromised, there are quite a few that are maybe not 100% trustworthy (China's CNNIC is one that springs to mind) that are trusted by browsers by default. I agree it's a huge problem. I was merely pointing out that the problem does not lie within TLS/SSL. The PGP "web of trust" is an existing distributed trust model; it never really caught on, though.

JoachimSchipper 16y ago

Alternate designs have lots of issues. The most prominent alternative, PGP's web-of-trust, quietly failed in the market (seriously, even most of my cryptographer colleagues don't have (up-to-date) keys). There is some talk of using DNS to authenticate servers - just stuff a public key into DNSSEC authenticated records - but it'll be a while before that is actually ready. And someone will still have the key to the DNS root, and all of this stuff only works if DNS fails closed (i.e. breaks if there are no signatures), which won't happen anytime soon.