- Many steps from the below recipe have been taken from Building Linux VPN's. For more indepth information read chapter 4, of this book.
- In order to keep everything isolated, I created a new user/group (sslvpn/sslvpn) on mia and zidler.
Instructions for creating users using command line options can be found
here.
I have set up passwordless login using SSHv2. PLease refer to
this document for the HowTo.
- It is better to set up your own CA (Certificate Authority) that will grant and sign certificates. However this is
not entirely necessary, and this step can be omitted. But I have preferred to use it and all further
steps will assume the existence of a CA. Instructions to create your very own CA, that can sign and approve user
requested certifcates can be found
here.
Make sure that you copy the CA's very own certificate
to a known directory.I have kept all such certificates in $HOME/certificates.
- The SSL user (sslvpn) that creates a VPN must request a certificate and get it signed by the CA.
PLease remeber that the private key must not be protected by a password..
Instructions for users to create such keys can be found in Step 8, 9, 10 of
this document.
- I am asssuming that we are using the following setup. mia
as the client and zidler as the server .
- When the user generates a request for the certificate he also generates a private key.
At the client i have named this private key as $HOME/certificates/client.pem.
Similarly at the server, I have named it as
$HOME/certificates/server.pem (on every machines that act as servers).
When the CA signs the certificate and sends it to the client user (client.cert, say), I keep it in the same directory,
i.e. $HOME/certificates. In addition I also download the CA certificated using
wget http://mia.ece.uic.edu/~papers/bin/cacert.cer and place it in the same directory.
Thus a listing of $HOME/certificates on both client and server leads to:
sslvpn@mia:~/certificates> ls -al total 24 drwxr-xr-x 2 sslvpn sslvpn 4096 Jul 8 15:07 . drwx------ 9 sslvpn sslvpn 4096 Jul 8 14:56 .. -rw-r--r-- 1 sslvpn sslvpn 1407 May 16 14:28 cacert.cer -r-------- 1 sslvpn sslvpn 1151 May 16 14:28 client.cert -r-------- 1 sslvpn sslvpn 887 Jul 8 15:06 client.pem -------------------------------------------------------------------- sslvpn@zidler:~/certificates> ls -al total 28 drwxr-xr-x 2 sslvpn sslvpn 4096 Jul 8 15:08 . drwx------ 7 sslvpn sslvpn 4096 Jul 8 14:55 .. -rw-r--r-- 1 sslvpn sslvpn 1407 May 16 14:30 cacert.cer -r-------- 1 sslvpn sslvpn 1155 May 16 14:30 server.cert -r-------- 1 sslvpn sslvpn 887 Jul 8 15:08 server.pem
Note the permissions on the keyfiles (server.pem and client.pem) - If you don't intend to work as root, then
set up SUDO, so that you can start pppd as a different user. In
order to configure sudo, ONLY USE
visudo. Set up the EDITOR environtment variable to pico using the command
mia#>setenv EDITOR pico mia#>visudo
The sudoers file is listed below. More advanced options for sudo can be found here# sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification Cmnd_Alias VPN=/usr/sbin/pppd, /bin/kill, /sbin/route # Defaults specification # User privilege specification root ALL=(ALL) ALL # Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL # Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now sshvpn ALL=NOPASSWD: VPN sslvpn ALL=NOPASSWD: VPN
- Check the version of Stunnel.
There is a vast different between 3.x and 4.x. I am using 4.x. Hence, if you
are using 3.x consider upgrading to 4.x.
- stunnel requires a configuration file. Since we will be setting up PPP over SSL tunnel, the configuration file
is different at the client and server. Below are some example config files.
Please take time to read the manpages
for stunnel. I have populated this config files in the startup scripts, discussed in the next point.
################################################################# sslvpn@zidler:~> cat stunnel.conf #This is the certificate file signed by the CA and sent back to us. cert = /home/sslvpn/certificates/server.cert #This is the file for our provate key. It should have permission of 400. key = /home/sslvpn/certificates/server.pem # Name of Pid file that is created. pid = /home/sslvpn/bin/stunnel-vpn1.pid # Authentication stuff (Use 2, use man stunnel to find out why). # verify = 2 #The directory where all the certificates can be found CApath = /home/sslvpn/certificates #The CA certificate file. This is the CA's certificate that is available to the public. CAfile = /home/sslvpn/certificates/cacert.cer # Some debugging stuff debug = 7 #output = /home/sslvpn/stunnel.log # Use it for client mode client = no foreground = yes #Protocol Specific options #ciphers = DES-CBC3-SHA:IDEA-CBC-MD5 # Service-level configuration [vpn] accept = 9871 #connect = zidler.ece.uic.edu:9871 exec = /usr/bin/sudo execargs = /usr/bin/sudo /usr/sbin/pppd debug noauth 192.168.254.254:192.168.254.253 pty = yes ################################################################################### ################################################################################### sslvpn@mia:~> cat stunnel.conf cert = /home/sslvpn/certificates/client.cert pid = /home/sslvpn/temp #key = /home/sslvpn/certificates/client.pem verify = 3 CApath = /home/sslvpn/certificates CAfile = /home/sslvpn/certificates/cacert.cer debug = 7 #output = /home/sslvpn/stunnel.log client = yes foreground = yes #Protocol Specific options #ciphers = DES-CBC3-SHA:IDEA-CBC-MD5 # Service-level configuration connect = zidler.ece.uic.edu:9871 ###################################################################################
- Note the option ciphers is used to specify a cipher suite.
A cipher suite consists of algorithms that cover 4 functions:
- Signing/Authentication
- Key Exchange
- Cryptographic hashing
- Encryption/decryption
sslvpn@mia:~/bin> openssl ciphers -v -ssl3 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 --SNIP--
Since I use public key, i will have to select algorithms that have Kx=RSA. If i want to use Kx=DH, I will somehow have to find out a way to share a secret key. - I have modified the following scripts (that came with the linux VPN book)
according to my personal requirements.
If you need the original scripts, please visit the author's
web site.
Additionally use man stunnel to know about the various options used.
However these scripts have to be executed in a particular order as indicated below: All scripts are placed in $HOME/bin.- Execute the following command to start the server. This will create a log file in $HOME/bin/stunnel.log
sslvpn@zidler:~/bin> ./ppp_over_ssl_vpn_server start vpn1
- Execute the following to start the client.
sslvpn@mia:~/bin> ./ppp_over_ssl_vpn_client start vpn1
- use "ifconfig" to see if a new ppp interface "ppp0" has been set up. For e.g.
sshvpn@mia:~/bin> ifconfig ---SNIP--- ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.254.253 P-t-P:192.168.254.254 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:66 (66.0 b) TX bytes:72 (72.0 b) - Use "netstat -rn" on both the client and the server machine to verify that the routing tables are updated.
For e.g. (Entries of interest are marked with ***)
sshvpn@mia:~/bin> netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.254.254 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0*** 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.1.0 192.168.254.254 255.255.255.0 UG 40 0 0 ppp0*** 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 40 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 131.193.50.1 0.0.0.0 UG 40 0 0 eth0 ------------------------------------------------------------------------------ sshvpn@zidler:~> netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.254.253 0.0.0.0 255.255.255.255 UH 40 0 0 ppp0*** 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.0.0 192.168.254.253 255.255.255.0 UG 40 0 0 ppp0*** 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 131.193.50.1 0.0.0.0 UG 40 0 0 eth0
- use "iptables" to verify that the forward chain has default behaviour of accept. If this is not set
then u will not be able to ping from one network to another. For e.g.
[sshvpn@mia bin]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT)*** target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere LOG all -- anywhere anywhere LOG level warning ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere LOG all -- anywhere anywhere LOG level warning Chain OUTPUT (policy ACCEPT) target prot opt source destination
- Finally use "ping" to check the connectivity.
- Execute the following command to start the server. This will create a log file in $HOME/bin/stunnel.log
- Finally to remove the connection use the following commands (in this sequence.
sslvpn@mia:~/bin> ./ppp_over_ssl_vpn_client stop vpn1
sslvpn@zidler:~/bin> ./ppp_over_ssl_vpn_server stop vpn1
NOW BEGINS THE EXPERIMENTATION
- The below diagram traces the path taken by a packet as it travels over the ppp-over-ssl tunnel.
- Each layer of protocol adds some bytes of overhead. This is illustrated in the above diagram. Note that
the SSL layer, has been shown to add "X" bytes of overhead. I am using
OpenSSL(0.9.6b and 0.9.7a) implementation for the SSL protocol.
To find out the overhead added by the SSL layer, one needs to read the standards published by netscape here. Also more information can be found out at this site. - I have put up a small note about SSL handshake procedure. This gives the reader a gentle introduction to how SSL clients and server's actually negotiate. You can find this note here.
- You will find that SSL bundles packet as:
1-byte packet_type (Handshake, application_data etc). 2-byte Version number (major(1B), minor (1B)) 2-Byte packet length n1-byte payload; m-byte MAC (message authentication code); e.g. SHA1 (20 Bytes), MD5 (16 Bytes) n2-byte random padding; to make [payload + MAC + paddin_lenght + padding] a multiple of block_size used by the cipher. (4 to 255 Bytes) 1-Byte padding_length (Hence one can add a maximum of 255 bytes of padding. - I found the below example from
RFC2246 to calculate the overhead,
which I reproduce below (with some modifications):
Dierks & Allen Standards Track [Page 19] RFC 2246 The TLS Protocol Version 1.0 January 1999 --SNIP-- Example: If the block length is 8 bytes, the content length is 61 bytes, and the MAC length is 20 bytes, the length before padding is 82 bytes (content_length(61) + MAC(20) + padding_len(1)). Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC. --SNIP-- - To use SSL, one needs to select a cipher suite, which includes algorithms for Key exchange (RSA, DSA etc.),
Authentication (RSA, DH etc.), Encryption (AES, DES etc.) and MAC (SHA, MD5 etc.).
One can find all the availavle cipher suites, by executing the following command:
sslvpn@mia:~/bin> openssl ciphers -v -ssl3 HIGH ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 KRB5-DES-CBC3-MD5 SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=MD5 KRB5-DES-CBC3-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=3DES(168) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1
To select a particular cipher suite in stunnel, include the following line in stunnel.conf.--SNIP-- ciphers = AES128-SHA:ADH-AES256-SHA --SNIP--
- Let us assume that we are using AES256-SHA. Suppose that the input to the SSL layer is
a packet of length 144 bytes, then you can calculate the total overhead added by SSL as follows:
- Add 20(MAC) + 1(padding_len) = 5 Bytes to Packet. This gives 144 + 21 = 165.
- Find out what block size is used by the cipher. In our case, since we are using aes128-cbc, the block size is 16 bytes.
- Calculate 165 % 16 = 5. Hence in order to make the packet an even multiple of 16, you will have to add either 11 bytes (to make it 176) or 27 bytes (to make it 192) etc. of padding. The exact amount of padding added is random, but the minimum is 4 bytes and maximum is 255 bytes.
- In this case, let us assume that we have added just 11 Bytes to make the packet to be of length 176 bytes, which is an even multiple of 16.
- Now add the 5 byte header (type(1) + version(2) + len(2)).
- Thus we have a total packet size of 181 Bytes.
- Thus we conclude that the SSL layer adds a minimum of (5(header) + 16(MAC:MD5) + 4(padding) + 1(padding len) = 26 bytes) and maximum of (5(header) + 20(MAC:SHA1) + 255(padding) + 1(padding len) = 281 bytes).
- Assuming no compression mechanism is used in PPP or SSL (NULL by default),
we conducted a series of experiments
with random packet sizes (and cipher suite AES256-SHA)
and measured the packet length on the wire. The experimental results are
provided below:
----------------------------------------------------- Application Data on wire Overhead Data (no comp) ----------------------------------------------------- 100 268 168 275 444 169 350 524 174 502 684 182 613 796 183 750 924 174 849 1036 187 917 1100 183 1010 1196 186 1200 1388 186 ----------------------------------------------------- Average Overhead: 179.4 -----------------------------------------------------
- I used a very versatile program called ethereal to sniff the packets on the wire and modudpgen to generate the random data.
- Stunnel does not support any compression mechanism. However,
I have enabled full compression at the PPP layer. This can be done by NOT specifying
the following options to ppp (both client and server)
noccp novj novjccomp nopcomp noaccomp
- The input data for this experiment was totally random. An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qAs said, this data was generated using modudpgen, a synonym for Modified UDP generator. - Using compression, it is not possible to estimate the amount of overhead, as the amount of compression
really depends on the entropy in the data. It is entirely possible for the data on the wire to be lesser
in size to the input data. My results are presented below:
----------------------------------------------------- Application Data on wire Overhead Data (no comp) ----------------------------------------------------- 100 236 136 275 404 129 350 468 118 502 588 86 613 692 79 750 804 54 849 884 35 917 948 31 1010 1020 10 1200 1180 -20 ----------------------------------------------------- Average Overhead: 65.8 -----------------------------------------------------
- PPP-over-SSL VPN tunnels, do not have inbuilt routing mechanisms. As a result the user
has to take care of establishing routes to remote networks. This can be done in the following two ways:
- Static routes can be set up within the script itself (as we have done) using the command:
route add -net network/netmask gw gateway-ip
Although this method is simple for small networks, it becomes exceedingly difficult to maintain such routes one your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network. - Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.
- Static routes can be set up within the script itself (as we have done) using the command:
- Stunel uses the cryptographic functions provided by your SSL implementation. Hence, if one needs to add
his own plugin-algorithm, one has to look for plug-in support in the SSL implementation that he is using.
Currentlty, I am using OpenSSL implementation of SSL, which AFAIK does not yet support any plugin algorithms to be used. However there is always the option of patching the source code itself with new algorithms and recompilation.
- The PPP-over-SSL solution for forming VPN's is highly unscalable.( This might not be true)
- For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.