1

I have a situation in which I wish to produce (physical hardware) widgets that plug into a LAN and act as a web server, serving content to web clients that are also on the LAN.

The traffic from the widgets to the client should be encrypted, but there is the problem that I don't have control of either the LAN or the client, meaning it is impossible to set up a local CA or do any DNS twiddling.

Is it possible to arrange some way in which the widget can serve encrypted data to the web client.

It is probably possible to create and publish certs for every device if that creates some mechanism to allow this to happen (tied to some domain that I own, say widgetN.thedomainiown.com). Assume everything on the LAN can see the big wide internets.

I've considered a couple of strategies as follows:

  1. Create a cert for each device as above, and ship the widget with that cert installed. I understand this won't work because it will cause a certificate hostname discrepancy.
  2. Have both the widget and the client communicate over a trusted internet server that I control.

In the second case, at one extreme, all the data can be communicated over the secure links and relayed by the trusted server. I suppose this would solve the problem, however it is impracticable for bandwidth and latency reasons.

Instead, is it possible to use the trusted server to set up the encrypted link between widget and the client? I've thought about using javascript encryption for this, but everything I've read tells me that javascript encryption is simply bad and should never be used. In this instance, I'm not fully clear what the problem would be, so I'd be pleased to be enlightened.

It would be a case of the trusted server constructing a web-app that encapsulates the encryption protocol and the necessary certificates which can then be used to handle the encryption over the LAN. That is, the trusted server provides the web page used to handle the local traffic (is this even possible given the same-origin policy?).

  • Why can't the users install their own certificates? This is what's normally done. – Michael Hampton Sep 30 '15 at 16:57
  • I would be possible, but it's hardly seamless - adding an extra layer of complication for the user (as well as the consequential support hassle). – Henry Gomersall Sep 30 '15 at 16:59
  • 1
    PKI is certainly not seamless. Anything done _right_ is going to require the user to do some sort of setup. – Michael Hampton Sep 30 '15 at 17:12
  • Why can't the widget generate it's own self-signed cert with the correct hostname during initial setup? – GregL Sep 30 '15 at 17:30
  • Initial setup? It can generate a self signed certificate but doesn't that still require a confused user to agree to the certificate without really knowing what they're agreeing to? – Henry Gomersall Sep 30 '15 at 17:35
  • @PKI Is it not plausible to hypothetically verify valid key exchange through displayed fingerprints or some such mechanism? It's probably worth noting that the widget and the client will be physically close to one another. – Henry Gomersall Sep 30 '15 at 17:37

0 Answers0