docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 172:5c873e6478ef

wrote about encryption

author	meillo@marmaro.de
date	Mon, 22 Dec 2008 20:42:33 +0100
parents	204683bfb4e7
children	c51f1be54224

comparison

equal deleted inserted replaced

-:9415e41e765e
+:5c873e6478ef
 	\item a different local user (e.g.\ ``\texttt{bob: alice}'')
 	\item a remote user (e.g.\ ``\texttt{bob: john@example.com}'')
 	\item a list of users (e.g.\ ``\texttt{bob: alice, john@example.com}'')
 	\item a command (e.g.\ ``\texttt{bob: |foo}'')
 \end{itemize}
-Aliases can be cascaded like in the following example:
-\begin{verbatim}
-team:   alice, bob
-bob:    bob@example.com
-\end{verbatim}
 Addresses expanding to lists of users lead to more envelopes. Aliases changing the reciptients domain part may require a different route to use.
-Aliasing is often handled in expanding the alias and reinjecting the mail into the system. Unfortunately, the mail is processed twice using this approach; also does the system need to handle more mail this way. Is it needed to check the new recipient address for acceptance, or should it be accepted generally? (The aliase actually came from inside the system.) A second point for access control seems to be no choice.
+Aliasing is often handled in expanding the alias and reinjecting the mail into the system. Unfortunately, the mail is processed twice then; additionally does the system have to handle more mail this way. If it is wanted to check the new recipient address for acceptance and do all processing again, then reinjecting it is the best choice.
 \subsubsection*{Authentication}
 \subsubsection*{Encryption}
-TLS/SSL prevents attackers to listen on the cable
+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.
-but it does not prevent man-in-the-middle attacks
-signed certificates help here
+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}.
+\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.
-ch /usr/share/ssl/misc
+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.
-create new CA:
-\begin{verbatim}
+\begin{figure}
-	CA.pl -newca
+	\begin{center}
-		country: DE
+		\input{input/stunnel.tex}
-		state: schwaben
+	\end{center}
-		city: Ulm
+	\caption{Data flow using \name{stunnel}}
-		company:
+	\label{fig:stunnel}
-		section:
+\end{figure}
-		name:
-		emailaddress:
+For incoming connections, \NAME{STARTTLS}---defined in \RFC2487---is what \mta{}s implement.
-\end{verbatim}
+\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.
-generate ssl key:
-\begin{verbatim}
+%TLS/SSL prevents attackers to listen on the cable
-	CA.pl -newreq
+%but it does not prevent man-in-the-middle attacks
-		... the same questions
+%signed certificates help here
-\end{verbatim}
+%   or PGP encryption
-sign request with CA:
-\begin{verbatim}
+%do not use stunnel wit SMTP:
-	CA.pl -sign
+%because all incoming mail would be from 127.0.0.1 !!
-\end{verbatim}
+%use STARTTLS instead
-remove passphrase from private key:
+%postfix: main.cf
-\begin{verbatim}
+%\begin{verbatim}
-	openssl rsa <newreq.pem >key.pem
+%	smtpd_use_tls = yes
-	(to be used by programs automaticly)
+%	smtpd_tls_received_header = no (does not log in received headers)
-\end{verbatim}
+%
+%	smtpd_tls_key_file = /etc/postfix/key.pem
-secure:
+%	smtpd_tls_cert_file = /etc/postfix/cert.pem
-\begin{verbatim}
+%	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
-	chmod 400 *.pem
+%
-	cp newcert.pem /etc/postfix/cert.pem
+%	smtp_use_tls = yes  (use TLS for sending)
-	cp key.pem /etc/postfix/key.pem
+%	smtp_tls_key_file = /etc/postfix/key.pem
-	cp demoCA/cacert.pem /etc/postfix/CAcert.pem
+%	smtp_tls_cert_file = /etc/postfix/cert.pem
-	chmode 400 /etc/postfix/*.pem
+%	smtp_tls_CA_file = /etc/postfix/CAcert.pem
+%\end{verbatim}
-	mkdir /etc/stunnel
-	cat newcert.pem key.pem >/etc/stunnel/stunnel.pem
-	chmod 400 /etc/stunnel/stunnel.pem
-	(check /etc/stunnel with `stunnel -V')
-\end{verbatim}
-set up stunnels for POP, etc:
-\begin{verbatim}
-	nmap localhost
-	stunnel -d pop3s -r localhost:pop3 -p /etc/stunnel/stunnel.pem
-	stunnel -d imaps -r localhost:imap -p /etc/stunnel/stunnel.pem
-	nmap localhost
-		pop3s 995
-		imaps 993
-\end{verbatim}
-do not use stunnel wit SMTP:
-because all incoming mail would be from 127.0.0.1 !!
-use STARTTLS instead
-postfix: main.cf
-\begin{verbatim}
-	smtpd_use_tls = yes
-	smtpd_tls_received_header = no (does not log in received headers)
-	smtpd_tls_key_file = /etc/postfix/key.pem
-	smtpd_tls_cert_file = /etc/postfix/cert.pem
-	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
-	smtp_use_tls = yes  (use TLS for sending)
-	smtp_tls_key_file = /etc/postfix/key.pem
-	smtp_tls_cert_file = /etc/postfix/cert.pem
-	smtp_tls_CA_file = /etc/postfix/CAcert.pem
-\end{verbatim}
 \subsubsection*{Spam prevention}

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 172:5c873e6478ef