0

I'm creating a system that will allow the user to control a certain number of remote hardware devices. Each device (the client) is connected to a micro web server, that responds to HTTP(S) requests.

The client must send data to the server (containing it's current hardware state). The server must send data to the client (to tell the client what to do). Client and server can send data to the counterpart when they want.

Now, I'm concerned about security... How about using HTTPS with self-signed SSL certificate for the client?

Let's assume that I buy a certificate for my domain server (provided by an external trusted CA) and I create a different self signed certificate for each client. Can I benefit from HTTPS security in the two communication directions (client to server and server to client)?

In this case the server will store the different client certificates, so it can establish a secure connection when it want to send a command to the client. Is it right?

Edit 1

The "client" (the hardware device) acts as a server when it receives a command by the remote user. But acts as a client when sends its hardware state to the server. These cases take place in two different moments. So, both parties should be able to connect with the counterpart as client or server depending on the case.

Improve this question
5
  • 2
    When a HTTPS connection is established, both data from the server to the client and from the client to the server is encrypted - this doesn't require a certificate to be purchased for the client side. However, from the description it sounds like the "clients" act as a server in some cases. Does the server initiate the connection to the client at all?
    – Matthew
    Commented Jan 4, 2017 at 10:01
  • @Matthew you're right, the "client" acts as a server when it receives a command by the remote user. But acts as a client when sends its hardware state to the server. These cases take place in two different moments. So, both parties should be able to connect with the counterpart as client or server, depending on the case.
    – Riccardo Leschiutta
    Commented Jan 4, 2017 at 10:57
  • Your question is very confusing to read as you describe the device as "client" when it is acting as both a client and a server. Leaving that aside for now, the overall security of the device is compromised by the fact it can act as both a client and a server. You've not said how the client action on the device is triggered (which is an important feature of the architecture and may be a consideration for security).
    – symcbean
    Commented Jan 4, 2017 at 14:30
  • "the server will store the different client certificates" - no, the whole point of SSL / TLS is that an end point only needs to store the CA cert - not the cert presented by an endpoint. Otherwise you're doing a weird sort of SSH.
    – symcbean
    Commented Jan 4, 2017 at 14:30
  • you could use (an adaption) of stunnel - stunnel creates a bidirectional ssl encrypted data stream between two devices through which you can easily tunnel other protocols/data
    – architekt
    Commented Jan 4, 2017 at 15:24

1 Answer 1

Reset to default
1

In this case, you would probably be best off going for self-signed certificates for the clients, ideally using an internal CA which your server is aware of. This situation doesn't have the usual drawback of self-signed certificates giving a browser warning, since only the server is expected to connect to the clients.

However, you wouldn't want to rely on just the basic HTTPS authentication process. While that would provide encryption in both directions, it wouldn't let you verify that it is your server connecting - it could be any other device. You could instead use HTTP Certficate Authentication (see Certificate based authentication vs Username and Password authentication for a description) and make your clients aware of what certificate the server should present. This is somewhat more complicated to configure than normal encryption, since both ends need to be aware of the other. The advantage, though, is that you can be sure that only your server (or an attacker who has compromised your server and copied the private key file) can connect to the client devices.

Depending on your configuration, this process might not be needed in both directions - you might consider it acceptable for other devices to connect to the server, so connections from client devices only encrypt without needing to verify the server certificate, while the connections from the server need to be verified by the client, since it's the only intended connecting device. This would also simplify the addition of new clients - they need to know what certificate to expect from the server, but the server doesn't need to be updated to know what certificate they have. This would be a decision based on the specific situation though.

Improve this answer
2
  • 2
    If you know your clients (with hardware and a preconfigured certificate that is mostly the case) you should do mutual SSL and not allow other clients to connect. This will reduce your attack surface and increase security. Also important, how will you protect the client certificate from being extracted? If such an certificate is extracted, an attacker can acts on behalf of the device. Depending on the hardware this can be difficult.
    – Silver
    Commented Jan 4, 2017 at 11:27
  • 1
    You also have the issue of being able to kill off certificates that have been compromised. Even so, self-signed certs would almost certainly be a suitable part of the answer.
    – Julian Knight
    Commented Jan 6, 2017 at 15:35

You must log in to answer this question.

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