Full Text Search: The Key to Better Natural Language Queries for NoSQL in Node.js
This article is dedicated to the task of securing a MySQL client-server connection using functionality provided by the Secure Shell (SSH) protocol. To be exact, the SSH tunneling concept is utilized. You first will review the steps needed to build secure MySQL client applications and implement a sample one yourself.
MySQL traffic is not the only kind of data that can be tunneled by the Secure Shell. SSH can be used to secure any application-layer TCP-based protocol, such as HTTP, SMTP, and POP3. If your application needs to secure such a protocol by tunneling it through a protected SSH connection, this article will be useful to you.
Take a look at what you have:
As you see, all the data between the application and SQL servers are transferred via the Internet "as is". Because most protocols used by SQL servers do not provide data integrity and confidentiality (and those that do, do it in a quite nontransparent way), all the transferred requests and responses may (and be sure, they will!) become visible to a passive adversary. An active adversary can cause much more serious problems—he can alter the data and no one will detect it!
SSH (Secure Shell) is a protocol that may help solve this problem. One of its outstanding features is its ability to tunnel different types of connections through a single, confident, and integrity-protected connection.
It works in the following way:
Now you do not have to worry about securing the data transferred over the Internet; SSH will handle this for you. In particular, SSH will take care of the following security aspects:
- Strong data encryption according to the latest industry-standard algorithms (AES, Twofish)
- Authentication of both client and server computers
- Data integrity protection
- Stability with regard to different kinds of network attacks
- Compression of the data being tunneled
- Complete independence of the operating system and network specifics
Tunneling (or forwarding) works in the following way:
- The SSH client opens a listening port on some local network interface and tells the SSH server that he wants to forward all connections accepted on this port to some remote host.
- When another connection is accepted on the listening port, the SSH client informs the SSH server about this fact and together they establish a logical tunnel for it. At the same time, the SSH server establishes a new TCP connection to the remote host agreed upon in Step 1.
- The SSH client encrypts all the data it receives from the accepted connection and sends it to the SSH server. The SSH server decrypts the data received from the SSH client and sends it to the remote host.
Note: The SSH client acts as a TCP server for the connections it accepts, and the SSH server acts as a TCP client for the connections it establishes to the remote host.
A single SSH connection can tunnel as many application layer connections as needed. This means that you can defend your server by moving all the listening ports (for example, database and application server ports) to a local network, leaving only the SSH port open. It is much easier to take care of a single port rather than a dozen different listening ports.