Imported the original site for re-publishing with ikiwiki.
[] / tunneling-ordinary-tcp-services / index.html
1 [[!meta title="Secure TCP Tunnelling with SSH"]]
2 [[!tag security]]
4 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
5 <html>
6  <head>
7   <title></title>
8  </head>
9  <body>
10   <h1 align="center">
11    Securing Ordinary TCP Services through Tunnels
12   </h1>
13   <center>
14    Manfred Bogen<br>
15    Michael Lenz<br>
16    Andreas Reichpietsch<br>
17    Peter Simons
18    <p>
19     April 17, 1998
20    </p>
21   </center>
22   <h3 class="ABSTRACT">
23    Abstract:
24   </h3>
25   <p class="ABSTRACT">
26    Many popular protocols deployed in the Internet today, have been designed
27    years before security, cryptographic authentication and data encryption was
28    an issue. Examples for such protocols are POP, telnet, X11-remote-display,
29    and FTP. These protocols are to be considered insecure nowadays and if we
30    were living in an ideal world, they would have been replaced by more
31    sophisticated protocols completely.
32   </p>
33   <p>
34    In fact, though, Internet services based on these protocols are used more
35    than ever before, because of the widespread availability of implementations
36    for all platforms and operating systems. A large organization or company can
37    not afford to discontinue services like POP or FTP, because so many of their
38    members or employees are using them.
39   </p>
40   <p>
41    The solution for this dilemma is to tunnel the insecure protocols through
42    secure channels, which are protected by strong cryptography. Even though
43    software for this purpose is widely available already, the Secure Shell
44    (SSH) for example, experience has shown that the concept of tunneling is not
45    easy to understand.
46   </p>
47   <p>
48    In this paper, the authors will explain the concept of tunneling TCP
49    connections through secure channels in great detail. Furthermore we will
50    provide several examples, how tunneling can be implemented transparently for
51    the users of a system, explain the necessary changes in the configuration of
52    the server- and the client-side of the service, and discuss the problems
53    that arise when tunneling is used through a firewall.
54   </p>
55   <p>
56    During our work in the German National Research Center for Information
57    Technology (GMD), we have also measured the performance penalty that arises
58    from encrypting and possibly compressing frequently occurring TCP
59    connections and will present the results here.
60   </p>
61   <p>
62    The paper has been written mostly for the administrators and users of Unix
63    and Windows NT workstations, but only very few parts actually depend on the
64    deployed operating systems. The underlying concepts of tunneling are valid
65    for all kinds of operating systems and software implementations.
66   </p>
67   <div align="center">
68    <b>Keywords</b><br>
69   </div>
70   <p>
71    Security, Cryptography, SSH, Unix.
72   </p>
73   <h1>
74    <a name="SECTION00010000000000000000">1 Introduction</a>
75   </h1>
76   <p>
77    The Internet was designed to provide a robust transmission facility of data
78    packets that remains in operation even if parts of the infrastructure are
79    out of service or not available. Security was neither a major issue while
80    defining the underlying protocols nor while defining many applications on
81    top of TCP/IP.
82   </p>
83   <p>
84    Although the fundamental vulnerabilities of computers that are connected to
85    the Internet were known for a long time, the flaws have rather been
86    accommodated than corrected. As a result, within the recent years many cases
87    of wide scale security infractions have occurred.
88   </p>
89   <p>
90    However, many users connected to the Internet rely on services like POP,
91    SMTP, telnet, and X11 despite their immanent security risks. Even more,
92    without using them there would almost be no reason to connect to the
93    Internet at all.
94   </p>
95   <p>
96    Security enhanced versions are available for some of the vulnerable
97    services, but not for all of them. In addition, they are not widespread
98    within the Internet. One possible solution to overcome these drawbacks, as
99    described throughout this paper, is the use of TCP-based tunneling
100    solutions.
101   </p>
102   <p>
103    The paper is structured as follows: After categorizing different types of
104    attacks to TCP-based protocols (section&nbsp;2), section&nbsp;3 describes
105    how tunnels operate in principle. Section four presents an overview about
106    available software solutions. Section five and six respectively deal with
107    tunneling simple and complex protocols and electronic mail. Potential
108    problems and performance penalties by using tunnels are discussed in
109    section&nbsp;7. Section&nbsp;8 describes some alternative solutions to
110    application-level tunneling while section&nbsp;9 concludes the paper.
111   </p>
112   <h1>
113    <a name="SECTION00020000000000000000">2 Insecure Protocols and Services</a>
114   </h1>
115   <h2>
116    <a name="SECTION00021000000000000000">2.1 What is a ``service'' in the
117    Internet?</a>
118   </h2>
119   <p>
120    Before we take a look at the technical details, it is important to clarify
121    the terminology used throughout this paper. The term ``service'' is used to
122    denote an Internet-specific application like the exchange of electronic
123    mail, the transfer of a file from one machine to another through the
124    network. These services are based on specific ``protocols''. Electronic mail
125    is exchanged with the Simple Mail Transfer Protocol (SMTP), files are
126    transferred via the File Transfer Protocol (FTP), etc.
127   </p>
128   <p>
129    The protocols discussed in this paper are based on TCP/IP, the protocol
130    stack of choice in the Internet. That is, a TCP connection is opened from
131    one machine to the other, and the protocol- or application data is
132    transferred through it. In the Internet, other type of protocols layers
133    exist, for example UDP or Multicast transmissions, but those are beyond the
134    scope of this paper.
135   </p>
136   <p>
137    Every TCP-based service in the Internet is identified via an unique ``port
138    number''. When a client initiates a connection to a server, it chooses to
139    connect to, say, port&nbsp;25 on the remote machine. According to [<a href=
140    "#rfc1700">RFC 1700</a>], port&nbsp;25 is assigned to the SMTP protocol and
141    thus to the service of delivering an electronic mail.
142   </p>
143   <p>
144    Most well-known and popular services are assigned a port number in the range
145    from 0 to 1024, but the valid port numbers range from 0 to&nbsp;65535.
146   </p>
147   <p>
148    Throughout our text, we will use the name of the protocol in question to
149    denote the TCP port associated to this protocol and the service for which
150    the protocol is deployed. Only when the context might be misleading, the
151    accurate distinction between the service, the protocol or the port number
152    will be made.
153   </p>
154   <h2>
155    <a name="SECTION00022000000000000000">2.2 Security Threats</a>
156   </h2>
157   <p>
158    Many of the popular TCP-based Internet services used today were not deployed
159    with security as a primary goal. So, they suffer from various potential
160    security threats.
161   </p>
162   <h3>
163    <a name="SECTION00022100000000000000">2.2.1 Sniffing</a>
164   </h3>
165   <p>
166    In the recent years, sniffing has become a pressing problem. IP packets are
167    transferred on a hop-by-hop basis. So, they can be intercepted by all
168    intermediate hosts. In addition, these packets are generally transferred via
169    broadcasting media within local networks. Thus, every host can eavesdrop all
170    data packets on the network it is directly attached to.
171   </p>
172   <p>
173    Unfortunately almost every popular and widespread Internet service like
174    SMTP, POP, HTTP, telnet, the r-commands, and X11 transmits its data in clear
175    text, thus allowing to eavesdrop sensitive or private information. Even
176    worse, many of these services rely on a password based authentication scheme
177    at which accounts and passwords are also transferred in clear text. In the
178    case of POP e.g. the password is transferred every time the POP client
179    accesses the server, which normally happens every few minutes.
180   </p>
181   <p>
182    Due to their passive nature sniffers can practically not be detected.
183    Supporting all kind of TCP/IP-based application protocols, they are quite
184    convenient to use. They can store the intercepted information locally over a
185    long time so that there is no need to initiate frequent connection requests
186    to forward the data which could be traitorous.
187   </p>
188   <h3>
189    <a name="SECTION00022200000000000000">2.2.2 Connection Hijacking</a>
190   </h3>
191   <p>
192    After a successful establishment and authorization, an attacker can try to
193    take over the connection. Target of this very technical attack are terminal
194    or login services, like e.g. telnet. The stolen connection can then be used
195    to initiate requests with the access rights of the originating user and to
196    intercept the replies.
197   </p>
198   <h3>
199    <a name="SECTION00022300000000000000">2.2.3 False Authentication</a>
200   </h3>
201   <p>
202    Many services require no authentication at all or rely solely on IP
203    addresses or domain names: Quite often SMTP servers accept e-mail messages
204    from any host without authentication. The same holds for anonymous FTP as
205    well as Web and gopher servers (as long as they do not offer access to
206    restricted documents). All these services are subject to command channel
207    attacks where ordinary protocol commands are used to exploit security
208    breaches.
209   </p>
210   <p>
211    In addition services like SMTP can also be used for data driven attacks. In
212    the case of SMTP the service may be subverted for mail bombing or for
213    distributing (macro) viruses.
214   </p>
215   <p>
216    The <i>rlogin</i> and <i>rsh</i> service rely on trusted hosts and/or
217    trusted users to grant access to the system without requesting a password.
218    Also FTP or Web servers can be configured in such a way that they allow
219    access to restricted data to specific hosts. But relying on IP-addresses or
220    domain names provides no real protection. IP addresses can be spoofed and
221    even reverse or double reverse look-ups of DNS information does not offer
222    substantially more security as DNS entries can also be forged quite easily
223    by an experienced attacker.
224   </p>
225   <h3>
226    <a name="SECTION00022400000000000000">2.2.4 Data Spoofing</a>
227   </h3>
228   <p>
229    Beside passively monitoring a network (i.e. sniffing) an attacker can also
230    manipulate transmitted datagrams or inject new ones. In general all clear
231    text protocols and services are vulnerable by this kind of attacks.
232   </p>
233   <p>
234    Being able to monitor all passing traffic and to connect to a service (e.g.
235    via IP spoofing) also opens an avenue for replay attacks where parts of an
236    ongoing legal communication are recorded and replayed lateron.
237   </p>
238   <h3>
239    <a name="SECTION00022500000000000000">2.2.5 Implementation and Configuration
240    Bugs</a>
241   </h3>
242   <p>
243    But even with a perfectly secure design a service may suffer from
244    implementation bugs like e.g. a buffer overflow which may be used to gain
245    access to the host. In the context of Web servers poor CGI scripts which
246    pass user provided data to a command shell without carefully checking are
247    wide open avenues for attackers.
248   </p>
249   <p>
250    Additional security breaches may result from misconfiguration. A poor
251    configuration of an anonymous FTP server e.g. may put the whole machine on
252    risk.
253   </p>
254   <h3>
255    <a name="SECTION00022600000000000000">2.2.6 Denial-of-Service Attacks</a>
256   </h3>
257   <p>
258    By launching a denial-of-service attack an existing service is made
259    unavailable to its authorized users. This can be achieved by flooding the
260    server with faked connection requests, like the popular SYN-flood attack.
261    While the flooding takes place, the attacked host is virtually detached from
262    the network.
263   </p>
264   <p>
265    Other attacks are protocol specific. SMTP messages received for local users
266    are ordinarily stored on local disk. Hence by flooding a SMTP server with
267    e-mail messages the service can be made unavailable for other users and in
268    addition the local file system can be filled up entirely. But this is not a
269    SMTP specific problem, virtually every externally accessible service can be
270    made unavailable by flooding it with requests.
271   </p>
272   <h1>
273    <a name="SECTION00030000000000000000">3 What is ``Tunneling''?</a>
274   </h1>
275   <p>
276    The idea of tunneling insecure protocols is to identify networks, that are
277    assumed to be secure. A company's internal network, for example, is usually
278    protected by a sophisticated IP packet filter or firewall software,
279    rendering all attacks to the inside of the network infeasible. The outside
280    network, on the other hand, is known to be insecure.
281   </p>
282   <p>
283    Let us, for example, contemplate what happens when an employee of the
284    company accesses his electronic mail at work from his private workstation
285    through the Internet, using the insecure [<a href="#pop3">POP3</a>] or
286    [<a href="#imap">IMAP</a>] protocols. His user password <i>and</i> the
287    contents of the e-mail are not protected and may be eavesdropped.
288   </p>
289   <p>
290    This is a serious security threat not only to the privacy of the employee,
291    but also for the security of the company and the company's internal network.
292    Of course, eliminating this threat is simple: Just disallow the employee to
293    read his e-mail at home by configuring the packet filter mechanism
294    appropriately. Unfortunately this may be infeasible as employees might be
295    required to access their electronic mail through the Internet from wherever
296    they are.
297   </p>
298   <p>
299    A secure tunnel is the appropriate solution for this dilemma. The concept of
300    tunneling is illustrated in figure&nbsp;<a href="#howdotunnelswork">1</a>
301    below.
302   </p>
303   <p>
304    <a name="31">&nbsp;</a><a name="howdotunnelswork">&nbsp;</a> <img width=
305    "527" height="371" align="bottom" alt="figure28" src="img1.jpg"><br>
306    <strong>Figure 1:</strong> How do tunnels work?<br>
307   </p>
308   <p>
309    To stick with the mail-reading example from above, let us say that a user
310    wants to read e-mail on server A, B, or C, using the insecure POP3 protocol.
311    Instead of connecting directly to the server machine at TCP port&nbsp;110,
312    he or she opens a secure connection from the client machine to the tunnel
313    server. This secure connection is made with a special tunneling software,
314    that features strong encryption and authentication.
315   </p>
316   <p>
317    The tunneling software, once started at the client machine ('Private
318    Workstation'), listens to, say, TCP port&nbsp;5000. All communication
319    requests are forwarded through the encrypted tunnel to the tunnel server,
320    which in turn decrypts the incoming data and forwards it to the mail server
321    at port&nbsp;110.
322   </p>
323   <p>
324    Now the users configure the POP3 software to connect to <tt>localhost</tt>,
325    port&nbsp;5000 and engages the mail-fetching process. The POP3 connection is
326    now tunnelled through the insecure network by the tunneling software and
327    then transparently forwarded by the tunnel server to the mail server again.
328   </p>
329   <p>
330    This works as follows: Both the client and server software speak plain and
331    insecure POP3 with each other, being completely unaware of the tunnel server
332    and the functionality it performs. The mail-fetching process works just fine
333    with the normal, unmodified POP3 programs.
334   </p>
335   <p>
336    Due to the tunnel, all data transmissions between the client machine and the
337    tunnel server are encrypted and have been authenticated properly. The
338    transmission between the tunnel server and the mail server is an ordinary
339    POP3 connection, but it lies within the secure company network and can not
340    be eavesdropped or abused otherwise.
341   </p>
342   <p>
343    This approach fixes two important problems:
344   </p>
345   <ol>
346    <li>The insecure POP3 protocol can be used in a secure fashion, using the
347    well-known software.
348    </li>
349    <li>The packet filter or firewall software, protecting the company network
350    does not need to have any holes to allow employees to read their electronic
351    mail. The packet filter needs to allow only connections to the tunnel server
352    &#8212; nothing else. And this interface is secure due to the functionality
353    of the tunneling software.
354    </li>
355   </ol>
356   <h1>
357    <a name="SECTION00040000000000000000">4 An Overview of Available Software
358    Solutions</a>
359   </h1>
360   <p>
361    Various software packages exist, that implement tunneling functionality. In
362    the following sections we shall introduce the most common solutions.
363   </p>
364   <h2>
365    <a name="SECTION00041000000000000000">4.1 Secure Shell (SSH)</a>
366   </h2>
367   <p>
368    The Secure Shell (SSH) can be found at [<a href="#SSH">SSH</a>]. Versions
369    exists for the Unix (including full source code) and Windows operating
370    system. For new users, a brief tutorial can be found at [<a href=
371    "#SSHTUT">SSH-TUT</a>].
372   </p>
373   <p>
374    The SSH is not exactly a tunneling software. In fact, the ability to tunnel
375    connections securely is only a by-product of SSH's other capabilities.
376    Mainly, the Secure Shell is a replacement for the well-known telnet, rlogin
377    and rcp services. SSH uses strong cryptography (RSA, IDEA, 3DES and other
378    algorithms) and authentication to allow users to log into a Unix machine
379    remotely. SSH's protocol protects against all attacks described in the first
380    section. It also features the ability to open secure tunnels as described in
381    the second section.
382   </p>
383   <p>
384    In our paper, we will use the SSH to demonstrate the real-world applications
385    of tunneling connections, because it is a very sophisticated and useful
386    tool, which is available for free for Unix users.
387   </p>
388   <h2>
389    <a name="SECTION00042000000000000000">4.2 Secure Socket Layer (SSL)</a>
390   </h2>
391   <p>
392    The Secure Socket Layer Protocol, developed by Netscape, has become a de
393    facto standard. SSL implements an additional layer between TCP and the
394    application layers (FTP, HTTP, SMTP, &#8230;). Complete authentication and
395    encryption happens in the Secure Socket Layer. For using SSL, special client
396    and server programs are needed. The applications are not involved, there are
397    no changes necessary and all standard application programs will work.
398   </p>
399   <p>
400    SSL connections are built up in two phases. A handshake protocol is started,
401    server and client agree on an encryption method and key. The server sends
402    its certificate [<a href="#X509">X.509</a>] for authentication &#8212;
403    optional client authentication is possible. Also, various public key
404    encryption methods are available and different kinds of hash functions can
405    be chosen.
406   </p>
407   <p>
408    After the server certificate is verified (and optionally the client is
409    authenticated via the client certificate), an encryption method is selected.
410    A session key is exchanged via public key encryption or token-based
411    encryption systems. This session key can use one out of a number of secret
412    (symmetric) key algorithms for encrypting the session.
413   </p>
414   <p>
415    Now phase two begins. The proper session starts, the message is fragmented
416    into blocks, a MAC (message authentication code) is used, the single blocks
417    (packets) are encrypted and transmitted. On the other side the received
418    packets will be decrypted, verified, put together and delivered up to the
419    higher levels. Client and server certificates use X.509. This enables a
420    complete authentication of both, client and server, and prevents against man
421    in the middle attacks. [<a href="#ssl">SSL3</a>]
422   </p>
423   <p>
424    Most commercial available products use 40-bit RC4 keys for session
425    encryption. This is forced by the US encryption export laws. But there are
426    also free available products which use strong encryption too.
427   </p>
428   <p>
429    A well known application of SSL is HTTPS, but other programs like sslftp or
430    ssltelnet are available on the Internet (see [<a href="#cert">CERT</a>]). A
431    widespread Web server with an optional SSL extension is the [<a href=
432    "#apache">APACHE</a>] Web server.
433   </p>
434   <h1>
435    <a name="SECTION00050000000000000000">5 Real-world Examples of Useful
436    Tunnels</a>
437   </h1>
438   <p>
439    The following applications for secure tunnels are real world examples, that
440    fulfill useful functions in the authors' every-day work. We have emphasized
441    the practical aspects of these tunneling examples and present actual
442    implementations for the Unix operating system, using the Secure Shell, SSH.
443   </p>
444   <p>
445    All examples can be used in an Windows environment with the SSH, too. The
446    differences in the SSH's user interface are trivial as all the concepts are
447    exactly the same.
448   </p>
449   <h2>
450    <a name="SECTION00051000000000000000">5.1 Tunneling Simple Protocols</a>
451   </h2>
452   <p>
453    A ``simple protocol'' is one that uses only one TCP connection to perform
454    all its functionality. Most protocols used in the Internet today are of this
455    type and tunneling them is pretty easy, once one got used to the way this is
456    accomplished.
457   </p>
458   <h3>
459    <a name="SECTION00051100000000000000">5.1.1 POP3</a>
460   </h3>
461   <p>
462    POP3 is used to transfer electronic mail from the mail server to the local
463    machine and is typically implemented in the mail reader. In our example, the
464    mail server is called <tt></tt> and the tunnel server is called
465    <tt></tt>.
466   </p>
467   <p>
468    Now an user wants to get his e-mail from the company mail server to his
469    private work station through the Internet. First of all, the tunnel needs to
470    be opened. This is achieved by executing the following command:
471   </p>
472   <pre>
473  $ ssh -L
474 </pre>
475   <p>
476    The SSH will now log into the tunnel server and open the tunnel. For this to
477    succeed, the user needs an accessible shell account on the server, in which
478    he can log into. This may be a personal account, or a generic account to
479    which all employees have access. The authors recommend to use personal
480    accounts, because this gives more power to the server administrators, to
481    control what is going on on their machines.
482   </p>
483   <p>
484    What happens now is this: When the login succeeded, SSH will start to listen
485    to port&nbsp;110 (POP3) on the local machine, that is the private
486    workstation of the user. Every connection that arrives there, is tunnelled
487    through the secure connection to The tunnel server will then
488    forward the connection to the machine, to port&nbsp;110.
489   </p>
490   <p>
491    So all the user has to do is to tell his mail client, that the POP3 server
492    to query for e-mail is the local machine: <tt>localhost</tt>.
493   </p>
494   <p>
495    The tunnel can also be tested using the command:
496   </p>
497   <pre>
498  $ telnet localhost pop3
499 </pre>which will be answered like this:
500   <pre>
501 Trying ...
502 Connected to
503 Escape character is '^]'.
504 +OK QPOP (version 2.2-b7) at starting. \
505         &lt;;
506 </pre>
507   <p>
508    If the tunnel works correctly, the server answering the connection will be
509    the intended machine, even though the TCP connection was originated with
510    <tt>localhost</tt> as target.
511   </p>
512   <h3>
513    <a name="SECTION00051200000000000000">5.1.2 IMAP</a>
514   </h3>
515   <p>
516    If the user uses the IMAP protocol, rather than POP3, the whole process is
517    identical except for the port numbers. The command to open the tunnel is now
518    as follows:
519   </p>
520   <pre>
521  $ ssh -L
522 </pre>
523   <h3>
524    <a name="SECTION00051300000000000000">5.1.3 Telnet</a>
525   </h3>
526   <p>
527    <a name="Telnet">&nbsp;</a>
528   </p>
529   <p>
530    Of course a normal telnet session can be tunnelled, too. The corresponding
531    port is 23. So if one wants to telnet into the server
532    <tt></tt>, this command will open the tunnel:
533   </p>
534   <pre>
535  $ ssh -L
536 </pre>
537   <p>
538    To start the telnet session, execute:
539   </p>
540   <pre>
541  $ telnet localhost
542 </pre>
543   <p>
544    Obviously, there is little point in tunneling a telnet session to a Unix
545    server. One should rather log into that machine with the SSH directly, which
546    is easier and adds additional benefits the SSH provides. But still there are
547    enough machines that can not be equipped with an SSH server, for example
548    ISDN routers, which frequently need to be accessed with telnet.
549   </p>
550   <h2>
551    <a name="SECTION00052000000000000000">5.2 More Complex Protocols</a>
552   </h2>
553   <p>
554    A ``complex'' protocol is one that uses more than one TCP connection. A good
555    example for this is the File Transfer Protocol (FTP) discussed below.
556    Tunneling of complex protocols can be tricky or flatly impossible.
557   </p>
558   <h3>
559    <a name="SECTION00052100000000000000">5.2.1 FTP</a>
560   </h3>
561   <p>
562    The FTP protocol uses two connections: A control channel and a data channel.
563    Over the control channel, the user logs into the FTP server, browses through
564    the available files or issues any GET or PUT commands. Once such a command
565    has been given, the FTP server and client open up a second channel over
566    which the actual data transmission takes place. When the file transfer is
567    over, the data channel is closed and control is given to the control channel
568    again.
569   </p>
570   <p>
571    The problem when trying to tunnel FTP is that it is not possible to predict,
572    which ports will be used for the data channel. The control channel is always
573    opened at port&nbsp;21, but the data channel may use any port that is
574    available and the actual number is negotiated between the client and the
575    server on the fly.
576   </p>
577   <p>
578    So it is possible to tunnel the control channel, thus securing the login and
579    password of the user. But the actual data transmission will take place
580    without protection. Protecting the user and password information is better
581    than nothing but the authors recommend to consider using the SCP tool
582    provided in the SSH distribution, to replace FTP for file transfers
583    completely, when sensitive data has to be exchanged.
584   </p>
585   <h3>
586    <a name="SECTION00052200000000000000">5.2.2 X11 Displays</a>
587   </h3>
588   <p>
589    An important feature of the graphical interface X11 is the ability to
590    forward graphical objects, like windows, through the network to a remote
591    machine.
592   </p>
593   <p>
594    Such transmissions can be secured with SSH, too, even though this is not
595    achieved with the usual tunnel approach. The SSH login tool has an in-built
596    X11 forwarding mechanism, which does this transparently. When logging into a
597    remote server with the SSH, a pseudo display is set up there and the
598    <tt>$DISPLAY</tt> environment variable is set automatically.
599   </p>
600   <p>
601    As a result, all started programs will open their displays as usual, but
602    internally, the transmission is tunnelled through the connection without any
603    further effort.
604   </p>
605   <h1>
606    <a name="SECTION00060000000000000000">6 Tunneling Electronic Mail</a>
607   </h1>
608   <p>
609    A rather unexpected, useful application of tunneling is the protection of
610    company internal electronic mail. For the sake of the example, let us
611    contemplate an imaginary company of the name ``Big Bucks''. Big Bucks has
612    two major departments, which are located in Tokyo, Japan and Birlinghoven,
613    Germany respectively. The corresponding Internet subdomains for each
614    department are <tt></tt> and
615    <tt></tt>.
616   </p>
617   <p>
618    Naturally, e-mail is used a lot for internal communication between the two
619    departments of the company, but the problem is that this mail is routed
620    through the insecure Internet and consequently is subject to eavesdropping
621    or even modification. Because many of the employees of Big Bucks are
622    non-technicians, it is not suitable to enforce that all e-mail is sent
623    encrypted.
624   </p>
625   <p>
626    A simple SSH tunnel between the two divisions of Big Bucks can solve this
627    problem easily and comfortably. We will describe the set-up below.
628   </p>
629   <ol>
630    <li>Each department needs a dedicated mail server:
631 and respectively.
632    </li>
633    <li>All machines are configured to deliver all non-local mail to the mail
634    server. This can be assured by blocking outgoing connections to the SMTP
635    port (25) via an IP packet filter or firewall software.
636    </li>
637    <li> and will
638    deliver outgoing mails for recipients in the Internet, or within the
639    division's network, as usual.
640    </li>
641    <li> will send all e-mail directed to the
642 division to and vice versa.
643    This delivery, though, is carried out through a secure tunnel.
644    </li>
645   </ol>
646   <p>
647    In this set-up, all company internal e-mail is transparently protected
648    against eavesdropping or modification &#8212; the employees of Big Bucks
649    need not even be aware of this measure!
650   </p>
651   <h2>
652    <a name="SECTION00061000000000000000">6.1 The Tunnel</a>
653   </h2>
654   <p>
655    Practically, this set-up is realized as follows. We are assuming, the
656    standard Unix sendmail program, version&nbsp;8 is installed. The tunnel is
657    done via SSH.
658   </p>
659   <p>
660    Opening the required tunnels is nothing really new, so we will keep the
661    description briefly. On, the tunnel to
662 is opened by logging into the other machine with
663    the command
664   </p>
665   <pre>
666  $ ssh -L \
668 </pre>and the other way round is as easy:
669   <pre>
670  $ ssh -L \
672 </pre>
673   <h2>
674    <a name="SECTION00062000000000000000">6.2 The Sendmail Configuration</a>
675   </h2>
676   <p>
677    Configuring sendmail is a bit more tricky. First of all, it is essential
678    that all machines are configure to relay all outgoing mail via the
679    appropriate mail server. With sendmail, this can be accomplished by adding
680    the following statement to the M4 configuration file:
681   </p>
682   <pre>
683 define(`SMART_HOST', `esmtp:[]')
684 </pre>or
685   <pre>
686 define(`SMART_HOST', `esmtp:[]')
687 </pre>
688   <p>
689    On other platforms, most notably Windows, this setting has to be made in the
690    user's mail reader, for example Netscape, so we will not describe it here.
691   </p>
692   <p>
693    Now we need to configure the mail servers. Both of them use the following M4
694    file to create the <tt></tt>:
695   </p>
696   <pre>
697 divert(-1)
698 include(`../m4/cf.m4')
699 OSTYPE(bsd4.4)
700 MAILER(smtp)
701 Mtsmtp,         P=[IPC], F=mDFMuX, S=11/31,
702                 R=21, E=\r\n, L=990,
703                 T=DNS/RFC822/SMTP, A=IPC $h 5000
704 FEATURE(mailertable, `hash -o /etc/mail/mailertable')
705 </pre>
706   <p>
707    This configuration file is pretty normal, except for the definition of the
708    new mailer type ``tsmtp''. ``tsmtp'' is the ordinary ``smtp'' driver,
709    included in sendmail, except for the fact, that it will connect to
710    port&nbsp;5000, rather than port&nbsp;25.
711   </p>
712   <p>
713    Please note that this sendmail still behaves perfectly normal. Mail is
714    delivered with ``ordinary'' SMTP or ESMTP to the usual ports. The only
715    addition is a mailer, that uses port&nbsp;5000 instead.
716   </p>
717   <p>
718    Now comes the crucial part: On, the following file
719    will now be installed in <tt>/etc/mail/mailertable</tt>:
720   </p>
721   <pre>
722  tsmtp:[]
723 </pre>and then the command
724   <pre>
725  $ makemap hash /etc/mail/mailertable.db &lt;/etc/mail/mailertable
726 </pre>is executed.
727   <p>
728    For, the appropriate file is:
729   </p>
730   <pre>
731  tsmtp:[]
732 </pre>
733   <p>
734    All e-mail addressed to recipients outside is delivered
735    through the normal (E)SMTP client of sendmail. All other mail stays either
736    inside the secure company network or is tunnelled securely through the
737    Internet, to the other department's mail server.
738   </p>
739   <h1>
740    <a name="SECTION00070000000000000000">7 When Using Tunnels</a>
741   </h1>
742   <h2>
743    <a name="SECTION00071000000000000000">7.1 Problems</a>
744   </h2>
745   <p>
746    There are various pitfalls that may cause trouble when using tunnels, in
747    particular with the SSH software:
748   </p>
749   <ul>
750    <li>On some machines, the SSH is compiled with the [<a href=
751    "#tcpd">TCPWRAP</a>] option included. TCP Wrapper is a program that
752    controls, who may connect to certain services on the local machine. Even
753    though this is not obvious at first, this also affects the ability to open
754    tunnels on that machine.
755     <p>
756      The tricky bit is that the SSH connection will succeed just fine and
757      everything looks okay at first. But every time someone tries to use the
758      tunnel, the connection will abort without further comment, if TCP Wrapper
759      disallows it. So if you are experiencing problems using the tunnel, it is
760      a good idea to specify the <i>-v</i> flag of SSH, when logging into the
761      remote machine.
762     </p>
763     <p>
764      This will turn the ``verbose-mode'' on, giving you a more detailed
765      description of what happens, and what does not happen.
766     </p>
767    </li>
768    <li>In the default configuration, the SSH binary will be installed with
769    owner ``root'' and the ``setuid'' bit set. This is necessary for the SSH to
770    take advantage of the common ``rhosts'' mechanism in Unix. In order to allow
771    rhosts-authentication, the client must engage the connection from a trusted
772    port &#8212; a port number lower or equal to&nbsp;1024 that is, and these
773    ports can only be used as superuser.
774     <p>
775      The problem that arises from this behaviour is that many company networks
776      are protected by a IP packet filter or firewall software and the default
777      configuration of these programs is to deny outgoing and incoming
778      connections from or to a port lower or equal to&nbsp;1024. Hence, if you
779      attempt to log into the remote machine with SSH, it will fail, even if
780      you're not using the rhosts-mechanism at all.
781     </p>
782     <p>
783      The solution is to either remove the ``setuid-root'' bit from the SSH
784      binary, or to set the following configuration options in
785      <tt>/etc/ssh_config</tt>:
786     </p>
787     <pre>
788 RhostsAuthentication no
789 </pre>Then the SSH will not use the trusted ports for outgoing connections
790 anymore.
791    </li>
792    <li>In section&nbsp;<a href="#Telnet">5.1.3</a> an example of tunneling a
793    telnet session was shown. In the example, the tunnel was opened at the local
794    machine on port&nbsp;23. This is convenient, because port&nbsp;23 is the
795    port assigned to the telnet service and hence, a simple <tt>telnet
796    localhost</tt> command would deploy the tunnel as intended.
797     <p>
798      Often this will not be possible, though, because the local port&nbsp;23 is
799      already allocated by the <tt>telnetd</tt> program, the software that
800      accepts incoming telnet connections and handles them. The same is true for
801      an attempt to tunnel a POP3 connection from the local machine to some
802      remote server, using port&nbsp;110. If the local machine supports the POP3
803      service, too, then port&nbsp;110 will be allocated already and opening the
804      tunnel will fail.
805     </p>
806     <p>
807      Fortunately the solution is rather easy. Instead of opening the local end
808      of the tunnel at the port that is commonly assigned to the service, one
809      can use a random, free port number instead, for example port&nbsp;5000.
810      The only difference in this case is that the client software, which
811      initiates the connection, must connect to port&nbsp;5000 instead, rather
812      than the port number assigned to the service usually.
813     </p>
814     <p>
815      With almost any modern client software, the port number to connect to can
816      be configured at run time, so that this doesn't pose a problem.
817     </p>
818    </li>
819   </ul>
820   <h2>
821    <a name="SECTION00072000000000000000">7.2 Costs</a>
822   </h2>
823   <p>
824    An interesting point to check is, what encryption will cost. To get some
825    ideas how encryption slows down the transmission, we set the follwing
826    experiment up:
827   </p>
828   <p>
829    A file of 7375432 byte was transported between different hosts using the
830    built-in rcp and the scp command from the ssh-distributon. The times were
831    stopped for the whole rcp/scp command, both processes used <tt>.rhosts</tt>
832    for login authentication.
833   </p>
834   <p>
835    The ssh programs were compiled without any additional optimization, we used
836    our normal inhouse network, the hosts were connected via hubs and switches.
837    SSH was configured not to use compression. The used encryption algorithm was
838    IDEA.
839   </p>
840   <div align="center">
841    <p align="center"></p>
842    <table cols="7" border frame="BOX" rules="GROUPS">
843     <col align="center">
844     <col align="center">
845     <col align="center">
846     <col align="center">
847     <col align="center">
848     <col align="center">
849     <col align="center">
850     <tbody>
851      <tr>
852       <td valign="baseline" align="center" nowrap>
853        method
854       </td>
855       <td valign="baseline" align="center" nowrap>
856        machines
857       </td>
858       <td valign="baseline" align="center" nowrap>
859        sec
860       </td>
861       <td valign="baseline" align="center" nowrap>
862        sec
863       </td>
864       <td valign="baseline" align="center" nowrap>
865        sec
866       </td>
867       <td valign="baseline" align="center" nowrap>
868        sec
869       </td>
870       <td valign="baseline" align="center" nowrap>
871        network interface
872       </td>
873      </tr>
874     </tbody>
875     <tbody>
876      <tr>
877       <td valign="baseline" align="center" nowrap>
878        RCP
879       </td>
880       <td valign="baseline" align="center" nowrap>
881        2x SS20
882       </td>
883       <td valign="baseline" align="center" nowrap>
884        5s
885       </td>
886       <td valign="baseline" align="center" nowrap>
887        7s
888       </td>
889       <td valign="baseline" align="center" nowrap>
890        6s
891       </td>
892       <td valign="baseline" align="center" nowrap>
893        6s
894       </td>
895       <td valign="baseline" align="center" nowrap>
896        ATM Class. IP
897       </td>
898      </tr>
899      <tr>
900       <td valign="baseline" align="center" nowrap>
901        SCP
902       </td>
903       <td valign="baseline" align="center" nowrap>
904        2x SS20
905       </td>
906       <td valign="baseline" align="center" nowrap>
907        27s
908       </td>
909       <td valign="baseline" align="center" nowrap>
910        26s
911       </td>
912       <td valign="baseline" align="center" nowrap>
913        29s
914       </td>
915       <td valign="baseline" align="center" nowrap>
916        27s
917       </td>
918       <td valign="baseline" align="center" nowrap>
919        ATM Class. IP
920       </td>
921      </tr>
922      <tr>
923       <td valign="baseline" align="center" nowrap>
924        RCP
925       </td>
926       <td valign="baseline" align="center" nowrap>
927        2x SS20
928       </td>
929       <td valign="baseline" align="center" nowrap>
930        9s
931       </td>
932       <td valign="baseline" align="center" nowrap>
933        11s
934       </td>
935       <td valign="baseline" align="center" nowrap>
936        9s
937       </td>
938       <td valign="baseline" align="center" nowrap>
939        9s
940       </td>
941       <td valign="baseline" align="center" nowrap>
942        ATM Lane
943       </td>
944      </tr>
945      <tr>
946       <td valign="baseline" align="center" nowrap>
947        SCP
948       </td>
949       <td valign="baseline" align="center" nowrap>
950        2x SS20
951       </td>
952       <td valign="baseline" align="center" nowrap>
953        32s
954       </td>
955       <td valign="baseline" align="center" nowrap>
956        33s
957       </td>
958       <td valign="baseline" align="center" nowrap>
959        28s
960       </td>
961       <td valign="baseline" align="center" nowrap>
962        29s
963       </td>
964       <td valign="baseline" align="center" nowrap>
965        ATM Lane
966       </td>
967      </tr>
968      <tr>
969       <td valign="baseline" align="center" nowrap>
970        RCP
971       </td>
972       <td valign="baseline" align="center" nowrap>
973        i586, i686
974       </td>
975       <td valign="baseline" align="center" nowrap>
976        9s
977       </td>
978       <td valign="baseline" align="center" nowrap>
979        13s
980       </td>
981       <td valign="baseline" align="center" nowrap>
982        15s
983       </td>
984       <td valign="baseline" align="center" nowrap>
985        8s
986       </td>
987       <td valign="baseline" align="center" nowrap>
988        10 MB Ethernet
989       </td>
990      </tr>
991      <tr>
992       <td valign="baseline" align="center" nowrap>
993        SCP
994       </td>
995       <td valign="baseline" align="center" nowrap>
996        i586, i686
997       </td>
998       <td valign="baseline" align="center" nowrap>
999        24s
1000       </td>
1001       <td valign="baseline" align="center" nowrap>
1002        23s
1003       </td>
1004       <td valign="baseline" align="center" nowrap>
1005        22s
1006       </td>
1007       <td valign="baseline" align="center" nowrap>
1008        23s
1009       </td>
1010       <td valign="baseline" align="center" nowrap>
1011        10 MB Ethernet
1012       </td>
1013      </tr>
1014      <tr>
1015       <td valign="baseline" align="center" nowrap>
1016        RCP
1017       </td>
1018       <td valign="baseline" align="center" nowrap>
1019        2x SS20
1020       </td>
1021       <td valign="baseline" align="center" nowrap>
1022        12s
1023       </td>
1024       <td valign="baseline" align="center" nowrap>
1025        17s
1026       </td>
1027       <td valign="baseline" align="center" nowrap>
1028        12s
1029       </td>
1030       <td valign="baseline" align="center" nowrap>
1031        11s
1032       </td>
1033       <td valign="baseline" align="center" nowrap>
1034        10 MB Ethernet
1035       </td>
1036      </tr>
1037      <tr>
1038       <td valign="baseline" align="center" nowrap>
1039        SCP
1040       </td>
1041       <td valign="baseline" align="center" nowrap>
1042        2x SS20
1043       </td>
1044       <td valign="baseline" align="center" nowrap>
1045        34s
1046       </td>
1047       <td valign="baseline" align="center" nowrap>
1048        31s
1049       </td>
1050       <td valign="baseline" align="center" nowrap>
1051        32s
1052       </td>
1053       <td valign="baseline" align="center" nowrap>
1054        34s
1055       </td>
1056       <td valign="baseline" align="center" nowrap>
1057        10 MB Ethernet
1058       </td>
1059      </tr>
1060      <tr>
1061       <td valign="baseline" align="center" nowrap>
1062        RCP
1063       </td>
1064       <td valign="baseline" align="center" nowrap>
1065        i586, SS20
1066       </td>
1067       <td valign="baseline" align="center" nowrap>
1068        17m11s
1069       </td>
1070       <td valign="baseline" align="center" nowrap>
1071        17m04s
1072       </td>
1073       <td valign="baseline" align="center" nowrap>
1074        17m12s
1075       </td>
1076       <td valign="baseline" align="center" nowrap>
1077        16m59s
1078       </td>
1079       <td valign="baseline" align="center" nowrap>
1080        ISDN 64 kb
1081       </td>
1082      </tr>
1083      <tr>
1084       <td valign="baseline" align="center" nowrap>
1085        SCP
1086       </td>
1087       <td valign="baseline" align="center" nowrap>
1088        i586, SS20
1089       </td>
1090       <td valign="baseline" align="center" nowrap>
1091        17m20s
1092       </td>
1093       <td valign="baseline" align="center" nowrap>
1094        16m58s
1095       </td>
1096       <td valign="baseline" align="center" nowrap>
1097        17m08s
1098       </td>
1099       <td valign="baseline" align="center" nowrap>
1100        17m12s
1101       </td>
1102       <td valign="baseline" align="center" nowrap>
1103        ISDN 64 kb
1104       </td>
1105      </tr>
1106     </tbody>
1107    </table>
1108    <p>
1109     <small class="SMALL">SS20 = Sparc SS20 (Solaris
1110     2.5.1),&nbsp;&nbsp;&nbsp;i586 = Pentium 66 MHz (Linux)<br>
1111     i686 = Pentium Pro 200 MHz (NetBSD),&nbsp;&nbsp;&nbsp;ATM = 155
1112     MBit/s</small>
1113    </p>
1114   </div>
1115   <p>
1116    At first, the speed loss due to encryption may be surprising, but it is
1117    clear that the loss suffered from the additional encryption phase becomes
1118    more substantial, the faster the network is. Practically, this is not a big
1119    problem as the average network transmission hardly exceeds the
1120    10&nbsp;MB/second rate in the Internet.
1121   </p>
1122   <p>
1123    Furthermore, the choice of the encryption algorithm greatly influences the
1124    performance. IDEA is considered to be the most secure algorithm of those,
1125    available in the SSH. That's why we used it in our tests, even though it is
1126    one of the slowest, too. Other algorithms, for example ``Blowfish'', are
1127    known to be a lot faster, at the cost of some security.
1128   </p>
1129   <h1>
1130    <a name="SECTION00080000000000000000">8 Alternative Solutions</a>
1131   </h1>
1132   <p>
1133    There are two fundamentally different approaches to secure transactions
1134    through the Internet: The one we described so far is on application-level,
1135    the other one works on network-level. Both approaches have their advantages
1136    and disadvantages.
1137   </p>
1138   <h2>
1139    <a name="SECTION00081000000000000000">8.1 IPv6</a>
1140   </h2>
1141   <p>
1142    In contrast to the method described so far by encrypting complete
1143    sessions/associations between humans and applications, there is also the
1144    possibility to encrypt on packet level. A new IP packet type is added to the
1145    normal IP protocol, with security built into each packet.
1146   </p>
1147   <p>
1148    IPv4 and IPv6 use two specific headers in IP datagrams to provide security
1149    services: the "IP Authentication Header (AH" and the "IP Encapsulating
1150    Security Payload (ESP)" header. Both headers are used alternatively or in
1151    combination to maintain a Security Association (SA) for each destination
1152    network or host. The SA is identified by a particular destination address
1153    and a set of security parameters (Security Parameter Index, SPI) like
1154    authentication algorithm, encryption algorithm, or keys.
1155   </p>
1156   <p>
1157    The IP Authentication Header (AH) is designed to provide integrity and
1158    authentication without confidentiality to IP datagrams. It holds
1159    authentication information for its IP datagram. It does this by computing a
1160    cryptographic authentication function like keyed MD5, DES, or CBC over the
1161    IP datagram and using a secret authentication key in the computation. The
1162    sender computes the authentication data prior to sending the authenticated
1163    IP packet. The receiver verifies the correctness of the authentication data
1164    upon reception. Certain fields needed for the transport of the datagram are
1165    omitted from the authentication calculation. Use of the Authentication
1166    Header will increase the IP protocol processing costs and the communications
1167    latency.
1168   </p>
1169   <p>
1170    The IP Encapsulating Security Payload (ESP) is designed to provide
1171    integrity, authentication, and confidentiality to IP datagrams. It does this
1172    by encapsulating either an entire IP datagram (Tunnel-mode) or only the
1173    upper-layer protocol (e.g. TCP, UDP, ICMP) data inside the ESP
1174    (Transport-Mode), encrypting most of the ESP contents, and then appending a
1175    new clear text IP header to the now encrypted Encapsulating Security
1176    Payload. The encapsulating security approach used by ESP can noticeably
1177    impact network performance in participating systems, but use of ESP should
1178    not adversely impact routers or other intermediate systems that are not
1179    participating in the particular ESP association. Use of encryption will also
1180    increase the communication latency.
1181   </p>
1182   <p>
1183    Several key management systems will be usable with AH and ESP, including
1184    manual key configuration. Both of these IP mechanisms can be used to
1185    increase the security provided by firewalls. Finally, the Security
1186    Parameters Indexes (SPIs) used in the IP security mechanisms, are
1187    receiver-oriented, making them well suited for the use in IP multicast (e.g.
1188    MBone).
1189   </p>
1190   <h2>
1191    <a name="SECTION00082000000000000000">8.2 VPN</a>
1192   </h2>
1193   <p>
1194    Big vendors like [<a href="#intel">INTEL98</a>] see the Virtual Private
1195    Network Technology (VPN Technology) as a first step towards building
1196    Internet-based networking in general by enabling secure, private networking
1197    among LANs at multiple company sites. The reasons for implementing this
1198    technology are not only security requirements, but also include cost,
1199    quality of service and bandwidth issues.
1200   </p>
1201   <p>
1202    Virtual Private Networks (VPNs) are implemented by encryption software used
1203    between a firewall or router and communicating entities. Because VPN
1204    software typically operates at the network level, all application protocols
1205    like ``FTP'', ``HTTP'', or ``SMTP are encrypted transparently. The
1206    firewall/router with VPN software simultaneously provides security services
1207    and encryption. LAN protocol traffic is encrypted and encapsulated in the
1208    TCP/IP protocol over the tunnel and then re-encapsulated in the WAN protocol
1209    being used on the real WAN link.
1210   </p>
1211   <p>
1212    VPNs will play an important role in the future by enabling secure
1213    communication and co-operation in and between organizations even over
1214    unsecure networks like Internet.
1215   </p>
1216   <h2>
1217    <a name="SECTION00083000000000000000">8.3 Simple Key-Management for Internet
1218    Protocols (SKIP)</a>
1219   </h2>
1220   <p>
1221    ``Simple Key-Management for Internet Protocols'' was developed by Sun
1222    Microsystems, but the patents held by Sun were placed into the public
1223    domain, so SKIP became an open standard.
1224   </p>
1225   <p>
1226    SKIP handles security over the network layer, what makes the encryption to
1227    be completely invisible for the applications and the user. All packets
1228    between two hosts will be encrypted. The IP header of SKIP packets have a
1229    protocol header field of 57, while TCP got 6 or UDP got 17 assigned by the
1230    Internet Assigned Numbers Authority (IANA). The encrypted datagrams and the
1231    SKIP header, preceded by an IP header, can be routed through every standard
1232    IP network.
1233   </p>
1234   <p>
1235    The main goal of SKIP is to implement a usable key management. Each host
1236    generates his own Diffie-Hellman (see [<a href="#diffie">DIFFIE</a>]) key
1237    pair and gets the public key certified by a certification authority (CA).
1238   </p>
1239   <p>
1240    Both hosts compute the same shared secret, using only the information in
1241    their own secret and the other side's public key. This shared secret will
1242    not be used to encrypt the traffic data directly. It is used as a kind of
1243    master key in the further encryption process. Each IP datagram is encrypted
1244    with a random traffic key, using lightweight symmetric algorithms like DES,
1245    RC2, or triple DES. This traffic key is encrypted with the long life shared
1246    secret using a strong symmetric encryption algorithm. The traffic key may be
1247    changed during the established connection due to a security configuration or
1248    policy. SKIP is a sessionless protocol. Asynchronous communication protocols
1249    as UDP, ATM, ADSL, multicast traffic or satellite links can be handled with
1250    it.
1251   </p>
1252   <p>
1253    The use of certified DH keys allows host authentication. No central key
1254    management station is needed, if all hosts are certified. Nevertheless, SKIP
1255    may allow (due to configuration) new stations to enter the SKIP community
1256    with dummy certificates.
1257   </p>
1258   <p>
1259    There exist freely available implementations of SKIP for SunOS, Linux and
1260    FreeBSD. Commercial implementations are available for several operation
1261    system (see [<a href="#skipsw">SKIPSW</a>]).
1262   </p>
1263   <h1>
1264    <a name="SECTION00090000000000000000">9 Conclusion</a>
1265   </h1>
1266   <p>
1267    Network coupled security, as SKIP uses, is the conceptionally superior
1268    approach when it comes to protecting everyday data transmissions over the
1269    Internet. Unfortunately it may still take several months or even years from
1270    now, before VPN technology reaches the acceptance and sophistication
1271    required for every-day usage.
1272   </p>
1273   <p>
1274    Until then, secure tunnels are a good way to protect network transmissions
1275    <i>now</i>. The administrative effort of opening secure tunnels up is
1276    negligible and for many applications, tunneling can be done transparently,
1277    without the user knowing about about it at all.
1278   </p>
1279   <p>
1280    The costs in terms of performance are acceptable, especially with the CPU
1281    power of computers growing constantly. For high-speed networks like ATM, a
1282    hardware implementation of the encryption algorithms would reduce the
1283    performance loss even further.
1284   </p>
1285   <p>
1286    To sum up the experiences made: there is no reason to accept the defects of
1287    insecure or older protocols because tunnels are available now.
1288   </p>
1289   <h2>
1290    <a name="SECTIONREF">References</a>
1291   </h2>
1292   <dl compact>
1293    <dt>
1294     <a name="anon"><strong>ANON97</strong></a>
1295    </dt>
1296    <dd>
1297     Anonymous: <i>Maximum Security</i>, Publishing, 1997
1298    </dd>
1299    <dt>
1300     <a name="apache"><strong>APACHE</strong></a>
1301    </dt>
1302    <dd>
1303     <i>The Apache HTTP Server Project</i>, <a href=
1304     ""></a>
1305    </dd>
1306    <dt>
1307     <a name="websecuritysourcebook"><strong>AVIEL97</strong></a>
1308    </dt>
1309    <dd>
1310     A.D.&nbsp;Rubin, D.&nbsp;Geer, M.J.&nbsp;Ranum: <i>The Web Security
1311     Sourcebook</i>, Wiley Computer Publishing, ISBN 0-471-18148-X, 1997
1312    </dd>
1313    <dt>
1314     <a name="aziz"><strong>AZIZ</strong></a>
1315    </dt>
1316    <dd>
1317     A.&nbsp;Aziz, M.&nbsp;Patterson: <i>Simple Key-Management for Internet
1318     Protocols</i>, <a href=
1319     ""></a>
1320    </dd>
1321    <dt>
1322     <a name="Caronni"><strong>CARONNI</strong></a>
1323    </dt>
1324    <dd>
1325     G.&nbsp;Caronni, H.&nbsp;Lubich, A.&nbsp;Aziz, T.&nbsp;Markson,
1326     R.&nbsp;Skrenta: <i>SKIP &#8212; Securing the Internet</i>, <a href=
1327     ""></a>
1328    </dd>
1329    <dt>
1330     <a name="cert"><strong>CERT</strong></a>
1331    </dt>
1332    <dd>
1333     <a href=
1334     ""></a>
1335    </dd>
1336    <dt>
1337     <a name="chbe"><strong>CHBE94</strong></a>
1338    </dt>
1339    <dd>
1340     W.R.&nbsp;Cheswick, S.M.&nbsp;Bellovin: <i>Firewalls and Internet
1341     Security</i>, Addison-Wesley Professional Computing Series, July 1994
1342    </dd>
1343    <dt>
1344     <a name="chzw"><strong>CHZW95</strong></a>
1345    </dt>
1346    <dd>
1347     D.B.&nbsp;Chapman, E.D.&nbsp;Zwicky: <i>Building Internet Firewalls</i>,
1348     O'Reilly &amp; Associates Inc., 1995
1349    </dd>
1350    <dt>
1351     <a name="diffie"><strong>DIFFIE</strong></a>
1352    </dt>
1353    <dd>
1354     W.Diffie, M.Hellman: <i>New directions in Cryptography</i>, IEEE
1355     Transactions on Information Theory, 1976
1356    </dd>
1357    <dt>
1358     <a name="gasp"><strong>GASP96</strong></a>
1359    </dt>
1360    <dd>
1361     S.&nbsp;Garfinkel, G.&nbsp;Spafford: <i>Practical UNIX &amp; Internet
1362     Security</i> O'Reilly &amp; Associates Inc., 1996
1363    </dd>
1364    <dt>
1365     <a name="imap"><strong>IMAP</strong></a>
1366    </dt>
1367    <dd>
1368     J.&nbsp;Rice: <i>Interactive Mail Access Protocol &#8212; Version 3</i>,
1369     RFC1203, February 1991
1370    </dd>
1371    <dt>
1372     <a name="intel"><strong>INTEL98</strong></a>
1373    </dt>
1374    <dd>
1375     <i>Enabeling Secure Virtual Private Networks Over the Internet</i>,
1376     <a href=""></a>
1377    </dd>
1378    <dt>
1379     <a name="pop3"><strong>POP3</strong></a>
1380    </dt>
1381    <dd>
1382     J.&nbsp;Myers, M.&nbsp;Rose: <i>Post Office Protocol &#8212; Version 3</i>,
1383     RFC 1939, May 1996
1384    </dd>
1385    <dt>
1386     <a name="rfc1700"><strong>RFC 1700</strong></a>
1387    </dt>
1388    <dd>
1389     J.&nbsp;Reynolds, J.&nbsp;Postel: <i>Assigned Numbers</i>, October 1994
1390    </dd>
1391    <dt>
1392     <a name="rfc1825"><strong>RFC 1825</strong></a>
1393    </dt>
1394    <dd>
1395     R.&nbsp;Atkinson: <i>Security Architecture for the Internet Protocol</i>,
1396     August 1995
1397    </dd>
1398    <dt>
1399     <a name="rfc2196"><strong>RFC 2196</strong></a>
1400    </dt>
1401    <dd>
1402     B.&nbsp;Fraser: <i>Site Security Handbook</i>, September 1997
1403    </dd>
1404    <dt>
1405     <a name="skiprev"><strong>SKIPREV</strong></a>
1406    </dt>
1407    <dd>
1408     <a href=
1409     ""></a>
1410    </dd>
1411    <dt>
1412     <a name="skipsw"><strong>SKIPSW</strong></a>
1413    </dt>
1414    <dd>
1415     <a href=
1416     ""></a>
1417    </dd>
1418    <dt>
1419     <a name="SSHTUT"><strong>SSH-TUT</strong></a>
1420    </dt>
1421    <dd>
1422     A.&nbsp;Reichpietsch, P.&nbsp;Simons: <i>Beginners guide to the Secure
1423     Shell</i>, <a href=""></a>
1424    </dd>
1425    <dt>
1426     <a name="SSH"><strong>SSH</strong></a>
1427    </dt>
1428    <dd>
1429     Tatu Yl&#246;nen: <i>The Secure Shell Home Page</i>, <a href=
1430     ""></a>
1431    </dd>
1432    <dt>
1433     <a name="ssl"><strong>SSL3</strong></a>
1434    </dt>
1435    <dd>
1436     <i>The SSL Protocol Version 3</i>, <a href=
1437     ""></a>
1438    </dd>
1439    <dt>
1440     <a name="tcpd"><strong>TCPWRAP</strong></a>
1441    </dt>
1442    <dd>
1443     Wietse Venema, <i>TCP Wrapper</i>, <a href=
1444     ""></a>
1445    </dd>
1446    <dt>
1447     <a name="X509"><strong>X.509</strong></a>
1448    </dt>
1449    <dd>
1450     ITU-T: <i>Recommendation X.509: The Directory &#8212; Authentication
1451     Framework</i>, 1988
1452    </dd>
1453   </dl>
1454  </body>
1455 </html>