4 ms·

The really silly thing is that it's 2018 and the browser vendors still refuse to implement name based constraints on certificate authorities. It should be perfe

by subway 8y ago

The really silly thing is that it's 2018 and the browser vendors still refuse to implement name based constraints on certificate authorities. It should be perfectly reasonable for a local, single domain CA to be generated and installed with the application. Instead we treat every CA as worthy to handle every domain always.

bostik 8y ago
I'm not sure that's a browser thing. The X.509 spec specifies a field for that, which in OpenSSL would be called "subjectNameConstraints". The rules for the constraint can be found in RFC5280.[0] Mozilla have had an open development track for CA name constraints for quite some time, but the last edit to the page is from 2015.[1] I tried to actually use this field couple of years ago, and none of the existing tools I tried had any support for it. OpenSSL would fail to parse a CSR config with this key. Same for Go's TLS library. So of course I did what any enterprising hacker would do: I created a CSR manually with the correct OID in place. Trying to sign that was nothing short of hilarious. Loading up the CSR into OpenSSL would trigger a BIO_read_* error. Trying the same with Go's TLS library triggered a panic! I then realised that if you could somehow supply a certificate chain with a name-constrained CA in it, it would act as a highly reliable DoS against virtually all clients. (Probably against servers too, if you supplied a client-cert chain.) Based on discussions since, I have been informed that Microsoft's TLS stack supports this - or at least should be technically capable of issuing CAs with the field in place. But because practically nothing else in the world has the support, and is in fact likely to crash when presented with one, even a gradual rollout is simply not possible. Hence every single CA you see will be valid for *. 0: https://tools.ietf.org/html/rfc5280 https://tools.ietf.org/html/rfc5280 1: https://wiki.mozilla.org/CA:NameConstraints https://wiki.mozilla.org/CA:NameConstraints
- kakwa_ 8y ago
  Another simple mitigation would be the ability for one certificate to be signed by several CAs. We could combined with some DNS records that states the policy for validating the certificate (stating the number of CAs to validate a given certificate). It could be a huge improvement on security, and eliminating CAs as single point failures for the whole internet, at least for critical pieces of it.

by subway 8y ago

bostik 8y ago

I'm not sure that's a browser thing. The X.509 spec specifies a field for that, which in OpenSSL would be called "subjectNameConstraints". The rules for the constraint can be found in RFC5280.[0] Mozilla have had an open development track for CA name constraints for quite some time, but the last edit to the page is from 2015.[1] I tried to actually use this field couple of years ago, and none of the existing tools I tried had any support for it. OpenSSL would fail to parse a CSR config with this key. Same for Go's TLS library. So of course I did what any enterprising hacker would do: I created a CSR manually with the correct OID in place. Trying to sign that was nothing short of hilarious. Loading up the CSR into OpenSSL would trigger a BIO_read_* error. Trying the same with Go's TLS library triggered a panic! I then realised that if you could somehow supply a certificate chain with a name-constrained CA in it, it would act as a highly reliable DoS against virtually all clients. (Probably against servers too, if you supplied a client-cert chain.) Based on discussions since, I have been informed that Microsoft's TLS stack supports this - or at least should be technically capable of issuing CAs with the field in place. But because practically nothing else in the world has the support, and is in fact likely to crash when presented with one, even a gradual rollout is simply not possible. Hence every single CA you see will be valid for *. 0: https://tools.ietf.org/html/rfc5280 https://tools.ietf.org/html/rfc5280 1: https://wiki.mozilla.org/CA:NameConstraints https://wiki.mozilla.org/CA:NameConstraints

kakwa_ 8y ago
Another simple mitigation would be the ability for one certificate to be signed by several CAs. We could combined with some DNS records that states the policy for validating the certificate (stating the number of CAs to validate a given certificate). It could be a huge improvement on security, and eliminating CAs as single point failures for the whole internet, at least for critical pieces of it.