I'm looking for any good reason not to use a shared key for a specific secured data transfer case. So far I don't find any good one. But at least one person I have described this to seems overly fearful of a shared key. I just think they are reacting to the fact that a shared key is not suitable in the general cases, but have not analyzed how it would apply in this case I describe below:

The use case is a one time data transfer. The scenario is a user logged in to two separate remote computers via a slow connection using ssh. There is a need to transfer a large volume of data from one remote host to the other. These remote hosts are located apart from each other requiring use of the internet to reach each other directly. The ssh connections might be as slow as mobile 2G or even dial-up. The data to be transfered between the remote hosts might be a terabyte in size. You simply would not even think of transferring it down one ssh connection and up the other. So a direct connection is clearly essential, and it must be secured via encryption. Preventing others from seeing the data is the primary concern, but undetected alterations are also a concern.

The data transfer needs to be spontaneous without any complex setup to be performed, such as starting an ssh daemon. Use of root permissions is unavailable. Also, creating cross signed certificates is not practical.

I believe in this scenario, a script that sets up a networked pipeline on these two remote machines, utilizing an encryption cipher like aes-256-cbc available in a tool like openssl would be suitable. The user would provide a randomly chosen string to each remote machine where it is safe to do so, where the openssl program ends up getting that key. The data would be compressed and encrypted on the source machine, transmitted over a TCP connection to the destination machine, where it would be decrypted and uncompressed.

The question:

Is there any reason that the use of a shared secret key between these remote hosts is not appropriate? Is there any reason to justify requiring the greater complexity of setting up a public-key SSL/TLS certificate for this case?

Your entire scenario depends on the security of that key, and getting it from place to place. Maybe the SSL protocol is just what you really want. This protocol can negotiate a secure communication with anyone who wants to connect. The two parties can then authenticate themselves any way they wish over the now-secure connection.

Of course it depends on the security of the key. Any crypto system depends on the security of its keys.

But this is what I do NOT want. I do NOT want "anyone who wants to connect" to be able to, or at least able to get anything useful out of it. This is NOT a "secure web server" scenario where I let anyone have the data even though the connection is secure (security in this case serves a different purpose).

The sender needs to make sure only the authorized receiver will be able to get the data in the clear. The receiver needs to make sure only data from the authorized sender is being received. We are familiar with how that happens with SSL through use of signed server certificates and client certificates (though clients certificates are rarely used ... login passwords in an assumed MitM-safe channel are used).

But in my scenario, the SSL setup is not in place.

If the data were of a small volume, a reasonably secure scenario can be set up through SSH ... although this requires anticipation by the person that started the two SSH sessions. The SSH login to the sender host could have beenwhile the SSH login to the receiver host could have (note -R vs -L). On the receiver, the user would do while on the sender, the user would do The sender would create a tarball of data and pass it to socat which connects to localhost port 12345. Then the sshd in the remote-send host would create the ssh forwarding channel in reverse back to the client host and make a connection to port 12345 on the client. The other ssh would be listening and create the ssh forwarding channel out to the remote-recv host, and connect to port 12345 there. The socat program would be listening to port 12345 there and pass the data to the tar program in the pipeline. There are three uses of port numbers and they do not have to be the same number.

Now this is fine for cases where the data is not too small and the connections to the remotes from the client are of sufficient bandwidth.

But the scenario I explained is one where the above SSH pipelining/forwarding scheme puts too much burden on the SSH connections from the client. So I want to go direct. And I want to do it in as simple a way as possible. However, it is OK to have a script implemented to carry this out and ready to go on each remote host. Such a script is something that can be shared among the community and easily put anywhere ahead of time.

However, a certificate setup for SSL would not be so easily done on the fly.

The scenario I am suggesting is a script that can be given the cipher key on the command line or in response to a prompt. The user at the client machine can simply make up a random key and type it in on each host she is connected to when prompted (or generate something stronger and copy/paste it in). The trust relationship between the two hosts is establish by the user typing/pasting in this key, and only for the duration of time using this key.

What I see is that the above is AS GOOD AS any other trust relationship, particularly because it is a one time event and not depending on a key that is BOTH shared AND stored.

I have a little toy/tool that can make the keys for me (originally for making passwords, but it will go to an extreme if asked to):And if you don't have my tool, there is always:though it is not as strong.

