SPipe

A secure web tunnel method                        Spanish

 

                                                                                    Rubén Cisneros <cisneror at tb-solutions.com>

                                                                                   Pablo J. Royo <royop at tb-solutions.com>

1.      Description of SPipe

2.      An example

3.      Requirements of Spipe

4.      Installation of SPipe

5.      Apache directives  

6. Creation of a telnet pipe using two web servers

7.      Experimental solutions and Internals

8.      References

9.      Greetings

 

DOWNLOAD:         patch_SPipe_0.1.4.gz                README.SPipe

 

SOURCEFORGE PAGE: http://sourceforge.net/projects/spipe/

 

CONCRETE EXAMPLE: Making POP3 & SMTP secure pipe (in Spanish)

 

CONCRETE EXAMPLE 2: Making VNC or Terminal Server secure pipe 

 

 

                                           

 

 

1.      Description of SPipe

 

SPipe (“Secure Pipe”) is an extension of the mod_ssl package, which allows users to obtain the functionality of a web server and a tunnel to another server.

 

It is a simple solution, which allows the same corporate web server to be used as a secure access door to internal servers that do not use HTTPS protocol, while also retaining its normal web server functionality for all HTTP requests.

 

Its characteristics are the following:

 

·        It allows redirecting secure non-https protocols to another specified non-secure service, deciphering SSL input protocol and sending the plain text protocol to selected service.

·        It allows usage of a unique input secure port to access the corporate net.

·        It allows decryption of input protocol, and forwarding of it ciphered with another different key to other service behind the web server.

·        It allows viewing of headers from input https protocol.

·        It allows enabling of other ports using virtual-host, does it can serve a lot of different applications using secure protocols with only one Apache server.

·        It allows create a secure communication pipe, using SSL, between a client and a server that don’t talk SSL, creating a secure communication channel outside the corporative net of the client and of the server.

·        It allows configuration of the server to redirect, depending on the input protocol,  some protocols (EXPERIMENTAL).  

 

This is a simple solution which allows using the corporate web server of a company as a secure access door to internal servers which does not use HTTP protocol, and at the same time, it allows normal web server functionality for all HTTP requests.

 

Last patch version (v.0.1.2) works in UNIX environments but also in WIN32 environments. Althougth this patch is only operative for version 2.8.16 of mod_ssl which runs under version 1.3.29 of Apache.

 

2.      An example

 

For example, it is possible to download mail in a secure maner from a mail server, located behind the web server, which does not use a secure protocol (SSL) to serve messages. It is the same for any non-HTTP protocol.  

 

 

In this example, the user has a SSL enabled mail client. The web server does the initial SSL handshake and decrypts the protocol, forwarding the plain protocol packages to the POP3 service to download the e-mail messages.

 

An Apache configuration for this could be the next. Observe that we are using same web server port used to serve HTTPS requests (443) using a virtual host:

 

 

As we can see, it is not required to create and configure a certificate for the POP3 mail server, and in spite of this, the download has been secure.

 

If we want also to send messages to a SMTP server we must use another port, because 443 is already used by POP3 for non-HTTP requests. This way, we could receive and also send mails in a secure manner through the web server, but we need to open another port in the firewall (4433 in this example) and configure other virtual host. In this case, we would add to the configuration:

 

 

But the main advantage, is that if your service use only one port, all communications are being transmitted through the corporate web server, making it not necessary to have a different service in another port or URL. Therefore,  you do not need to open or configure more ports or IPs in the firewall. This is the main difference with the open source package, STunnel. You can use SPipe with more ports, but you will have to open them in firewall and configure them as virtual hosts.

 

If you have a web server running in a port, it is only necessary to recompile mod_ssl package after applying SPipe patch, without reconfiguring or recompiling the Apache core.

 

3.      Requirements of Spipe

 

As a main requirement, SPipe needs Apache core to be compiled with Extended API (EAPI). This is a non-restrictive requirement, because having mod_ssl already installed in Apache implies that it has already been compiled with EAPI. Thus, it is not required to recompile the Apache core, if you are using mod_ssl.

 

The remote server you are going to connect must use a pure SSL protocol (or a protocol without SSL). Thus, SPipe does not work to redirect traffic to servers using other secure protocols, such as SSH, because they use an exclusive secure connection protocol, which has nothing to do with SSL.

 

4.      Installation of SPipe

 

