Hacker News new | past | comments | ask | show | jobs | submit login
Embedded Devices Share, Reuse Private SSH Keys, HTTPs Certificates (threatpost.com)
21 points by walterbell on Dec 1, 2015 | hide | past | favorite | 7 comments



Hmmm... for the HTTPS certificate. Assuming that a router exposes itself as "myrouter.box" in the LAN and the manufacturer obtains a CA-signed cert for it, it would not be a problem for the private key to be public?

At least in consumer space, the only threat I believe to be reasonable is your kids running an ARP poison attack to get the admin password of the router and unlocking the internet firewall - and any parent relying on technology instead of properly educating their kids deserves being owned that way imho.


It is not possible to get a CA-signed cert for internal domains.


It was possible it was banned in 2011 by the cabforum. It was deemed that it would more likely be exploited for malicious purposes rather than anything else, and since you cannot explicitly validate the ownership of local domains it pretty much creates a FCFS environment which can fail very easily due to the inability to validate domain existence.

Internal sub domains e.g local.mycorp.com are still valid as long as you can provide proof of ownership of the parent domain, and after the "ban" they also introduces some leniency in getting an intermediate singing cert for internal domains because in many cases the reason why a company would buy a "CA" cert for an internal domain / host was regulatory and auditors don't care what the cabforum has to say.

Those CA's however will not be distributed outside of the organization so they pretty much provide as much assurance as an internal self signed CA just with the ability to please an auditor by saying that it was signed by verisign.


> after the "ban" they also introduces some leniency in getting an intermediate singing cert for internal domains because in many cases the reason why a company would buy a "CA" cert for an internal domain / host was regulatory and auditors don't care what the cabforum has to say.

Wait, so you're saying that CAs are giving out intermediate roots to customers on the promise that they won't give out the private key? If this is the case, please provide examples of CAs that do this, so I can open bugs in the relevant software to request the root CAs be removed.

TrustWave did this, and got a lot of flack for it. In the end they stated it was a mistake and they'd never do it again, so they got to keep their cert (a mistake in my opinion, as they already demonstrated that they can't be trusted with CA powers).

Or did you mean they provide regular server certs or wildcards for internal domains?


Isn't it possible for a CA cert to have authority only for *.foo.com?


> Isn't it possible for a CA cert to have authority only for *.foo.com?

Technically, you can do that with name constraints. In practice, you can't because many SSL implementations (like, say, OpenSSL[0]) won't honour it, so it'd effectively be an unrestricted root CA for those.

[0] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-...


If I am to set up an embedded device for distribution to outside customers, and would like to setup https and/or more secure ssh private keys.

What's the best way to set it up?

Is it possible with current CA/https system?




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

Search: