Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 231:adb7ecbc92da

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
removed obsolete figure
author meillo@marmaro.de
date Sat, 10 Jan 2009 00:27:31 +0100
parents 711f0d3f5dfd
children 5cfea0d05e7f
comparison
equal deleted inserted replaced
230:35b0dfefd2c4 231:adb7ecbc92da
57 57
58 \TLS\ allows to create secure tunnels through which arbitrary programs can communicate. Hence one can add secure communication afterwards to programs without changing them. \name{OpenSSL} for example---a free implementation---allows traffic to be piped into a command; a secure tunnel is created and the traffic is forwarded through it. Or a secure tunnel can be set up between a local and a remote port; this tunnel can then be used by any application. 58 \TLS\ allows to create secure tunnels through which arbitrary programs can communicate. Hence one can add secure communication afterwards to programs without changing them. \name{OpenSSL} for example---a free implementation---allows traffic to be piped into a command; a secure tunnel is created and the traffic is forwarded through it. Or a secure tunnel can be set up between a local and a remote port; this tunnel can then be used by any application.
59 59
60 The \NAME{POP} protocol, for example, is good suited for such tunneling, but \SMTP\ is is not generally. Outgoing \SMTP\ client connections can be tunneled without problem---\masqmail\ already provides a configure option called \texttt{wrapper} to do so. Tunneling incomming connections to a server leads to problems with \SMTP. As data comes encrypted through the tunnel to the receiving host and gets then decrypted and forwarded on local to the port the application listens on. From the \MTA's view, this makes all connections appear to come from localhost, unfortunately. Figure \ref{fig:stunnel} depicts the data flow. 60 The \NAME{POP} protocol, for example, is good suited for such tunneling, but \SMTP\ is is not generally. Outgoing \SMTP\ client connections can be tunneled without problem---\masqmail\ already provides a configure option called \texttt{wrapper} to do so. Tunneling incomming connections to a server leads to problems with \SMTP. As data comes encrypted through the tunnel to the receiving host and gets then decrypted and forwarded on local to the port the application listens on. From the \MTA's view, this makes all connections appear to come from localhost, unfortunately. Figure \ref{fig:stunnel} depicts the data flow.
61 61
62 \begin{figure}
63 \begin{center}
64 \input{input/stunnel.tex}
65 \end{center}
66 \caption{Data flow using \name{stunnel}}
67 \label{fig:stunnel}
68 \end{figure}
69
70 For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement. 62 For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
71 63
72 \masqmail\ is already able to encrypt outgoing connections, but encryption of incoming connections, using \NAME{STARTTLS} should be implemented. This only affects the \SMTP\ server module. 64 \masqmail\ is already able to encrypt outgoing connections, but encryption of incoming connections, using \NAME{STARTTLS} should be implemented. This only affects the \SMTP\ server module.
73 65
74 %TLS/SSL prevents attackers to listen on the cable 66 %TLS/SSL prevents attackers to listen on the cable