#keyexchange

First of all I like tho share how can modify the ssl encrypted protocols to non-encrypted or vica-versa. With load balancing :). And last my favorite things: combine that two method for a ssl key exchange (We will play man-in-middle, but his is very useful because the developers sometimes can`t see what  is payload in their programs).

Materials:

1. Linux: often I preferred the Debian, but in this case the Ubuntu is the better choice, because the pen package compiled with ssl support.

2. pen tcp proxy package

3. stunnel4 package

4. The certificate, the cert chain, and the key what you like to use in the ssl communication.

Scenario 1: The clients like to use ssl connections but the server can`t. But my personal favorite tcp proxy, the pen save the Christmas:

/usr/bin/pen -G certfullchain.pem -E cert.pem -K key.pem -p /var/run/pen.pid -x 500 -b 10 9443 192.168.10.10:9501 192.168.10.11:9501 

(don`t forget use the correct file path for the pem files!)

Explanation:

-G certfullchain.pem : In this file you need to store your certification trust chains (https://www.digicert.com/ssl-support/pem-ssl-creation.htm). You can leave it, but better if exist.

-E cert.pem : your signed certificate 

-K key.pem : your encryption key for the certificate

-p /var/run/pen.pid : in this file the pen store the own pid if you want to kill it

-x 500 : Max number of simultaneous connections

-b 10 : If the server dont answer then the pen wait for 10 second before the new connection request. This is useful when you run the tcp proxy as load balancer

9443 : the listener port, the pen will serve the datas here

192.168.10.10:9501 192.168.10.11:9501 : the two server which are serving the payload without encryptions. The pen have interesting functions:

can balancing between the servers, if you define control port (if you run the pen as root, the pen ignore this parameter) then you can change lot of parameters in runtime, can make statistic...  The pen use tls1 default and you can change with the -L switch but better if you don`t do that.

About the stability: in production environment I use pen for frontend ldap load balancing for Oracle ldap server and the process started two years ago. I think this is stable.

Scenario 2: Your clients can`t handle the ssl but the server support the ssl.  The solution: stunnel4 package. The distributions you can find the simple stunnel, but this configuration run with stunnel4.

In this case I use configuration file:

stunnel4 /pathtoconfig/stunnel4.conf

stunnel4.conf:

debug = info

output = /var/log/stunnel4/stunnel.log

client = yes

pid = /var/run/stunnel4.pid

[https]

accept = 192.168.10.1:11000

connect = 192.168.10.2:443

Explanation:

debug = info : The logging level to the log file (see below)

output = /var/log/stunnel4/stunnel.log

client = yes : Now the stunnel4 run as client (you could run in server mode, like the pen but I prefered the pen)

pid = /var/run/stunnel4.pid : Storing the pid, like the pen above

[https] : Section marker

accept = 192.168.10.1:11000 : In this case the stunnel4 run in the machine 192.168.10.1 and use the port 11000 for listening

connect = 192.168.10.2:443 : the SSL server ip address and port.

Of course you can change the ssl with the parameter sslVersion. Another important thing: with the SNI parameter you can connect to server with Server Name Indicator functionality. Scenario 3: Your want tho hide the server self signed certificate (or don`t want distribute into all server your private key). Solution: mix the Scenario 1 and the Scenario 2:

Changes in the configs:

pen: change the server ip address to localhost:

the last parameter : 127.0.0.1:10000

stunnel4.conf:

accept parameter: accept = 127.0.0.1:10000

That's all folks!