11

Embedded devices, such as routers, IP cameras, generally provide HTTPS access to the admin interface. These HTTPS implementations generally have a lot of problems (non-unique certificates, self-signed certificates, etc.), which make connections insecure. So, I'm looking for best practices, how an embedded device can implement HTTPS in a secure way, which fulfills the following requirements:

  • The browser accessing the device via HTTPS (both remotely and from LAN) does not display any warning to the user. Thus the browser is able to validate the certificate sent by the device correctly.
  • If the private key of the device was compromised, an attacker should not be able to use this key to perform MitM attack against another device or another web page.
  • If it was possible, users should not have to install any certificate or accept any exception in their browsers.
Improve this question

3 Answers 3

Reset to default
3

It is possible that a device may stay un-sold/unused for a couple of years after its manufacture date and most (if not all) CAs will probably be unwilling to issue device certificates that have long expiry dates, so a straight forward solution is perhaps impractical.

However, I propose the following alternative:

  1. Use alternative method to establish initial trust between the device and client. For example, this can be a IPSec/L2TP VPN with a per-device PSK. The out-of-band transfer of the PSK prevents MitM (unless the PSK is known by the attacker).

  2. Use HTTP (via VPN) to download a CSR from the device. The domain can be a random sub-domain of a domain controlled by the manufacturer/supplied by the user.

  3. User/client submits the CSR to a CA on the device's behalf and relay back the signed certificate to the device via HTTP. The CA should enfore rules to not re-issue certificates for a sub-domain.

  4. Device apply the certificate and communication switches to HTTPS.

  5. When the certificate is about to expire, the device sends a signed renew request to the CA (via the client/user if necessary).

Obviously, the above "dance" is best automated by a program.

Security analysis

  • The identity of the device is established by the knowledge of the PSK.
  • MitM and eavesdropping are prevented by the VPN protocol (with PSK)
  • Device's private key is never revealed (and can be generated on-demand as opposed to programmed in factory) due to the way CSR works
  • Valid per device certificate can be used which fulfils all requirements
  • Random, non-device-specific sub-domain prevents an imposter pre-emptively registering a certificate
Improve this answer
1
  • Is it at all practical to use unsigned HTTPS over LAN? Isn't it redundant?
    – Suncatcher
    Jul 12, 2017 at 15:57
1

Points 1 and 2 are addressed by buying a certificate from a trusted CA.

As for your second point -

If the private key of the device was compromised, an attacker should not be able to use this key to perform MitM attack against another device

If you can find a way to do this, you'll be very rich.

or another web page.

Eh? I don't understand.

While the devices of this type I have used in the past have shipped without a cert, they provide a means for deploying the cert (and private key) to the device. Certainly you can't trust a certificate supplied with the hardware unless you sent the certificate singing request to the supplier (and retained the private key).

Improve this answer
1
  • The point is that compromising one device shouldn't allow a MitM attack on all devices. If you have the private key of one device you can obviously MitM that device, but not necessarily other devices.
    – Sjoerd
    Jan 30, 2019 at 18:36
0

The solution is provisioning the devices at the factory with unique verifiable certificates. But nobody does this.

Also some of your requirements are not realistic (as mentioned above):

If the private key of the device was compromised, an attacker should not be able to use this key to perform MitM attack against another device or another web page.

Not possible with the way TLS PKI works. May not be very practical though if (even self-signed) certificates are unique per device.

If it was possible, users should not have to install any certificate or accept any exception in their browsers.

Well, since #2 is not possible, users have to install a verifiable certificate if one wasn't provisioned at the factory.

These two other questions relate to this:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .