Securing Ordinary TCP Services Through Tunnels
Manfred BOGEN <firstname.lastname@example.org>
Many popular protocols deployed in the Internet today were designed years before security, cryptographic authentication and data encryption were an issue. Examples for such protocols are POP, telnet, X11-remote-display, and FTP. These protocols are considered insecure nowadays, and if we were living in an ideal world, they would have been replaced by more sophisticated protocols completely.
In fact, though, Internet services based on these protocols are used more than ever before, because of the widespread availability of implementations for all platforms and operating systems. A large organization or company cannot afford to discontinue services like POP or FTP, because so many of their members or employees are using them.
The solution for this dilemma is to tunnel the insecure protocols through secure channels, which are protected by strong cryptography. Even though software for this purpose is widely available already, the Secure Shell (SSH) for example, experience has shown that the concept of tunneling is not easy to understand.
In this paper, the authors will explain the concept of tunneling TCP connections through secure channels in great detail. Furthermore we will provide several examples, how tunneling can be implemented transparently for the users of a system, explain the necessary changes in the configuration of the server- and the client-side of the service, and discuss the problems that arise when tunneling is used through a firewall.
During our work in the German National Research Center for Information Technology (GMD), we have also measured the performance penalty that arises from encrypting and possibly compressing frequently occurring TCP connections and will present the results here.
The paper has been written mostly for the administrators and users of Unix and Windows NT workstations, but only very few parts actually depend on the deployed operating systems. The underlying concepts of tunneling are valid for all kinds of operating systems and software implementations.
The Internet was designed to provide a robust transmission facility of data packets that remains in operation even if parts of the infrastructure are out of service or not available. Security was not a major issue while defining the underlying protocols nor while defining many applications on top of TCP/IP.
Although the fundamental vulnerabilities of computers that are connected to the Internet have been known for a long time, the flaws have been accommodated rather than corrected. As a result, within the recent years, many cases of wide-scale security infractions have occurred.
However, many users connected to the Internet rely on services like POP, SMTP, telnet, and X11 despite their immanent security risks. Even more, without using them there would almost be no reason to connect to the Internet at all.
Security-enhanced versions are available for some of the vulnerable services, but not for all of them. In addition, they are not widespread within the Internet. One possible way to overcome these drawbacks is the use of TCP-based tunneling solutions, as described in this paper.
The paper is structured as follows: After the different types of attacks to TCP-based protocols are categorized in section 2, section 3 describes how tunnels operate in principle. Section 4 presents an overview of available software solutions. Sections 5 and 6 deal with tunneling simple and complex protocols and electronic mail. Potential problems and performance penalties stemming from using tunnels are discussed in section 7. Section 8 describes some alternative solutions to application-level tunneling while section 9 concludes the paper.
Before we take a look at the technical details, it is important to clarify the terminology used throughout this paper. The term "service" is used to denote an Internet-specific application like the exchange of electronic mail or the transfer of a file from one machine to another through the network. These services are based on specific "protocols." Electronic mail is exchanged with the Simple Mail Transfer Protocol (SMTP), and files are transferred via the File Transfer Protocol (FTP), etc.
The protocols discussed in this paper are based on TCP/IP, the protocol stack of choice in the Internet. That is, a TCP connection is opened from one machine to the other, and the protocol- or application data is transferred through it. In the Internet, other types of protocol layers exist, such as UDP or Multicast transmissions, but those are beyond the scope of this paper.
Every TCP-based service in the Internet is identified via a unique "port number." When a client initiates a connection to a server, it chooses to connect to, say, port 25 on the remote machine. According to [RFC 1700], port 25 is assigned to the SMTP protocol and thus to the service of delivering an electronic mail.
Most well-known and popular services are assigned a port number in the range from 0 to 1024, but the valid port numbers range from 0 to 65535.
Throughout our text, we will use the name of the protocol in question to denote the TCP port associated to this protocol and the service for which the protocol is deployed. Only when the context might be misleading will the accurate distinction between the service, the protocol, and the port number be made.
Many of the popular TCP-based Internet services used today were not deployed with security as a primary goal. They thus suffer from various potential security threats.
In recent years, sniffing has become a pressing problem. IP packets are transferred on a hop-by-hop basis. So, they can be intercepted by all intermediate hosts. In addition, these packets are generally transferred via broadcasting media within local networks. Thus, every host can eavesdrop on all data packets on the network it is directly attached to.
Unfortunately, almost every popular and widespread Internet service like SMTP, POP, HTTP, telnet, the r-commands, and X11 transmits its data in clear text, thus allowing eavesdropping on sensitive or private information. Even worse, many of these services rely on a password-based authentication scheme at which accounts and passwords are also transferred in clear text. In the case of POP, for example, the password is transferred every time the POP client accesses the server, which normally happens every few minutes.
Due to their passive nature, sniffers can practically not be detected. Supporting all kind of TCP/IP-based application protocols, they are quite convenient to use. They can store the intercepted information locally over a long period of time so that there is no need to initiate frequent connection requests to forward the data which could be traitorous.
After a successful establishment and authorization, an attacker can try to take over the connection. The targets of this very technical attack are terminal or login services, such as telnet. The stolen connection can then be used to initiate requests with the access rights of the originating user and to intercept the replies.
Many services require no authentication at all or rely solely on IP addresses or domain names. Quite often SMTP servers accept e-mail messages from any host without authentication. The same holds for anonymous FTP as well as Web and gopher servers (as long as they do not offer access to restricted documents). All these services are subject to command channel attacks where ordinary protocol commands are used to exploit security breaches.
Services like SMTP can also be used for data driven attacks. In the case of SMTP, the service may be subverted for mail bombing or for distributing (macro) viruses.
The rlogin and rsh services rely on trusted hosts and/or trusted users to grant access to the system without requesting a password. Also, FTP or Web servers can be configured in such a way that they allow access to restricted data to specific hosts. But relying on IP-addresses or domain names provides no real protection. IP addresses can be spoofed, and even reverse or double reverse look-ups of DNS information do not offer substantially more security because DNS entries can also be forged quite easily by an experienced attacker.
Besides passively monitoring a network (sniffing), an attacker can also manipulate transmitted datagrams or inject new ones. In general, all clear text protocols and services are vulnerable to this kind of attack.
Being able to monitor all passing traffic and to connect to a service (e.g., via IP spoofing) also opens an avenue for replay attacks where parts of an ongoing legal communication are recorded and replayed later on.
But even with a perfectly secure design, a service may suffer from implementation bugs such as a buffer overflow which may be used to gain access to the host. In the context of Web servers, poor CGI scripts which pass user-provided data to a command shell without carefully checking are wide-open avenues for attackers.
Additional security breaches may result from misconfiguration. A poor configuration of an anonymous FTP server, for example, may put the whole machine at risk.
With the launching of a denial-of-service attack, an existing service is made unavailable to its authorized users. This can be achieved by flooding the server with faked connection requests, like the popular SYN-flood attack. While the flooding takes place, the attacked host is virtually detached from the network.
Other attacks are protocol specific. SMTP messages received for local users are ordinarily stored on local disk. Hence, if a SMTP server is flooded with e-mail messages, the service can be made unavailable for other users, and in addition the local file system can be filled up entirely. But this is not a SMTP-specific problem; virtually every externally accessible service can be made unavailable by flooding it with requests.
The goal of tunneling insecure protocols is to identify networks that are assumed to be secure. A company's internal network, for example, is usually protected by a sophisticated IP packet filter or firewall software, rendering all attacks to the inside of the network unfeasible. The outside network, on the other hand, is known to be insecure.
Let us, for example, contemplate what happens when an employee of the company accesses his electronic mail at work from his private workstation through the Internet, using the insecure [POP3] or [IMAP] protocols. His user password and the contents of the e-mail are not protected and may be eavesdropped on.
This is a serious security threat not only to the privacy of the employee, but also to the security of the company and the company's internal network. Of course, eliminating this threat is simple: Just disallow the employee to read his e-mail at home by configuring the packet filter mechanism appropriately. Unfortunately this may be unfeasible as employees might be required to access their electronic mail through the Internet from wherever they are.
A secure tunnel is the appropriate solution for this dilemma. The concept of tunneling is illustrated in figure 1 below.
Using the mail-reading example from above, let us say that a user wants to read e-mail on server A, B, or C, using the insecure POP3 protocol. Instead of connecting directly to the server machine at TCP port 110, he or she opens a secure connection from the client machine to the tunnel server. This secure connection is made with a special tunneling software that features strong encryption and authentication.
The tunneling software, once started at the client machine ('Private Workstation'), listens to, say, TCP port 5000. All communication requests are forwarded through the encrypted tunnel to the tunnel server, which in turn decrypts the incoming data and forwards it to the mail server at port 110.
Now the users configure the POP3 software to connect to localhost, port 5000 and engage the mail-fetching process. The POP3 connection is now tunneled through the insecure network by the tunneling software and then transparently forwarded by the tunnel server to the mail server again.
This works as follows: Both the client and server software speak plain and insecure POP3 with each other, being completely unaware of the tunnel server and the functionality it performs. The mail-fetching process works just fine with the normal, unmodified POP3 programs.
Due to the tunnel, all data transmissions between the client machine and the tunnel server are encrypted and have been authenticated properly. The transmission between the tunnel server and the mail server is an ordinary POP3 connection, but it lies within the secure company network and can not be eavesdropped on or abused otherwise.
This approach fixes two important problems:
Various software packages exist that implement tunneling functionality. In the following sections we shall introduce the most common solutions.
The SSH is not exactly a tunneling software. In fact, the ability to tunnel connections securely is only a byproduct of SSH's other capabilities. Mainly, the Secure Shell is a replacement for the well-known telnet, rlogin, and rcp services. SSH uses strong cryptography (RSA, IDEA, 3DES, and other algorithms) and authentication to allow users to log into a Unix machine remotely. SSH's protocol protects against all attacks described in the first section. It also features the ability to open secure tunnels as described in the second section.
In our paper, we will use the SSH to demonstrate the real-world applications of tunneling connections, because it is a very sophisticated and useful tool and is available for free for Unix users.
The Secure Socket Layer Protocol, developed by Netscape, has become a de facto standard. SSL implements an additional layer between TCP and the application layers (FTP, HTTP, SMTP, etc.). Complete authentication and encryption happen in the Secure Socket Layer. To use SSL, special client and server programs are needed. The applications are not involved, there are no changes necessary, and all standard application programs will work.
SSL connections are built up in two phases. A handshake protocol is started; server and client agree on an encryption method and key. The server sends its certificate [X.509] for authentication -- optional client authentication is possible. Also, various public key encryption methods are available and different kinds of hash functions can be chosen.
After the server certificate is verified (and optionally the client is authenticated via the client certificate), an encryption method is selected. A session key is exchanged via public key encryption or token-based encryption systems. This session key can use one out of a number of secret (symmetric) key algorithms for encrypting the session.
Now phase two begins. The proper session starts, the message is fragmented into blocks, a MAC (message authentication code) is used, and the single blocks (packets) are encrypted and transmitted. On the other side the received packets will be decrypted, verified, put together, and delivered up to the higher levels. Client and server certificates use X.509. This enables a complete authentication of both client and server and guards against "man-in-the-middle" attacks. [SSL3]
Most commercially available products use 40-bit RC4 keys for session encryption. This is forced by the US encryption export laws. But there are also free products available which use strong encryption too.
A well-known application of SSL is HTTPS, but other programs like sslftp or ssltelnet are available on the Internet (see [CERT]). A widespread Web server with an optional SSL extension is the [APACHE] Web server.
The following applications for secure tunnels are real-world examples that fulfill useful functions in the authors' everyday work. We have emphasized the practical aspects of these tunneling examples and present actual implementations for the Unix operating system, using the Secure Shell, SSH.
All examples can be used in a Windows environment with the SSH, too. The differences in the SSH's user interface are trivial, as all the concepts are exactly the same.
A "simple protocol" is one that uses only one TCP connection to perform all its functionality. Most protocols used in the Internet today are of this type, and tunneling them is pretty easy, once one becomes used to the way this is accomplished.
POP3 is used to transfer electronic mail from the mail server to the local machine and is typically implemented in the mail reader. In our example, the mail server is called mail.my.org and the tunnel server is called tunnel.my.org.
Now a user wants to get his e-mail from the company mail server to his private workstation through the Internet. First of all, the tunnel needs to be opened. This is achieved by executing the following command:
$ ssh -L 110:mail.my.org:110 tunnel.my.org
The SSH will now log into the tunnel server and open the tunnel. For this to succeed, the user needs an accessible shell account on the server, into which he or she can log. This may be either a personal account or a generic account to which all employees have access. The authors recommend the use of personal accounts, because this gives more power to the server administrators to control what is occurring on their machines.
What happens now is this: When the login succeeds, SSH will start to listen to port 110 (POP3) on the local machine, that is, the private workstation of the user. Every connection that arrives there is tunneled through the secure connection to tunnel.my.org. The tunnel server will then forward the connection to the machine mail.my.org, to port 110.
So all the user has to do is to tell his mail client that the POP3 server to query for e-mail is the local machine: localhost.
The tunnel can also be tested using the command
$ telnet localhost pop3
which will be answered like this:
Trying 127.0.0.1... Connected to localhost.my.org. Escape character is '^]'. +OK QPOP (version 2.2-b7) at mail.my.org starting. \ <email@example.com>
If the tunnel works correctly, the server answering the connection will be the intended machine, even though the TCP connection was originated with localhost as target.
If the user uses the IMAP protocol, rather than POP3, the whole process is identical except for the port numbers. The command to open the tunnel is now as follows:
$ ssh -L 220:mail.my.org:220 tunnel.my.org
Of course a normal telnet session can be tunneled, too. The corresponding port is 23. So if one wants to telnet into the server server.my.org, this command will open the tunnel:
$ ssh -L 23:server.my.org:23 tunnel.my.org
To start the telnet session, execute
$ telnet localhost
Obviously, there is little point in tunneling a telnet session to a Unix server. One should rather log into that machine with the SSH directly, which is easier and adds additional benefits the SSH provides. But still there are enough machines that cannot be equipped with an SSH server, such as ISDN routers, which frequently need to be accessed with telnet.
A "complex" protocol is one that uses more than one TCP connection. A good example for this is the File Transfer Protocol (FTP) discussed below. Tunneling of complex protocols can be tricky or flatly impossible.
The FTP protocol uses two connections: a control channel and a data channel. Over the control channel, the user logs into the FTP server and browses through the available files or issues any GET or PUT commands. Once such a command has been given, the FTP server and client open up a second channel over which the actual data transmission takes place. When the file transfer is over, the data channel is closed and control is given to the control channel again.
The problem when trying to tunnel FTP is that it is not possible to predict which ports will be used for the data channel. The control channel is always opened at port 21, but the data channel may use any port that is available, and the actual number is negotiated between the client and the server on the fly.
So it is possible to tunnel the control channel, thus securing the login and password of the user. But the actual data transmission will take place without protection. Protecting the user and password information is better than nothing, but the authors recommend that one consider using the SCP tool provided in the SSH distribution, to replace FTP for file transfers completely, when sensitive data has to be exchanged.
An important feature of the graphical interface X11 is the ability to forward graphical objects, like windows, through the network to a remote machine.
Such transmissions can be secured with SSH, too, even though this is not achieved with the usual tunnel approach. The SSH login tool has a built-in X11 forwarding mechanism, which does this transparently. When logging into a remote server with the SSH, a pseudo-display is set up there and the $DISPLAY environment variable is set automatically.
As a result, all started programs will open their displays as usual, but internally, the transmission is tunneled through the connection without any further effort.
A rather unexpected, useful application of tunneling is the protection of company internal electronic mail. For the sake of the example, let us contemplate an imaginary company of the name "Big Bucks." Big Bucks has two major departments which are located in Tokyo, Japan and Birlinghoven, Germany. The corresponding Internet subdomains for each department are tokyo.big-bucks.com and birlinghoven.big-bucks.com.
Naturally, e-mail is used a lot for internal communication between the two departments of the company, but the problem is that this mail is routed through the insecure Internet and consequently is subject to eavesdropping or even modification. Because many of the employees of Big Bucks are nontechnicians, it is not suitable to enforce that all e-mail be sent encrypted.
A simple SSH tunnel between the two divisions of Big Bucks can solve this problem easily and comfortably. We describe the set-up below:
In this set-up, all company internal e-mail is transparently protected against eavesdropping or modification -- the employees of Big Bucks need not even be aware of this measure!
Practically, this set-up is realized as follows. We are assuming the standard Unix sendmail program, version 8, is installed. The tunnel is done via SSH.
Opening the required tunnels is nothing really new, so we will keep the description brief. On mail.birlinghoven.big-bucks.com, the tunnel to mail.tokyo.big-bucks.com is opened by logging into the other machine with the command
$ ssh -L 5000:mail.tokyo.big-bucks.com:25 \ mail.tokyo.big-bucks.com
The other way round is as easy:
$ ssh -L 5000:mail.birlinghoven.big-bucks.com:25 \ mail.birlinghoven.big-bucks.com
Configuring sendmail is a bit more tricky. First of all, it is essential that all machines are configured to relay all outgoing mail via the appropriate mail server. With sendmail, this can be accomplished by adding the following statement to the M4 configuration file:
On other platforms, most notably Windows, this setting has to be made in the user's mail reader (for example, Netscape), so we will not describe it here.
Now we need to configure the mail servers. Both of them use the following M4 file to create the sendmail.cf:
divert(-1) include(`../m4/cf.m4') OSTYPE(bsd4.4) MAILER(smtp) Mtsmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, T=DNS/RFC822/SMTP, A=IPC $h 5000 FEATURE(mailertable, `hash -o /etc/mail/mailertable')
This configuration file is pretty normal, except for the definition of the new mailer type "tsmtp." "tsmtp" is the ordinary "smtp" driver, included in sendmail, except for the fact that it will connect to port 5000, rather than port 25.
Please note that this sendmail still behaves perfectly normally. Mail is delivered with "ordinary" SMTP or ESMTP to the usual ports. The only addition is a mailer that uses port 5000 instead.
Now comes the crucial part: On mail.tokyo.big-bucks.com, the following file will now be installed in /etc/mail/mailertable:
and then the command
$ makemap hash /etc/mail/mailertable.db </etc/mail/mailertable
For mail.birlinghoven.big-bucks.com, the appropriate file is
All e-mail addressed to recipients outside big-bucks.com is delivered through the normal (E)SMTP client of sendmail. All other mail stays either inside the secure company network or is tunneled securely through the Internet to the other department's mail server.
There are various pitfalls that may cause trouble when using tunnels, in particular with the SSH software:
An interesting point to check is what encryption will cost. To get some ideas of how encryption slows down the transmission, we set the following experiment up:
A file of 7375432 bytes was transported between different hosts using the built-in rcp and the scp command from the ssh-distribution. The times were stopped for the whole rcp/scp command; both processes used .rhosts for login authentication.
The ssh programs were compiled without any additional optimization; we used our normal in-house network and the hosts were connected via hubs and switches. SSH was configured not to use compression. The encryption algorithm used was IDEA.
Note: SS20 = Sparc SS20 (Solaris 2.5.1), i586 = Pentium 66 MHz (Linux), i686 = Pentium Pro 200 MHz (NetBSD), ATM = 155 MBit/s
At first, the speed loss due to encryption may be surprising, but it is clear that the loss suffered from the additional encryption phase becomes more substantial the faster the network is. Practically, this is not a big problem as the average network transmission hardly exceeds the 10 MB/second rate in the Internet.
Furthermore, the choice of the encryption algorithm greatly influences the performance. IDEA is considered to be the most secure algorithm of those, available in the SSH. That's why we used it in our tests, even though it is one of the slowest, too. Other algorithms -- for example, "Blowfish" -- are known to be a lot faster, at the cost of some security.
There are two fundamentally different approaches to secure transactions through the Internet: The one we described so far is on application-level; the other one works on network-level. Both approaches have their advantages and disadvantages.
In contrast to the method described so far by encrypting complete sessions/associations between humans and applications, there is also the possibility of encrypting on packet level. A new IP packet type is added to the normal IP protocol, with security built into each packet.
IPv4 and IPv6 use two specific headers in IP datagrams to provide security services: the "IP Authentication Header (AH)" and the "IP Encapsulating Security Payload (ESP)" header. Both headers are used alternately or in combination to maintain a Security Association (SA) for each destination network or host. The SA is identified by a particular destination address and a set of security parameters (Security Parameter Index, SPI) such as authentication algorithm, encryption algorithm, or keys.
The IP Authentication Header (AH) is designed to provide integrity and authentication without confidentiality to IP datagrams. It holds authentication information for its IP datagram. It does this by computing a cryptographic authentication function like keyed MD5, DES, or CBC over the IP datagram and using a secret authentication key in the computation. The sender computes the authentication data prior to sending the authenticated IP packet. The receiver verifies the correctness of the authentication data upon reception. Certain fields needed for the transport of the datagram are omitted from the authentication calculation. Use of the Authentication Header will increase the IP protocol processing costs and the communications latency.
The IP Encapsulating Security Payload (ESP) is designed to provide integrity, authentication, and confidentiality to IP datagrams. It does this by encapsulating either an entire IP datagram (Tunnel-mode) or only the upper-layer protocol (e.g., TCP, UDP, ICMP) data inside the ESP (Transport-Mode), encrypting most of the ESP contents, and then appending a new clear text IP header to the now encrypted Encapsulating Security Payload. The encapsulating security approach used by ESP can noticeably impact network performance in participating systems, but use of ESP should not adversely impact routers or other intermediate systems that are not participating in the particular ESP association. Use of encryption will also increase the communication latency.
Several key management systems will be usable with AH and ESP, including manual key configuration. Both of these IP mechanisms can be used to increase the security provided by firewalls. Finally, the Security Parameters Indexes (SPIs) used in the IP security mechanisms are receiver-oriented, making them well suited for the use in IP multicast (e.g., MBone).
Big vendors like [INTEL98] see the Virtual Private Network Technology (VPN Technology) as a first step towards building Internet-based networking in general by enabling secure, private networking among LANs at multiple company sites. The reasons for implementing this technology are not only security requirements, but also cost, quality of service, and bandwidth issues.
Virtual Private Networks (VPNs) are implemented by encryption software used between a firewall or router and communicating entities. Because VPN software typically operates at the network level, all application protocols like "FTP," "HTTP," or "SMTP" are encrypted transparently. The firewall/router with VPN software simultaneously provides security services and encryption. LAN protocol traffic is encrypted and encapsulated in the TCP/IP protocol over the tunnel and then re-encapsulated in the WAN protocol being used on the real WAN link.
VPNs will play an important role in the future by enabling secure communication and cooperation in and between organizations even over insecure networks like the Internet.
"Simple Key-Management for Internet Protocols" was developed by Sun Microsystems, but the patents held by Sun were placed into the public domain, so SKIP became an open standard.
SKIP handles security over the network layer, what makes the encryption to be completely invisible for the applications and the user. All packets between two hosts will be encrypted. The IP header of SKIP packets has a protocol header field of 57, while TCP got 6 or UDP got 17 assigned by the Internet Assigned Numbers Authority (IANA). The encrypted datagrams and the SKIP header, preceded by an IP header, can be routed through every standard IP network.
The main goal of SKIP is to implement a usable key management. Each host generates his own Diffie-Hellman (see [DIFFIE]) key pair and gets the public key certified by a certification authority (CA).
Both hosts compute the same shared secret, using only the information in their own secret and the other side's public key. This shared secret will not be used to encrypt the traffic data directly. It is used as a kind of master key in the further encryption process. Each IP datagram is encrypted with a random traffic key, using lightweight symmetric algorithms like DES, RC2, or triple DES. This traffic key is encrypted with the long life shared secret using a strong symmetric encryption algorithm. The traffic key may be changed during the established connection due to a security configuration or policy. SKIP is a sessionless protocol. Asynchronous communication protocols such as UDP, ATM, ADSL, multicast traffic, or satellite links can be handled with it.
The use of certified DH keys allows host authentication. No central key management station is needed if all hosts are certified. Nevertheless, SKIP may allow (due to configuration) new stations to enter the SKIP community with dummy certificates.
There exist freely available implementations of SKIP for SunOS, Linux, and FreeBSD. Commercial implementations are available for several operation systems (see [SKIPSW]).
Network coupled security, as SKIP uses, is the conceptually superior approach when it comes to protecting everyday data transmissions over the Internet. Unfortunately it may still take several months or even years before VPN technology reaches the acceptance and sophistication required for everyday usage.
Until then, secure tunnels are a good way to protect network transmissions now. The administrative effort of opening up secure tunnels is negligible and for many applications, tunneling can be done transparently, without the user knowing about it at all.
The costs in terms of performance are acceptable, especially with the CPU power of computers growing constantly. For high-speed networks like ATM, a hardware implementation of the encryption algorithms would reduce the performance loss even further.
To sum up our experiences: There is no reason to accept the defects of insecure or older protocols, because tunnels are available now.