views:

158

answers:

5

What is the safest communication method between two applications on the same machine, both Java and C/C++ clients with a Java server.

Are SSL sockets safe enough or they can be broken by "man in the middle" attacks?

The main concern here is how the clients can trust the local server?

Would introducing a remote server improve the security of the local communication and how can this be achieved?

+1  A: 

Safe from what? If an attacker has root, they can subvert system calls and spy on memory buffers before encryption and after decryption, and nothing you can do is safe.

If an attacker does not have root, they can't see this information even if you don't encrypt it.

So I don't see a point to this.

bmargulies
+1  A: 

If your entire system, including it's secrets are running on the same machine, then unforutnately it is intrinsicly unsafe. A hacker can see all parts of the system, and with enough effort, can unravel any protection, or encryption scheme you put in place.

If the system must be 100% secure then part of the system needs to be remote, and so unavailable to a hacker to comprimise.

mdma
if a system must be 100% secure, it must be unplugged - from the power grid as well as the network :)
CuriousPanda
Even then it is possible to read the harddrive and decrypt it, so you must lock it away in a big safe and bury it somewhere where no one expect it... But even then there a small chance that someone will find it... I think I'm getting paranoid. ;-)
Hardcoded
+1  A: 

I'd have to say that memory-mapped files or shared memory regions are the safest method, which both Java and C++ (Win32, Unix) support for interprocess communication. It's more complex though as you have to deal with your own synchronisation. Bypass sockets completely.

Chris Dennett
safe-ish, until I inject an evesdropping dll into your process space...
mdma
@mdma Of course at that point the entire memory space of the process is readable, so the communication mechanism is irrelevant.
KeithB
@mdma how do you plan on doing that?
Rook
see http://en.wikipedia.org/wiki/DLL_injection
mdma
+5  A: 

You need to elaborate your threat model. It's a general truism that anyone with physical access to your hardware, motivation and sufficient time will be able to subvert anything. This goes double if that attacker happens to be an admin on the server.

And yes, anything that is in your code is readable with admin access. You can try clever tricks like encrypting or obfuscating a password stored in binaries/JAR files, but this is a hindrance, not an absolute barrier.

Again, on the other side, there are no absolute barriers for confidentiality, merely more or less efficient obstructions. Whatever your measure, whatever the strength of your encryption and key management, with enough time and incentives, anything will yield. Which returns us to my first point: what is your threat model (what attacks do you wish to protect against); how much are your protected assets worth; and whom and what do you trust?

Pontus Gagge
In my particular case the clients will have to get a response from the local server based on which they will proceed on different paths so they need to trust this server.
Radu
@Pontus Agreed. This is why DRM is fundamentally flawed. The owner of the hardware becomes the attacker, so with enough effort any DRM can be broken. Note, I'm not trying to imply that the question has anything to do with DRM, just making an analogy.
KeithB
I honestly don't think Radu knows what attack he is trying to defend against. But this is a good answer to a bogus question.
Rook
@The Rook: Unfortunately, business people are known and infamous for expecting 'bogus' questions like these to have concrete, practical answers (which are naturally cheap and quickly implemented!). @KeithB's DRM example is just one of the more well known fallacies... But hey, let's just sprinkle the magic encryption dust and wait for the sparkles to protect us! :-)
Pontus Gagge
+1  A: 

A pipe should provide safe (and easy) communication. Yes, hackers would be able to retrieve a password if it is stored in a binary and the binary's permissions allow reading the file.

Marnix A. van Ammers