20

We are developing a product (device / system) that will be installed on customer sites. Many of our customers will (should) be concerned about security, and should be thinking about it seriously.

Our product provides an API via HTTPS, which is used by the built-in UI and is also open for use by customers.

I'm looking for information and advice on how to deal with the SSL certificates that are installed in our product when they leave the factory.

I would appreciate any input - have we overlooked or missed anything?

As It Stands Today

Currently (the system is in development) we are installing the same self-signed certificate into every development and prototype unit. This clearly has no chain of trust and the user will see a warning.

I believe that this is the same approach taken by other manufacturers (e.g: Cisco, Ubiquiti), but confirmation would be appreciated.

Options

  1. tick Customers will be able to provide their own certificates, signed in whatever manner they wish (publicly, or privately). This will give them the chain of trust, and will allow them to be sure that they really are connecting to *that* system.

  2. qmark Installing a different self-signed certificate on each unit. I'm not sure there is any benefit to doing this over sharing a single self-signed certificate across all units, as the certificate is still untrusted.

  3. cross Installing a publicly signed certificate on each unit that leaves the factory. As far as I can tell, this will not work. Certificates are tied to a FQDN (possibly with a wildcard), and as such there is no way for us to generate and sign a certificate for the customer.

Attie
  • 303
  • 1
  • 7
  • So you have asked for a security review of your entire solution. While you may get someone generous enough to think through your entire proposal for free, you'd probably have better luck if you broke this into multiple smaller questions, each focusing on a single specific point. – Mike Ounsworth Mar 31 '17 at 14:04
  • @MikeOunsworth I was trying to ask specifically about certificates installed on a product going out of the door. I included #5 (nginx) and #6 (updates) for completeness as I felt that if I didn't people would comment. – Attie Mar 31 '17 at 14:07
  • Okay, then since your question, as it is now is more than a screen long and seems to contain 6 different questions, maybe you could edit out the extra bits so that the single core question is more obvious? (ie make it easy for us to see at a glance what the question is) – Mike Ounsworth Mar 31 '17 at 14:09
  • 1
    @MikeOunsworth Done – Attie Mar 31 '17 at 14:17
  • 4
    I'd install a different self-signed cert on every box, but allow the admin to upload their own cert (and CA bundle, if needed). Separate certs allows them to decide, on a per-unit basis, whether they want to trust that unit. With the same cert, once you trust one, you've basically trusted all of them, which is not great. – Joe Mar 31 '17 at 14:45
  • For an example of very dangerous fixed key and _CA_ cert (hopefully not your case) https://en.wikipedia.org/wiki/Lenovo#Superfish also here on stack https://security.stackexchange.com/questions/82035/what-security-risks-are-posed-by-software-vendors-deploying-ssl-intercepting-pro https://security.stackexchange.com/questions/82056/how-to-detect-if-i-am-vulnerable-to-superfish-and-how-to-remove-it https://security.stackexchange.com/questions/82113/why-was-the-private-key-of-the-superfish-certificate-so-easily-extractable and several more – dave_thompson_085 Mar 31 '17 at 18:51
  • Using the same self-signed certificate on each unit means someone who "hacks" *one* of your devices can then impersonate *every device* (except the ones whose administrators uploaded their own certificates). This is bad. Don't do it. – user253751 Apr 01 '17 at 02:25
  • 2
    If the reason you don't want to install a different certificate on every device is because your manufacturing process doesn't allow it, then you could instead manufacture them with no certificate, and have them generate one on first boot. (In that case remember to make sure the device has a sufficient source of randomness!) – user253751 Apr 01 '17 at 02:27

4 Answers4

30

We are installing the same self-signed certificate into every development and prototype unit.

Installing the same certificate into every unit is about the worst security practice one could imagine when dealing with certificates. We now know not to release products with the default hard coded administrative credentials. We avoid default credentials because such credentials could be extracted once and used to compromise all devices that implement them. This is a very similar situation – the default certificate means the private key could be extracted once and used to compromise all devices that rely on this certificate.

Cryptographically, both self-signed and trusted third party certificates operate the same way. Each certificate is associated with a key pair consisting of a secret private key and a non-secret public key. If you know the private key, then you can perform every action associated with the public key and certificate.

The compromise of the default certificates has further implications than just compromising authentication. For TLS, depending on the cipher used, the certificate could end up being used to establish a shared secret. In such cases, a passive eavesdropper would be able to decrypt TLS traffic after seeing the initial handshake.

Sure, competent administrators will fix this issue by uploading their own unique certificates, but how many would actually stop at 'just make it work' stage by trusting the default certificate? What you should do instead is generate a new key pair on initial boot or factory reset. This is how secure network devices operate. When generating new certificate, you also have to make sure that you have sufficient entropy available in the system and do not end up generating factorable keys.

Kirill Sinitski
  • 989
  • 6
  • 12
  • 2
    Thanks. Would you be able to give me any more info on 'why' we should have different certificates for each unit? The default certificate isn't intended to provide any proof of identification or authentication - what is the risk? – Attie Mar 31 '17 at 14:57
  • 11
    What you intend and how it is used are often diverge. If you need technical justification for your management to redesign use following: Depending on TLS cipher, certificates could end up being used to establish shared secret. If hard coded certificate is used, and you have to assume it is compromised, you can derive keys and decrypt TLS. – Kirill Sinitski Mar 31 '17 at 15:46
  • @Attie If you had a unique certificate per device then they *would* be proof of identification or authentication, after you'd accepted the certificate once. – user253751 Apr 01 '17 at 02:28
  • 3
    As a caution, most embedded devices that generate initial certificate on first boot generate one of a handful of certificates. The only way to avoid this is to include a hardware random source such as a thermal diode on the device. You would do better if you generated each one at the factory. – Joshua Apr 01 '17 at 04:07
  • Thanks @Joshua - this had been my plan, I can't see entropy being good shortly after first boot - especially as the unit will likely be connected to nothing but a laptop for its initial configuration. – Attie Apr 01 '17 at 07:51
