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.
If I understood correctly, the potential threat is from a malicious process (running locally) getting in middle of two components of the same app running locally and interacting with each other via IPC. Indeed it is a overlooked threat model, and deceiving local attackers like Man-in-the-Machine (MitMa) are a real threat even in security critical software such as password manager. Password managers has desktop app as one component and the browser extension as the other, running as a local server and client. I assume the OP's architecture reflects something similar.
The OP did not mention the underlying operating system. The choice of IPC is dependent on the underlying OS, its support to security features or a specific IPC method. Hence, besides network sockets (used for local communication) there is no one IPC fits all concept.
In my opinion, IPC should be treated with same prudence as that of a network communication. Hence, if network sockets are to be used, it is tempting to use TLS/SSL based approach, like they do in real network communication, to secure the IPC communication might be tempting. However, remember the following:
As @Tom Leek pointed out, using TLS/SSL based approach is not worth it. Though they provide security for your IPC components, the necessary infrastructure, including certification authorities, may be an overkill. The goal here is just the authorization of the two ends of IP channel (two processes or components of same software) rather than binding them to strong identities.
For other OS and IPC methods, here are few things to consider:
FILE_CREATE_PIPE_INSTANCE and FILE_FLAG_FIRST_PIPE_INSTANCE flags. The former ensures that if an instance of the named pipe with the same name already exists, only processes with the FILE_CREATE_PIPE_INSTANCE access to the pipe object can create a new instance. The latter, on the other hand, ensure that it is creating the first instance.
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.
