docs/diploma

annotate thesis/tex/5-Improvements.tex @ 189:79803ad327ca

reworked general requirements
author meillo@marmaro.de
date Tue, 30 Dec 2008 13:22:21 +0100
parents d4f818a4da04
children e038b2572d12
rev   line source
meillo@176 1 \chapter{Improvements}
meillo@89 2
meillo@109 3 << what to really implement within the thesis >>
meillo@109 4
meillo@89 5
meillo@184 6
meillo@184 7
meillo@184 8
meillo@176 9 \section{Implementation}
meillo@125 10
meillo@184 11
meillo@184 12
meillo@184 13
meillo@184 14
meillo@176 15 \subsection{Authentication for SMTP-in}
meillo@125 16
meillo@184 17 Several ways to restrict access are available. The most simple one is restrictiction by the \NAME{IP} address. No extra complexity is added this way, but static \NAME{IP} addresses are mandatory. This kind of restriction may be enabled using the operating system's \path{hosts.allow} and \path{hosts.deny} files. To allow only connections to port 25 from localhost or the local network \texttt{192.168.100.0/24} insert the line ``\texttt{25: ALL}'' into \path{hosts.deny} and ``\texttt{25: 127.0.0.1, 192.168.100.}'' into \path{hosts.allow}.
meillo@184 18
meillo@184 19 If static access restriction is not possible, for example if mail from locations with changing \NAME{IP} addresses wants to be accepted, some kind of authentication mechanism is required. Three common kinds exist:
meillo@184 20 \begin{enumerate}
meillo@184 21 \item \SMTP-after-\NAME{POP}: uses authenication on the \NAME{POP} protocol to permit incoming \SMTP\ connections for a limited time afterwards.
meillo@184 22 \item \SMTP authentication: is an extension to \SMTP. Authentication can be requested before mail is accepted.
meillo@184 23 \item Certificates: confirm the identity of someone.
meillo@184 24 \end{enumerate}
meillo@184 25 The first mechanism requires a \NAME{POP} (or \NAME{IMAP}) server running on the same host (or a trusted one), to enable the \SMTP\ server to use the login dates on the \NAME{POP} server. This is a common practice used by mail service providers, but is not adequate for the environments \masqmail\ is designed for.
meillo@184 26
meillo@184 27 Certificate based authentication, like provided by \NAME{TLS}, suffers from the overhead of certificate management. But \NAME{TLS} provides encryption too, so is useful anyway.
meillo@184 28
meillo@184 29 \SMTP\ authentication (also refered to as \NAME{SMTP-AUTH}) suppoert is easiest received by using a \name{Simple Authentication and Security Layer} implementation. \person{Dent} sees in \NAME{SASL} the best solution for authenticating dynamic users:
meillo@184 30 \begin{quote}
meillo@184 31 %None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.
meillo@184 32 None of these [authentication methods] is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
meillo@184 33 \cite[page 44]{dent04}
meillo@184 34 \end{quote}
meillo@184 35
meillo@184 36 %either by
meillo@184 37 %- network/ip address
meillo@184 38 % easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
meillo@184 39 %or
meillo@184 40 %- some kind of auth (for dynamic remote hosts)
meillo@184 41 % adds complexity
meillo@184 42 % - SASL
meillo@184 43 % - POP/IMAP: pop-before-smtp, DRAC, WHOSON
meillo@184 44 % - TLS (certificates)
meillo@184 45
meillo@184 46
meillo@184 47
meillo@184 48
meillo@184 49
meillo@184 50
meillo@184 51
meillo@176 52 \subsection{Encryption}
meillo@129 53
meillo@184 54 Electronic mail is very weak to sniffing attacks, because all data transfer is unencrypted. This concerns the message's content, as well as the email addresses in header and envelope, but also authentication dialogs that may transfer plain text passwords (\NAME{PLAIN} and \NAME{LOGIN} are examples). Adding encryption is therefor wanted.
meillo@184 55
meillo@184 56 The common way to encrypt \SMTP\ dialogs is using \name{Transport Layer Security} (short: \TLS, successor of \NAME{SSL}). \TLS\ encrypts the datagrams of the \name{transport layer}. This means it works below the application protocols and can be used by any of them\citeweb{wikipedia:tls}.
meillo@184 57
meillo@184 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.
meillo@184 59
meillo@184 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.
meillo@184 61
meillo@184 62 \begin{figure}
meillo@184 63 \begin{center}
meillo@184 64 \input{input/stunnel.tex}
meillo@184 65 \end{center}
meillo@184 66 \caption{Data flow using \name{stunnel}}
meillo@184 67 \label{fig:stunnel}
meillo@184 68 \end{figure}
meillo@184 69
meillo@184 70 For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
meillo@184 71
meillo@184 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.
meillo@184 73
meillo@184 74 %TLS/SSL prevents attackers to listen on the cable
meillo@184 75 %but it does not prevent man-in-the-middle attacks
meillo@184 76 %signed certificates help here
meillo@184 77 % or PGP encryption
meillo@184 78
meillo@184 79
meillo@184 80 %do not use stunnel wit SMTP:
meillo@184 81 %because all incoming mail would be from 127.0.0.1 !!
meillo@184 82 %use STARTTLS instead
meillo@184 83
meillo@184 84 %postfix: main.cf
meillo@184 85 %\begin{verbatim}
meillo@184 86 % smtpd_use_tls = yes
meillo@184 87 % smtpd_tls_received_header = no (does not log in received headers)
meillo@184 88 %
meillo@184 89 % smtpd_tls_key_file = /etc/postfix/key.pem
meillo@184 90 % smtpd_tls_cert_file = /etc/postfix/cert.pem
meillo@184 91 % smtpd_tls_CA_file = /etc/postfix/CAcert.pem
meillo@184 92 %
meillo@184 93 % smtp_use_tls = yes (use TLS for sending)
meillo@184 94 % smtp_tls_key_file = /etc/postfix/key.pem
meillo@184 95 % smtp_tls_cert_file = /etc/postfix/cert.pem
meillo@184 96 % smtp_tls_CA_file = /etc/postfix/CAcert.pem
meillo@184 97 %\end{verbatim}
meillo@184 98
meillo@184 99
meillo@184 100
meillo@184 101
meillo@184 102
meillo@89 103
meillo@89 104
meillo@176 105 \section{Documentation}
meillo@89 106
meillo@89 107
meillo@89 108 \section{Test and validation}
meillo@89 109
meillo@175 110
meillo@175 111 \section{Release}
meillo@175 112
meillo@175 113 << Debian >>
meillo@175 114
meillo@175 115