Can you show how the scripts executed on the two remote hosts would establish trust in a simple way so the user only needs to run one command on each end? I do not think this is possible.

You're proposal is essentially the classic establish a secure channel (usually using asymmetric keys, here via ssh which may also use asymmetric keys) and distribute a shared session key over it. SSL does something similar.

I would suggest having the script generate a random key, don't leave it up to the user. The user shouldn't need to generate the session keys any more than they do for the ssh or SSL session keys.

Yes, that seems what it is. Except that the "distribute" part as it applies to the "SSL does something similar" is at best awkward. It might help if SSH itself (or a front end to it) would take care of that in some way.

Which script? The one on the remote sender? The one on the remote receiver?

The client machine that runs ssh to the two remotes? If I do that at the client, it will need to pass the same key to ALL the hosts (there might be hundreds, but the transfer only needs to be done by two of them, while another has been broken into).

Some mechanism for the script on the remotes to communicate back to the client and address the other remote specifically and do a key exchange that way could make more sense. It would be stronger than just a random shared string. And it could now be on the time scale as the cipher in SSL (which ultimately is a shared key of rather short duration). I could have SSH always set up a reverse channel back to a client based "key trader" server/agent.

But if I don't have that mechanism? Just how weak is it to have the user just think up a pass phrase and use that ... once?

I was thinking the script would be run from the client running ssh using a key per transfer, something like:
2 possible weaknesses occur to me:

• If the user is actually just thinking up a pass phrase they might choose a dictionary word, or reuse an old password. If you have very security conscious users (does that ever happen?) using mkpw 72 you're probably fine.
• The bad guy asks for the password

The password usage would be to give it to the program doing the encryption, and likewise the one doing the decryption. The "openssl" program might prompt for it but that is within the ssh session, not some web site being accessed. If the MitM is in your ssh session, you have other issues to deal with, first.

Here is what I've put together so far around this idea:
http://wiki.slashusr.net/documentation/scripts/cpionet
http://wiki.slashusr.net/documentation/scripts/tarnet

What I am thinking of changing is to have one end generate a random password and output that with instructions to copy it to the other machine. The listen side needs to be run first, so that's where it would be generated.

I was thinking more about phishing than MitM, but upon reflection it seems unlikely given the way passwords are being used here.

Seems a bit weird to have 2 identical-except-for-script-name pages.

I think my suggested script would be more convenient for the user (no need to copy & paste passwords), but maybe there is some limitation in your setup that prevents it from working?

Neither cpio nor tar are perfect solutions. So I made it both ways and documented each.

It depends on port forwarding, which may be disallowed in some locations (especially where they do bureaucratic security over technical security).

Maybe you could combine the documentation pages? Or maybe you could actually combine the command: instead of cpionet and tarnet, have one command that takes cpio or tar as an argument.


I don't think that's the case.

Please bear in mind that the SSL/TLS protocol does not have to be "open." It does support certificate-based client authentication.

It's also not the only secure-tunnel protocol out there. VPN of course is another. SSH tunneling is a distant third.

In any case, you want to use an existing, well-understood industry standard tunneling protocol, which is easily supported by your hardware. You don't want to roll your own. Once you have established the secure connection, the two sides must still authenticate with one another. Then, they can exchange information through whatever methods you please, all through the secure tunnel which neither of them has to secure further.

I invariably and strongly encourage a certificate-based approach, and here's an easy example why. When you go into your workplace, there's no one there saying, "say the magic word." No, you swipe your badge. You can't copy the badge. If you lose it, or get fired or whatever, that specific badge immediately is made useless. No one else is inconvenienced. The company can specify exactly what that unique badge is good for, and can easily change that profile at any time.

Password-protected certificates are strong additional protection because they are based on strong encryption of the key contents. But you still have to possess a valid, one-of-a-kind key, in addition to having the means to unlock it.

Is that because of its use of TCP?

I have not seen existing software that applies to my use case. Nevertheless, what I have put together uses openssh encryption. The data is encrypted, so it cannot be spied on. The data must be decrypted to be useful to whoever gets it. A MitM attack is just a DoS attack (and not DDoS).

That doesn't match my use case. I'm not going to analyze that example as to whether that is a use case for certificate-based ... I'll just assume it is. But it only shows there is at least one use case for a certificate-based approach (I know there are many). But I don't see where the one I'm trying to do is.

Yes. So how would the quickie large file transfer case work with clients to 2 remotes?