4

Customers will be able to provide their own certificates, signed in whatever manner they wish (publicly, or privately). This will give them the chain of trust, and will allow them to be sure that they really are connecting to that system.

This suggests that either A) a typical installation will have a "real" domain name, visible on the public internet (as opposed to an intranet domain name or private IP address) or B) a typical customer will have the necessary technical knowledge to operate their own internal certificate authority.

If (A) is true, then your product could dial out to Let's Encrypt and obtain a signed certificate that way. This requires that the service both has a "real" domain name, and that it is fully visible to the public internet (i.e. it is not firewalled on ports 80 and/or 443). Let's Encrypt certificates can be acquired in a fully automated fashion and do not require any manual steps, provided you both know and control (can serve web traffic from) the FQDN. Naturally, you should interact with the service in a reasonably "polite" manner, especially considering that it is free of charge (i.e. do not send it a large number of requests at once, implement exponential retry backoff, etc.).

If (B) is true, then you should definitely go with the option you describe (i.e. let the customer provide a certificate), because your customers are better positioned to solve this problem than you are. However, in most industries, (B) is not true. Nevertheless, a sufficiently adventurous customer might want the option of doing this, so you should provide it anyway.

If neither (A) nor (B) is true, then you should follow one of the other answers. In this case, a typical customer does not have the ability to provide a good certificate, so you should not make them responsible for doing so. You may still want to provide an option for using a custom certificate, but you should not make it the default.

Kevin
  • 906
  • 6
  • 12
  • 1
    You can do PTR for yourself to determine your FQDN. If you get a value that resolves to your IP again you can just declare that to be your FQDN and Let's Encrypt will allow it to work. – Joshua Apr 01 '17 at 04:09
  • @Joshua: Indeed. But if the customer's sysadmins have firewalled incoming web traffic, it will be a lot harder to pull off, unless your box just so *happens* to have the ability to administer the customer's DNS and set a TXT entry, which is improbable. – Kevin Apr 01 '17 at 04:21
  • In my mind I imagined the box that absolutely needs this the most -- end-user wireless routers. – Joshua Apr 01 '17 at 04:22
  • Thanks @Kevin - for us, A is unlikely to ever be possible, B is a much more likely scenario. There will of course be the customers who don't understand / can't do this, but we need to support those who can. It is unfortunate that security needs this level of understanding and input from users, but that's a whole other topic. – Attie Apr 01 '17 at 07:45
4

You could do something like offer up a unique certificate for

product-serial-number.product-name.company-name.com

and have it issued by something that has something trusted in the certification path. The certificate would still not be trusted for that purpose, but someone could check the certificate against a sticker on the box (and optionally install it into their certificate store). Unfortunately, Chrome and Edge no longer make it easy to view certificate details on HTTPS pages, so this will be difficult.

David A
  • 71
  • 3
  • For products with embedded hardware security module/smart card, this can work quite well. The device can present a CSR generated using its private key during setup and the user simply forwards it to the manufacturer. The CSR can embed the internal IP address as the SAN so can be access without above domain name. The manufacturer can also change the DNS of above to return the device IP. This would allow the certificate to be issued by a proper CA and renewed regularly. – billc.cn Apr 06 '17 at 16:41
  • Could I trouble either of you to help me understand this scenario better please? (As you've seen from my own answer, I have a similar use case to the OP's, so I'm interested to learn other options.) First, what is the advantage of having a cert issued and signed by the manufacturer, using their own trusted cert (which I suppose originates from a CA) if we are unable to provide a 'real' domain for the CN, over and above generating a self-signed certificate? I would expect the browser to display a warning in either case. But does the manufacturer creating the certificate using their own [TBC] – Trevor Jan 15 '18 at 14:07
  • cert have the advantage that even though the browser moans about the domain / common name, at least a savvy user can verify its authenticity? Is that correct? So, the advantage is that one could verify that the certificate is not a rogue cert that a MITM has created, which is a possibility with using self-signed certs...? – Trevor Jan 15 '18 at 14:10
  • Also, @billc.cn, could you please expand on the point regarding a proper CA issuing the cert with the IP address as the SAN please? When I looked into this some time ago, my understanding (from having spoken with several CAs) is that a CA cannot produce a cert for you without assigning that cert to a specific FQDN. Is my understanding not entirely correct? – Trevor Jan 15 '18 at 14:15
  • @Trevor The issue here is what constitutes acceptable identifier. FQDN is a gold standard in open-PKI, but there are other types of identifiers that can be used. See RFC 6125 for more details. – Kirill Sinitski Feb 22 '18 at 14:13
3

I have been in exactly the same situation, having been responsible for developing a HTTPS server (and associated content, REST API, and so on) that is embedded within a consumer device.

As already stated in the question, installing a CA (Certificate Authority) signed certificate isn't an option unfortunately, because the certificate has to be tied to a domain.

In my experience, the best you can do is to generate a unique key pair and certificate in each device. In my device this takes place during the first boot after firmware is loaded into the device and also if a factory reset is performed. The microcontroller in use has a hardware RNG used for this purpose.

Using the same key pair and certificate on all devices would be especially dangerous when you consider that an attacker could simply obtain one of your devices and extract the private key from it, at which point all devices would be compromised.

So, in my experience, the very best you can really do (as no ideal solution seems to exist) is to inform your customers about why they have to acknowledge their browser's security warning about the self-signed certificate in the product manuals, and at least ensure that each device creates its own unique private key and certificate.

Trevor
  • 173
  • 6