1 
HW (linux) <---Eth---> Official PC (win,mac,linux)
               |
               |
                ----> Man-in-the-middle eavesdrop

I'm looking to prevent an unauthorized party inside the LAN to make sense of communications between an official PC and a custom piece of HW.

The custom protocol used to communicate works on top of TCP. It can be assumed the unauth party won't have access to the filesystem of the official PC.

My current design involves using self-signed client certificates that we'd use in the official PC. Self-signed server certificates would be present inside the custom HW. The software would wrap the current socket comms in TLS, via libtls.

The certificates would be generated once with the openssl command and last for a couple of years.

Does this look reasonable or is it junk? Any gotchas?

EDIT

Commenting on some of the points in Steffen Ullrich's answer:

The client and server certificates would only be used to connect from specific official PCs to the device, and not for any other kind of communication to other devices or software. The distribution of the client certificate is controlled. The server certificate details can be made known to the official PCs, and the client certificate details can be made known to the custom HW.

  • 1st point: In the client, we can validate the server certificate using its fingerprint. In the server, we can validate the client certificate using its fingerprint too, if needed.
  • 2nd point: The distribution of the client certificate is strictly controlled, so nobody outside of the official PCs should have it. IIUC, that means other connections without the client certificate would be rejected (right? Otherwise, would it help to invert client/server?)
  • 3rd point: We can update client/server certificates (both or just one of the two) as needed.
Improve this question

1 Answer 1

Reset to default
1

The use of TLS makes sense. The use of self-signed certificates makes sense as long as you properly deal with the servers certificate at the client side. This means that

  • The trusted self-signed certificate properly validated for example by using the fingerprint (pinning) or the certificate itself. This means also that it is known before the first connection is established by the client, so that already the first connection can be validated.
  • The trusted self-signed certificate is only trusted for connections to the specific device. This means especially that it is not imported as a generally trusted CA into the browser. Otherwise it could be used to intercept other connections in case the private key of this certificate somehow gets known to the attacker.
  • A working process is established how trust into the certificate can be revoked in case it gets compromised and how it can be replaced when it expires or gets revoked.

Your question does not provide enough detail to decide if these requirements are satisfied by your design.

Improve this answer
13
  • For the first point, what do you mean by "validated"? Not sure I fully follow the point made and its implications, but yes, the server and client can both be made aware of each other certificates before the first connect. ///// For 2nd point, what kind of other connections could be intercepted? Do you mean a browser accessing the HW device?
    – ArthurChamz
    Jul 2, 2019 at 15:22
  • @ArthurChamz: Validation means that the certificate is the expected one. For CA issued certificates this usually means checking expiration, subject, status revocation and that it was issued by a trusted CA. For self-signed certificates it can for example checked against the expected fingerprint.
    – Steffen Ullrich
    Jul 2, 2019 at 15:35
  • " For 2nd point, what kind of other connections could be intercepted?" - TLS connections from any system/software which trusts this certificate as trusted CA can be MITM. This is not restricted to connections accessing the HW.
    – Steffen Ullrich
    Jul 2, 2019 at 15:36
  • Thank you for your comments, please see my edit with more info on each point.
    – ArthurChamz
    Jul 2, 2019 at 16:20
  • @ArthurChamz: If the self-signed server certificate is also a CA certificate (typical case since otherwise openssl would ignore it when put in the CA store) and if it is put into the browsers (or other applications or systems) trust store as trusted CA (also common setup or misconfiguration) and if an attacker might get hand on this certificates private key (whatever "strictly controlled" really prevents in practice), then this certificate might be used as the trusted issuer inside MITM attacks since it can be used to issue certificates for arbitrary sites and is trusted by the the client.
    – Steffen Ullrich
    Jul 2, 2019 at 17:30

You must log in to answer this question.

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