Are TCP connections on localhost secure?

Question

Domain

I am designing a piece of software ATM and I would like to hide necessary cryptographic operations behind a "crypto daemon", which accesses encrypted keys on disk and offers a high level, application specific interface to these operations.

The other programs have to:

• Authenticate to the daemon (valid authentication allows the daemon to decrypt the keys on disk)
• Issue commands to the daemon and receive answers

I have the idea of using TCP via localhost for these operations. After doing the TCP handshake, the program has to authenticate to the daemon and - if successful - crypto commands can be issued to the daemon.

Actual Question

At least two assumptions have to hold, otherwise this is insecure by design:

1. TCP channels on localhost cannot be hijacked/modified (except by the admin/root)
2. TCP channels on localhost are private (cannot be peeked at) (except by admin/root)

Are these assumptions true? Why? Why not? Is anything else flawed?

Answer 1

Loopback connections are in general not subject to man-in-the-middle attacks (from other non-root processes on the same box, or from outside the box).

If you intend to use loopback as a poor-man's-transport-security (instead of TLS) you will have to ensure that both ends of the connection are suitably protected:

• On the client end, what is the consequence of an unauthorised low-privilege process being allowed to connect to the server? If client access is protected by a plaintext password, you might consider a brute-force attack against that password, and address that with password complexity and auditing of failures.

• On the server end, is it conceivable for a low-privilege process to cause the server to terminate (eg crash it with malformed input or resource exhaustion), and replace it with a trojaned listener that would steal the password from a client or return misleading results? You might consider using Unix's low port number protection to stop this (but then you have to worry about running as root/setuid/fork).

It depends on your threat model how much of a concern you have with protecting against local access; you may take the position that your infra sec and monitoring is sufficient to discount the scenario of an attacker getting a low-privilege account. But in the general case, you may be better off biting the bullet and going with the well-known solution of TLS.