I need to secure the communication between an application (runs on any PC and has been designed for Windows) and an external device (runs on UNIX). The application is running on Windows while the device is Unix-based. I can directly influence the application, but I cannot influence the device (I have to communicate with the guy that is developing the firmware for the devices). Both sides must be on the same LAN in order to communicate with each other, but the traffic between those must be secured. There are several raw TCP-Connections as well FTP. The communication is bidirectional. There is also a directed UDP broadcast but this only happens sometimes and the sent data is not that sensitive so there is no need for protection here yet. A device can be connected to multiple hosts running the application and the application can be connected to multiple devices. I also need to make sure that no ones gets unauthorized access to the devices or manipulates data packets between the application and the devices. This means I need authorisation and integrity checks. My goal is to simply make the TCP and FTP communications inside the LAN secure. It might also be possible that users will need remote access to the devices from outside the LAN but that is a different story. For now I only want to secure the traffic that is happening inside the LAN.

So far so good. I have done some research on what security options are available. My problem appears to be pretty simple yet it seems that there are a lot of different solutions out there. Two of them appear to be suiting my problem perfectly.


As far as I know, SSH operates on the application layer whereas TLS/SSL is implemented at above the TCP layer. Does this mean that I basically need an external application that sets up a protected SSH tunnel for data communication? Do I need multiple tunnels for every connection that I am using (raw TCP, FTP)? If going for SSH, I will certainly replace FTP with SFTP. This reduces the number of open ports as far as I know since SFTP is only using one port for both control and data transfer. However, I heard that it is not possible with SFTP to limit the bandwith of the server. We need to decrease the speed at which the FTP server is sending files because the device has limited resources and the traffic might block other data. This is possible with FTP

On the other hand, there is TLS/SSL. I do not need third party programs here, but I need to take care of TLS/SSL in the application I am using itself. This means the application must be aware of encryption, as far as I know. It allows for encryption, authentification and can garantuee data integrity for the communication. Thats nice, but is it possible here to tunnel everything through one connection? (again, I have several TCP connections and FTP transfer). I could replace the FTP with FTPS, but I heard that FTPS (and FTP in general) seems to have problems with NAT or firewalls. In the future, it might be possible that someone needs to have access to the FTP-servers on the devices. However, as I mentioned before, if that happens then we will need a central access-server anyways so that shoiuld be no problem.

Ok, sorry for all the text that I am bothering you with. I am just unsure what solution fits my problem best. My goals are simply to secure the data traffic and minimize the ports that need to be open on the devices or the host which runs the application.

What can you suggest? SSH or TLS/SSL? Or maybe something completely different (like VPN)?

2 Answers 2


With SSL/TLS, you will most probably need to open several ports (one per service), and indeed FTPS (FTP over SSL/TLS) indeed may cause some issue when dealing with the data connection (port to open to establish the connection, NAT device address to take into account, etc.).

SSH might seem more suitable since it allows to open only one port:

  • SSH offers native support for SFTP and SCP protocols for file transfers (even if I'm not aware of QoS settings at this level, usually handled by the host or external devices), all within a single TCP connection (as opposed to the two TCP connections required by FTP),
  • For the Raw TCP, you may want to take a look to the SSH subsystems configuration options, mainly used to make 'sshd' to use an external program to handle SFTP requests, it can allow you to define your own supplementary subsystems corresponding to your needs,
  • And at last SSH offers tunneling facilities, to secure any kind of TCP connections.
  • Thank you for your answer. I am basically sending binary data, strings and files over the network. SSH specifies different protocols for what goes through the tunnel right? Does it mean that I have to tailor all my data so that it fits the appropriate SSH protocols? This is obviously no problem for FTP, since I can simply use SFTP, but how does it work for the arbitrary data I am sending over the raw TCP connections? I am not sending true console commands or anything else.
    – WMEZ
    Nov 13, 2013 at 12:57
  • @user34163: What I like with SSH is that it can be truly tailored to your need. Are you using your own protocol and want to secure it using SSH, as mentioned you may want to take a look into SSH subsystems facilities (for instance you have more information here), otherwise SSH tunneling will always do the trick even if it may be less efficient (need local-loop redirection on both client/server sides, this is widely documented on the Internet). Nov 13, 2013 at 14:20

I like the fact that you are looking to use existing protocols rather than trying to invent something, all too often people who post are too eager to re-invent the wheel. Neither solution you've chosen is difficult to deploy and use programmatically, windows and unix/linux have loads of support for both, and there is a massive amount of sample code to use. Given that you're on a LAN as well I am assuming there are no bandwidth or latency constraints so whether you use SSL/TLS or SFTP is entirely dependent on how your applications work:

  • If you are transferring files or groups of files from one system to another scp/sftp is a good choice. It's simple, robust, and quick
  • SSH if often used for control connections, especially if the system being controlled is a unix/linux system, it's easy to script commands to be actioned on the remote system
  • TLS is the protocol of choice if you want to use APIs for control and messaging between systems. You can also use it for data transfers. It may require more ports but you're on a LAN, so that's not an issue

So you may use one of these or a combination of them depending on what your applications are supposed to do. Regarding the security of these protocols remember these things:

  1. Key and certificate management is of primary importance to the security of these protocols
  2. Try and use native packages already existing on the OS deployments for encryption and certificate/key management, it will greatly simplify your upgrade path
  • Thanks for your answer. If using SSH that means that I can create a seperate SSH application opens a secure connection to another SSH application on the destination machine. I then forward all of my packets (raw TCP, FTP etc.) to the application, which encrypts it and sends it through the tunnel. The other side decrypts the received package and then forwards them to the corresponding service ports. Is that right? But that would mean I still would have to open up ports on the destination machine, right?
    – WMEZ
    Nov 13, 2013 at 12:54
  • You are entirely correct, whether you use SSH tunneling or SSL/TLS you will still need to have ports listening on the destination machine. SSH tunneling would make no sense in your situation and would just add complexity. If you need to limit the application to one open port you'll need to do that in the application itself.
    – GdD
    Nov 13, 2013 at 13:07
  • Since SSH is base on the application layer I should be able to (for example) create a seperate SSH-client thread (whichs runs in the background whenever the main application is running) that is doing all the SSH stuff (establish a connection, authenticate, encrypt and forward packets). Is that correct? Is there a common way to implement SSH without using some third party software? In addition to that, as far as I know, SSH specifies different data types that are sent through the tunnel. But I can basically send whatever I want through the tunnel, right?
    – WMEZ
    Nov 13, 2013 at 13:20
  • Not really @WMEZ. SSH is basically an encrypted form of telnet, it's designed to be used for secure remote administration. SCP and SFTP use SSH's transport mechanisms for file transfer. You would have an sshd running on one side and use an ssh client (or client module) on the other side to then run automated commands. I wouldn't try using SSH as a client-server protocol for API style controls, that's what SSL/TLS is for.
    – GdD
    Nov 13, 2013 at 16:08
  • I see, thanks for your answer. I'm getting the impression that TLS/SSL suits my problem better than SSH. I am sending specific TCP-packets which will be received directly by an application running on the device which then uses the packets to perform further actions. It appears to me that TLS/SSL is the better solution for this. Also with SSH I still have open ports on my devices that can be connected to without any kind of authentication. The encryption/authentication is only applied on the SSH tunnel, but it's still possible to directly connect to the open TCP ports w/o authentication.
    – WMEZ
    Nov 14, 2013 at 7:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .