Let's say I have a server listening on port 1234. I have some client software that needs to be able to connect to this port. But I want to prevent malicious users from bypassing the client software and connecting to the port by some other means (such as in a console or another piece of software).
The trusted client software and the server may share a secret key, if necessary (I can live with the possibility that the key can be extracted from the binary). I'd prefer not to send such a key in plaintext, but data after the authentication can be in plaintext. Specifically, I'm trying to figure out how to defeat a man-in-the-middle attack where the malicious user is using the trusted client software to calculate correct responses to server challenges.
Can I get there from here?
I could have the server's listening port bind only to localhost and require that clients first gain access to the machine via ssh. Then the client software could use an ssh library to run a command on the server that connects to the local port (in this scenario, the malicious user would be unable to use ssh to access the machine because he would not have the password). But then all my traffic is encrypted, which is additional overhead. Perhaps there is a program similar to ssh that only does the authentication but then leaves the channel in plaintext after that?
I ran a test to determine the overhead associated with encrypting all traffic.
spew.rb outputs 10 million 100-character lines.
fantius@machine> time /home/fantius/spew.rb > /dev/null real 0m35.015s user 0m34.934s sys 0m0.084s
top shows 25% cpu usage (one full core, of four cores)
fantius@machine> time ssh localhost /home/fantius/spew.rb > /dev/null real 0m40.704s user 0m19.981s sys 0m1.400s
top shows 45% cpu usage (almost two full cores)
That message rate probably exceeds most inter-machine connections.