I have some app-components on the same machine but in different languages which need to communicate. I am using socket communication over localhost to do so. The data transferred is confidential.

Should this communication be encrypted?

I mean an attacker would have to be able to run code on the machine in order to intercept this and in that case the user lost anyway, right?


You need encryption to deter passive attackers (evil people who spy on the line and try to work out the data contents), and integrity (and its sibling authentication) to block active attackers who alter the data while in transit. SSL provides both. However, this makes sense only in contexts where attackers can actually spy on or alter data in transit. For two process on the same machine, communicating through the "localhost" network, attackers who can do that have, usually, "already won".

Details may differ depending on the OS. However, your security will normally depend on the OS, not on encryption. Consider, for instance, a Unix system with multiple users. If your two processes talk to each other, then processes from other users cannot peek into the data exchanges (unless the attacker is root, and then he can do anything); however, they may try impersonation: at some point, one of your components must connect to the other, and the rendez-vous point for TCP sockets is a port number. An attacker who can run his own code (as an ordinary user) on the machine may maintain a fake server which will receive the connection request in lieu of the intended component. To protect against that, the client would have to make sure that it talks to the expected server (and vice versa): this can be done with SSL, but better solutions exist (in this case, using Unix-domain sockets with a path protected by system access rights and/or getpeereid()).

If, in your case, the local machine is assumed to be "clean" (no hostile code runs on the machine, under any identity), then connections to localhost are safe and there is no need for any extra protection. If potentially hostile but unprivileged code may run on the machine (that's the "shared multi-user machine" model, as was typical of Unix systems in the late 1980s), then you should use the OS features to make sure that connections are indeed conveyed to the right process (i.e. to a process running on the expected identity). SSL would be overkill.

  • Also using a name in a directory (with a owner) for a rendez-vous is much saner than a meaningless arbitrary number that might clash with another choice of arbitrary number. – curiousguy Jun 23 '18 at 0:33

Well,if the two programs are running on the localhost why do you want to use Network communication? You can use any IPC(interprocess communication) like Named Pipes You can specify a security descriptor for a named pipe when you call the CreateNamedPipe function. The security descriptor controls access to both client and server ends of the named pipe.

Read the access control Model to learn how to secure named pipes. http://msdn.microsoft.com/en-us/library/windows/desktop/aa374876(v=vs.85).aspx Or you may simply use a Symmetric Encryption Algorithm for which the secret is know to both processes,you may hardcode the secret into the code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.