3 ms·

I'm a little lost on why the need a new root CA cert on a computer that already has a cert store. Can't they safely communicate with whatever.sennheiser.com us

I'm a little lost on why the need a new root CA cert on a computer that already has a cert store. Can't they safely communicate with whatever.sennheiser.com using the existing certs? Afaict, this isn't a stand-alone device trying to communicate, but your computer, running some app. What am I missing? Edit: okay, I see below that they are using a local web server, and (thanks to browser decisions about localhost) it requires https.

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.
rogerbinns 8y ago
I work on a product that is in a similar boat. We have LAN based remote control using HTTP connections, but have no practical way of TLS enabling it. Stunts like this would work, but are a really bad idea. The other alternative is to have the devices and remote control connect to a central server over TLS and Internet and then have that server relay traffic. But that is not nice either. However we may be forced into it because of client restrictions on non-TLS connections. The Plex folks did solve this problem, but it requires a CA to cooperate. I wish someone would step in and help solve it for all. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- deleted 8y ago
  [deleted]

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.

rogerbinns 8y ago

I work on a product that is in a similar boat. We have LAN based remote control using HTTP connections, but have no practical way of TLS enabling it. Stunts like this would work, but are a really bad idea. The other alternative is to have the devices and remote control connect to a central server over TLS and Internet and then have that server relay traffic. But that is not nice either. However we may be forced into it because of client restrictions on non-TLS connections. The Plex folks did solve this problem, but it requires a CA to cooperate. I wish someone would step in and help solve it for all. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

deleted 8y ago
[deleted]