Using spiped ​

Imagine this application scenario: a company has two data centers. Due to an urgent need, it requires cross-data-center access to Redis data. The application is deployed in Data Center A, while storage is in Data Center B. Direct TCP access poses a security risk, as data transmission would be exposed to the public network, increasing the risk of eavesdropping on client-server interactions.

Redis itself does not support SSL secure connections, but with SSL proxy software, we can encrypt communication data transparently, as if Redis is wearing an invisibility cloak. Spiped is one such SSL proxy software, recommended by Redis.

Spiped Principles ​

Let’s delve into the details of how spiped works. It launches a spiped process on both the client and server sides.

The spiped process A on the left receives request data from the Redis client, encrypts it, and sends it to the spiped process B on the right. Spiped B then decrypts the received data and forwards it to the Redis server. The Redis server then responds back through a reverse process to the Redis client.

Each spiped process has a listening port (server socket) to receive data and also acts as a client (socket client) to forward data to the target address.

Spiped processes must appear in pairs and use the same shared key to encrypt messages.

Getting Started with Spiped ​

To install spiped, I used Mac.

brew install spiped

For Linux, you can install it using apt-get or yum:

apt-get install spiped
yum install spiped

Use Docker to start the Redis server, ensuring to bind the local loopback address 127.0.0.1:

docker run -d -p127.0.0.1:6379:6379 --name redis-server-6379 redis

Generate a random key file:

# Random 32 bytes
dd if=/dev/urandom bs=32 count=1 of=spiped.key

Start the server spiped process using the key file, with 172.16.128.81 being my public IP address:

# -d means decrypt, -s is source listening address, -t is target forwarding address
spiped -d -s '[172.16.128.81]:6479' -t '[127.0.0.1]:6379' -k spiped.key

This spiped process listens on the public IP's port 6479 to receive data from the public network, decrypts it, and forwards it to the local loopback address port 6379, where redis-server listens.

Start the client spiped process with the key file, using 172.16.128.81 as my public IP address:

# -e means encrypt
spiped -e -s '[127.0.0.1]:6579' -t '[172.16.128.81]:6479' -k spiped.key

The client spiped process listens on the local loopback address port 6579, encrypting data received on that port and forwarding it to the server spiped process.

To start the client connection, we use Python code since it's difficult to access the host machine's loopback address from inside Docker:

import redis
c = redis.StrictRedis(host="localhost", port=6579)
c.ping()
c.info('cpu')

The client and server are now connected. If we try to directly link to the server spiped process (the encrypted port 6379), let’s see what happens:

import redis
c = redis.StrictRedis(host="172.16.128.81", port=6479)
c.ping()

The output indicates that the request was sent, but a read timeout occurred, suggesting either the server did not return data within the default timeout or it did not return the expected data.

Spiped supports multiple client connections for data forwarding but cannot simultaneously support multiple server-to-server forwarding. In a clustered environment, a separate spiped process must be started for each server node to receive messages, which can be cumbersome in operations.