5

How would one go about ensuring that a server at a given IP address is who it says it is? I need to send confidential data to another server at another IP address. If the server had a public domain it is clear that a SSL certificate would be the right solution, but is this also the case for IP addresses?

I control a specific piece of software running on both servers, where Server1 will send confidential data to Server2. Server1 lives in a cloud I can control, but Server2 can live on any machine around the world as long as it is connected to the internet. At Server1, I have a registry of all Server2s that it can connect to.

I have thought about using a RSA key-pair, where the private key would live on Server2 and the public key would live in the registry on Server1 alongside the Server2 IP address. Then before sending the confidential data, I could present Server2 with the challenge of decrypting a random string and echoing back the result and check if it matches on Server1. The confidential data will of course also be encrypted with the public key, so an eventual man-in-the-middle attacker spoofing the IP address would get pure nonsense, but I don't like the idea of someone eavesdropping on the communication.

TLDR; How do I make sure that a server at a specific IP address is not a man-in-middle attacker and is in fact a server that can be trusted with confidential data?

Improve this question
3
  • Your whole approach to making your own solution would be moot if you answered your very first question. Of course you can have SSL certs for IP addresses...
    – schroeder ♦
    Commented Apr 2, 2021 at 9:42
  • @schroeder yes, I tried figuring something out on my own just going with my intuition :). I have seen that it is possible to use SSL certificates for IP adresses, however I was in doubt if it would fit my communication scheme.
    – Da_programmer
    Commented Apr 2, 2021 at 9:54
  • Which server's identity are you referring to, the sender or the receiver?
    – Barmar
    Commented Apr 2, 2021 at 22:23

1 Answer 1

Reset to default
22

Basically you are trying to re-invent certificate based authentication since you only have an IP address and not a domain.

But certificate based authentication can be used without a domain too, for example by having the IP address as the subject of the certificate (if fixed) or by knowing exactly which certificate or public key inside the certificate to expect (certificate pinning, maybe even with a self-signed certificate).

In other words: just use TLS with certificates and don't invent anything new.

Improve this answer
5
  • Thanks for the answer! So would it be possible to create a Certificate Authority shared for both Server1 and Server2, and then sign a certificate with the IP address as the subject? Is it even possible that a man-in-the-middle attacker could spoof the IP address and provide the original certificate signed by the CA?
    – Da_programmer
    Commented Apr 2, 2021 at 9:49
  • 1
    @Da_programmer: It is possible to create such a CA which can be added as trusted to the TLS client (i.e. your Server1) in order to verify the server certificate of the TLS server (your Server2). It is also possible to use the IP as subject in the certificate. A man in the middle can not provide the original certificate though since it does not have the private key of the certificate.
    – Steffen Ullrich
    Commented Apr 2, 2021 at 10:03
  • I’d skip adding the IP address for the multiple connecting servers and just do certificate authentication without it. The added value is minor compared with the inconvenience of ensuring the IP address is stable (static or long held DHCP in broadband). Also, IP addresses can be spoofed, so again minor. If you feel you must have a fixed endpoint for the certificate, use DNS if you have your own domain or Dynamic DNS if you don’t. The security of the private key is paramount for both servers and all that matters during Authentication. Their specific addresses are mutable.
    – Andrew Philips
    Commented Apr 2, 2021 at 12:15
  • 4
    @AndrewPhilips: Assuming you are going to use more than one certificate in the system as a whole, you probably need to put some kind of identity on it. But this identity need not correspond to something physical such as an IP address. For example, you could establish a set of "roles" (opaque strings), set privileges based on those roles, and then issue certificates for each role. The whole point of using an internal CA is to have flexibility in how your identity and authorization systems work, so it can be as simple or as complex as is required.
    – Kevin
    Commented Apr 2, 2021 at 18:31
  • @Kevin agreed. The CN field could contain anything. DNS host name is the usual standard, but that doesn’t preclude other identifying information. RBAC, roles, privileges could all be useful, although these are most useful in a federated environment and OP appears to only have one central server that needs to handle things. In this case, it would be more convenient just to centralize Authorizations there and outside of the certs. Although, we may not have enough details on the architecture.
    – Andrew Philips
    Commented Apr 2, 2021 at 18:37

You must log in to answer this question.

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