SPipe requires Apache was installed with mod_ssl package enabled. Thus, in systems without Apache it is necessary to configure and compile it. To indicate steps to go, we use the following tags:

 

EU.................. Command has to be run by citizens of a European state ONLY

ALL................ Command has to be run by ANYONE, independent of location

OPTIONAL.... Command is optional and not really needed

SHARED....... Command is optional, but necessary to enable mod_ssl as a shared object (.so)

 

At first time we must download Apache, mod_ssl and OpenSSL sources (see references at the bottom of page), and extract them. After that we configure OpenSSL library with the following lines:

 

$ cd openssl-0.9.x                                                                    ALL

$ sh config \                                                                               ALL

> no-idea \                                                                                  EU

> no-threads \                                                                OPTIONAL

> -fPIC

 

Afterwards we configure mod_ssl package, to do this:

 

$ cd mod_ssl-x.x.x-x.x.x

$ ./configure \                                                                            ALL

> --with-apache = /path/to/apache/source \                           ALL

> --with-ssl = /path/to/openssl \                                               ALL

> --with-crt = /path/to/your/server.crt \                         OPTIONAL

> --with-key = /path/to/your/server.key \                     OPTIONAL

> --prefix = /path/to/apache \                                                   ALL

> --enable-shared = ssl \                                                SHARED

[...more mod_ssl options...]                                         OPTIONAL

 

At the end, if we want to install Apache web server we must run the following instructions:

 

$ ./configure \                                                                            ALL

> --prefix = /path/to/apache \                                                   ALL

> --enable-rule = EAPI \                                                           ALL

> --enable-rule = SHARED_CORE \                            SHARED

> --enable-module = so \                                                SHARED

> --enable-shared = ssl \                                                SHARED

[...more Apache options...]                                          OPTIONAL

 

Now we only have to install SPipe. SPipe installation is simple; you only have to apply the SPipe patch to mod_ssl source code.  To do this, you have to type the next line:

 

$ cd apache_x.x.x/src/modules/

$ patch < patch_SPipe_x.x

            or

$ patch –i patch_SPipe_x.x

 

Now, you have to compile the package with “make”:

 

$ cd ssl

$ make

 

In the end, you have to copy the shared object created (libssl.so) to the Apache directory and restart the Apache daemon. This is done with:

 

$ cp libssl.so /path/to/apache/libexec

$ /path/to/apache/bin/apachectl stop

$ /path/to/apache/bin/apachectl startssl

 

 

 

5.      Apache directives

 

SPipe’s way of running is very simple. It uses some Apache configuration variables that allow setting SPipe configuration parameters. These directives are applied in the same way to the other mod_ssl directives are applied . That is, in the same section of the configuration file httpd.conf which has already been configured.

 

These directives are introduced inside a virtual-host, so we could have different virtual-host sections, each one for each service which serves a different secure protocol. These configuration variables are the following:

 

·        SSLSPipeUrl <host:port> : This directive allows indicating the destination server and port to which it will connect to, in case the request is not HTTP. 

·        SSLSPipeShowHeaders : It serves to trace request http headers in Apache error log file. In this way we can have a traffic control of the request to the web server, should we have need for this.

·        SSLSPipeInputNoSSL : This directive allows not to handle as SSL the incoming protocol.  This is usefull if you need to read incoming bytes as they arrive and then send them with SSL.

·        SSLSPipeWait <timer> : (EXPERIMENTAL) It allows setting the time, in seconds, that it is going to wait for the reception of a request message from the client. If at the indicated time no messages have arrived, SPipe connects to the server selected in the SSLSPipeUrl directive.

 

In the future, it could be possible to add to these parameters a short configuration table, able to assign a different service for each protocol, to which the connection will be redirected to, depending on the first client bytes sent. This is a experimental feature.

 

Note also, that all SSL certificates configuration directives remain as allways.

 

6. Creation of a telnet pipe using two web servers

 

Another functionality that SPipe offers is the creation of secure channels between two web servers.

 

Suppose our company need to access in a safe manner to a telnet server located behind a company delegation remote web server. Their administrators don´t allow SSH use, because they desire to open only a web server port, used to serve web content.

 

We can then enable an internal VirtualHost listener on our company, (call it A Web Server), to receive our telnet communication, and then to forward it to our company delegation on its remote web server (lets call it B Web Server).

 

That server is also SPipe enabled, so when he receives a non-HTTPS protocol he will forward to the configured server: a telnet server in this example.

 

