2

We have devices (think "Internet of Things") that have a HTTP server installed. Those devices can change their IP and domain name quite frequently (or have no domain name at all). They have a GUID though.

The clients communicating with this HTTP server are not all under our control - they might be common browsers.

Is there a way to use HTTPS in this situation, without forcing the user to either

  • Accept an invalid certificate
  • Add our own CA to their trust store
  • Do something else that seems fishy?

Does the answer change if we have control over the client (an app)?

In the past this was solved by using a server in the internet, to whom both client and device connected, and which forwarded messages.

Jost
  • 191
  • 9
  • You may need to switch to some tunneling protocol, like public key authenticated SSH or VPNs. If it is about mobile devices talking over WiFi primarily, Mosh is a version of SSH that you may find useful, designed to tolerate poor latency. – Natanael Nov 05 '15 at 07:53
  • I couldn't think of anything which could work under those constraints. – Philipp Nov 05 '15 at 07:55

1 Answers1

1

The certificate is used to validate that a client is talking to the expected endpoint and not to some man-in-the-middle. If IP address and hostname change frequently this means that they cannot be used for identification.

... not all under our control - they might be common browsers.

Browsers expect to have a constant hostname, even for certificates were an explicit exception was made. Thus common browsers can not be used if the hostname changes frequently.

Does the answer change if we have control over the client (an app)?

In this case you could use certificate/public key pinning, that is your application does not expect a certificate signed by any trusted CA where the certificate matches the hostname but instead it expects a specific certificate or at least a specific public key. Of course this expectation must be hard-coded into the application.

Another option would be to work around the problem of changing hostnames by providing your own DNS service and provide constant hostnames within your own domain (e.g. foobar.customer.example.com). But this would require that each device announces any hostname changes to your DNS server so that the appropriate CNAME alias could be setup and that the clients would need to have an internet connection in order to connect to the device even if the device is in the same local network.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
  • Thanks - so we'll have to tell users to accept invalid certificates in the browser, have the app verify the certificate against our own CA or a pinned certificate. I just hope that mobile OS give us enough control to do so. – Jost Nov 07 '15 at 09:09
  • @Jost: common mobile OS give you the option to do certificate pinning and you will find sample code at OWASP. Teaching users to accept invalid certificates is a very bad idea. Once the user is used to accept invalid certificates man-in-the-middle attacks against other sites is no problem because the user is trained to accept invalid certificates and will thus ignore the problem. – Steffen Ullrich Nov 07 '15 at 09:18
  • I hoped to circumvent teaching the users to accept invalid certificates, which was the reason for this question. Also, even major vendors like AVM have not solved this, their Fritz!Box presents just a self-signed certificate. So for the in-browser use case I don't see any alternative, except not using TLS. – Jost Nov 07 '15 at 09:23
  • @Jost: Fritz!Box is actually a good example on how to do it right: They offer the myfritz service which creates a constant hostname for the same Fritz!Box (this was one of the alternatives I've shown). This way you have to accept the unknown certificate only once. Apart from that they give you the fingerprint you should expect in the administrator interface and they even offer you a way to import your own certificate or to export the generated certificate to import it as trusted on other systems. Thus they avoid to teach you to accept arbitrary invalid certificates. – Steffen Ullrich Nov 07 '15 at 09:43