Thursday, June 6, 2013

Authenticating an Stunnel server to an Stunnel client

Stunnel can take care of our network encryption needs for any TCP connection. I blogged about setting this up here. Stunnel makes use off SSL certificates which enables us to achieve these 3 main things, 1. Authentication, 2, Confidentiality and 3, Integrity. If you referenced my first post about stunnel, you may or may not have realized that i did not make use of the "authentication" feat of SSL. In this post, i aim to achieve that.

Essentially, the client will be able to connect to the server and verify that it's indeed connected to the correct server. By default the client will communicate with any stunnel server and accept the server's certificate without taking extra steps to verify it. What this means is that a malicious person can potentially setup a rogue stunnel server with their own certificate and pose as a ligitimate server. Because your client accepts everything blindly, it will make the assumption that it is connected to the right server, when indeed it might  not be. Lets fix that.

Step 1. Generate private key, certificate and PEM file.

# openssl genrsa -out server.key 2048
# openssl req -new -x509 -nodes -days 365 -key server.key -out server.crt
# cat server.key server.crt > server.pem
# chmod 640 server.pem
# chmod 640 server.key

Step 2. Run stunnel server.

# stunnel -f -d 443 -r 127.0.0.1:80 -p server.pem -s nobody -g nogroup -P /tmp/stunnel.pid

Step 3. Copy ONLY server.crt file to clients that would be connecting to the stunnel server. The server.pem and server.key file MUST be kept secret at all times.

Step 4. Run client with extra option -v 3 to enable certificate verification via locally installed cert.

# stunnel -c -f  -d 443 -r remote.server.com:443 -v 3 -A server.crt

Thats it.

If a malicious person tries to impersonate your server,it will fail to pass these checks:

1. When the initial connection between client and server is made, the server sends its certificate to the client. The client would only accept this certificate if it is within it's white list of certs "-A option".
2. If for some reason the malicious person was able to have the server send the correct cert, the client would challenge the server to prove that it has the matching private key for the cert. Because the malicious user does not have the private key and is unable to prove that it does, the client will terminiate the session.

Here is a screenshot of what things look like on the client under normal working conditions.



Here is a screenshot of what will happen on the client if a malicious server is used to impersonate a legitimate one.



The way we have setup stunnel we achieve the three main goals of SSL certificates.

1. Authentication. Server authenticates itself to the client before communication is established.
2. Confidentiality. Session is encrypted using symmetric cryptography.
3. Integrity. Ensures that the encrypted data has not been tampered with via a negotiated hashing algorithm.

No comments:

Post a Comment