So, this way, we will have a SSL enabled telnet sesion between our company and one of his delegations, without ussing extra public ports and with telnet users knowing nothing of certificates and SSL.

 

There is a handycup: you must do the telnet to your web server (A) host, and not to the remote server directly. So you must write its address and port, like this

 

telnet webserverA.dummy-host.com 443

 

and the host administrator will forward that to the correct address by configuring SPipe. (But,… you can also think this “feature” is a good way to control external telnets…)

 

Let´s see how this works on this drawing:

     

 

 

You must put SSLSPipeInputNoSSL in Apache A VirtualHost  configuration to avoid telnet input bytes to be handled as SSL.(He will receive telnet as such).

 

You could also apply an AllowFrom directive so that this port (lets say, 4443) is accessed only from inside adresses. You must also use SSLSPipeUrl directive to say where you want to forward that telnet, after ciphering with SSL.

 

 

Web server B will receive that telnet ciphered with SSL, so he will decipher protocol, and then (as it isn´t HTTP) will forward it to where SSLSPipeUrl says in server B  configuration.  SSLSPipeInputNoSSL will not appear in server B VirtualHost

 

You could create a pipe with more than two servers, routing in a chain the protocols.

 

 

7.      Experimental solutions and Internals

 

The key of SPipe is that it is able to distinguish the input protocol in the web server, before deciding what to do with it. This distinction is made by inspecting the protocol when you have decrypted the first received bytes.

 

To distinguish if packet is HTTP, we use directives set forth in RFC 2616, that is OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT. In case that what arrives first is any of these directives, the control is returned to the Apache core and if not, it is directed to the configuration selected server.

 

This way of operation, that allows inspection of the protocol under SSL, has the disadvantage of being only applied to protocols which initiate the connection, being clients the first to send bytes to server. This is not always the case. There are protocols in which, after doing the TCP connect ( ) system call, the client does not send anything and waits for a server response before continuing. This makes it impossible for SPipe, to know which service to connect to and redirect traffic, because it does not receive any bytes to do so.

 

These types of servers are, for example, servers that use e-mail protocols, SMTP (Simple Mail Transfer Protocol, RFC 821) and POP3 (Post Office Protocol version 3, RFC 1939). We have selected a solution that improves the speed of HTTP response from the web server. To do this, a configurable parameter is used by Apache to wait for the reception of a packet from the client. If this timeout ends, then a connection to the configured remote server is initiated, and the program continues assuming that server is correct for that protocol.

 

As we have mentioned before, the solution of waiting for a client message (after the SYN packet has arrived in connect( )), a number of configurated seconds have been selected to encourage HTTP requests, which will not be affected, because HTTP always transmits bytes. But , there could be congestion in the network and HTTP package could be late. In this case, we would connect to the configured server instead of handling the connection as a web request. For that reason, in this case, once we are connected to remote server, we will send the server response to the client, who must then send  whatever is required to the server. If the request is HTTP and arrives late, the connection with the remote server is inmediately closed. Therefore, no problem will arise due to delays.

 

As you can see, the time you are going to wait for the first client bytes is important  , and for this reason, this timeout is configurable. To reach this situation, there must been a great delay between the client connect( ) and the arrival of the first three or four bytes, and this is not usually the case, because TCP implementations tend to send maximum number of data bytes all together. A high delay, in this case, is a network problem, more than the situation here aforementioned. This type of communications would fail, in the same way that a web page download would fail, if the server does not respond in a reasonable timeframe.

 

Anyhow, this is experimental, and OpenSource. It´s up to you to use this experimental option or not.

 

8.      References

 

http://www.apache.org : Apache project web page.

http://www.mod_ssl.org :  mod_ssl (OpenSSL for Apache) web page.

http://www.openssl.org : OpenSSL web page.

http://www.stunnel.org : Stunnel package web page.

 

9.      Greetings

 

To Mayte Hurtado,  for her kind help in translation it the most of this document.

 

To all OpenSSL and mod_ssl development group, for their perseverance in a product development without which the cryptographic software would not be the same.

 

To the Apache development  group, because without their contribution, Internet would be smaller.

 

To TB-Solutions Advanced Technologies, S.L. (TB·Solutions) company, for assigning its resources to this project.

 

            And, finally to all those who believe that the only way to build an Internet  for all, is to use and foster OpenSource.