| ▲ | jabiko 3 days ago |
| But what would be the value of such a certificate over a self-signed one? For example, if the ACME Router Corp uses this special CA to issue a certificate for acmerouter.local and then preloads it on all of its routers, it will sooner or later be extracted by someone. So in a way, a certificate the device generates and self-signs would actually be better, since at least the private key stays on the device and isn’t shared. |
|
| ▲ | nine_k 3 days ago | parent [-] |
| The value: you open such an URL with a bog standard, just-installed browser, and the browser does not complain about the certificate being suspicious. The private key of course stays within the device, or anywhere the certificate is generated. The idea is that the CA from which the certificate is derived is already trusted by the browser, in a special way. |
| |
| ▲ | procaryote 2 days ago | parent | next [-] | | Compromise one device, extract the private key, have a "trusted for a very long time" cert that identifies like devices of that type, sneak it into a target network for man in the middle shenanigans. | | |
| ▲ | dcow 2 days ago | parent [-] | | If someone does that you’ve already been pwned. In reality you limit the CA to be domain scoped. I don’t know why domain-scoped CAs aren’t a thing. | | |
| ▲ | jabiko 2 days ago | parent [-] | | > If someone does that you’ve already been pwned Then why use encryption at all when your threat model for encrypted communication can't handle a malicious actor on the network? | | |
| ▲ | mjmas 2 days ago | parent [-] | | Because there are various things in HTML and JS that require https. (Though getting the browser to just assume http to local domains is secure like it already does for http://localhost would solve that) |
|
|
| |
| ▲ | 2 days ago | parent | prev [-] | | [deleted] |
|
