Seit einiger Zeit bietet die Johann Wolfgang Goethe-Universität eine neue Möglichkeit der
Authentifizierung von Versuchen an, über den Uni-Mailserver mails zu versenden.
Eine Authentifizierung selbst ist nötig, da nicht jeder beliebige anonyme Anfragende über
den Uni-Mailserver mails versenden können dürfen soll (wg. der Probleme mit unerwünschter
Werbemail, alias Spam). Da nun aber Sender, die sich mit dem "Absende-Server" der Uni
verbinden, nicht bloß aus dem lokalen Uni-Netzwerk stammen, so dass etwa nach den Netzwerk-Adressen
dieser Rechner gefiltert werden könnte, sondern z.B. auch Uni-Angehörige von zu Hause aus,
während sie von einem Drittanbieter mit einer Internet-Verbindung mit dynamischer (d.h.
möglicherweise jedesmal wechselnder) Adresse versorgt werden, diesen Dienst in Anspruch
nehmen können sollen, muss eine adressunabhängige Authentifizierung eingerichtet werden.
Lange Zeit wurde dies dadurch erreicht, dass nur dann eine ausgehende Mail versandt werden
durfte, wenn zuvor - unter Angabe des Benutzernamens und des Passworts - die eingehende
Mail überprüft wurde.
Dieses Verfahren ("SMTP-after-POP") wurde seit Mai 2003 durch Mechanismen abgelöst, die
nicht nur die Authentifizierung der Absender ausgehender Mails sicherstellen, sondern
darüber hinaus auch den großen Vorteil haben, den Mailempfang und -versand inklusive
Anmeldung und Übertragung von Benutzernamen und -passwort nicht mehr als Klartext durchs
Internet zu schicken, sondern diesen ersten Schritt im Rahmen von verschlüsselten Verbindungen
abzuwickeln.
Zwar gilt dies nur für die Verbindung zwischen dem "Mailclienten" (Outlook,
The Bat!, Eudora, Mutt, Pine usw.) und dem Universitätsmailserver, jedoch ist dies trotz dieser
Einschränkung aus zwei Gründen ein wesentlicher Vorteil: Zunächst ist dies die einzige
Verbindung, an der das Passwort erforderlich ist, dann aber sollte man auch nicht unterschätzen,
wie viele Rechner diese eine Verbindung belauschen könnten - so besteht diese Verbindung oftmals
nicht aus einem einzigen "hop", sondern es könnte sich z.B. um einen Rechner handeln, der
in einem Firmennetzwerk vernetzt ist, und für die Verbindung zum Internet einen speziellen Rechner
dieses Netzwerks anspricht (den "Standard-Gateway"), welcher dann einen Rechner des
Internet-Providers der Firma kontaktiert, welcher die Verbindung durch eine ganze Reihe eigener Rechner
zu einem übergeordneten Leitungs-Provider ("backbone") weiterleitet. Dann geht es weiter
in das Netz des DFN (Deutsches Forschungs-Netz e.V.), welches der Provider der Uni ist, und schließlich
zum Netz der JWGU, wo der Mailserver mit wenigen Schritten erreichbar ist. ...und auf allen diesen Schritten
sind es nicht bloß die unmittelbar beteiligten Kommunikationspartner, welche das Passwort und die
Nachricht unverschlüsselt lesen können, sondern alle Rechner, die mit den jeweiligen
Kommunikationspartnern auf eine bestimmte Art und Weise verbunden sind (die sich im selben "Netzwerksegment"
befinden), also z.B. alle Rechner des Firmennetzwerkes.
Allerdings sollte man sich nicht darüber hinwegtäuschen, dass trotz dieses großen Fortschritts
die Nachricht - nur die Nachricht, nicht das Passwort - zwischen den weiter "stromabwärts" gelegenen
Mailservern wieder im Klartext
weitergereicht wird. Darauf hat auch die Uni oder das DFN keinen Einfluss - lediglich
der Verfasser der Nachricht,
der ja die Nachricht selbst (z.B. mit
GPG oder
PGP)
verschlüsseln kann.
Hier wird zunächst die Einrichtung der Verschlüsselung für die abgehenden Mails beschrieben,
dann die für die eingehenden.
Mehr Informationen dazu auf der Uni-eigenen Seite unter
http://www.rz.uni-frankfurt.de/internet/mail/smtpauth.shtml.
Doch zuerst noch ein Wort der Warnung: Obwohl ich vom HRZ der Uni Frankfurt immer sehr
hilfreichen Support auch in diesen Fragen erfahren habe, soll hier nicht der Eindruck
entstehen, der Support von Postfix/Fetchmail als Clienten der SMTP-A/APOP Services der Uni
sei eine Selbstverständlichkeit. Dies ist keine von der Uni geschriebene oder betreute
Anleitung und wer sich ihrer bedient, tut gut daran, bei Schwierigkeiten - und erst
recht bei Korrekturen und Verbesserungsvorschlägen - erst einmal
mit mir
Kontakt aufzunehmen, bevor er oder sie den Support der Uni in Anspruch nimmt.
Vielen Dank.
... ... ... jetzt aber los!:
Zertifikate basieren auf dem Prinzip der Verschlüsselung mit öffentlichen Schlüsseln (public key cryptography):
Für jeden Kommunikationsteilnehmer wird ein Schlüsselpaar generiert, das aus einem
privaten und einem öffentlichen Schlüssel besteht. Der private Schlüssel bleibt geheim und gut
gesichert beim Besitzer, der öffentliche Schlüssel hingegen wird verteilt und kann von
jeder beliebigen Instanz eingesehen werden. Dieser wird benutzt, um eine Nachricht an den
Schlüsselbesitzer zu verschlüsseln - die dann nur mittels des dazugehörigen
privaten Schlüssels (also in der Regel noch nicht einmal vom Absender selbst)
entschlüsselt werden kann. Der Clou ist, dass es faktisch unmöglich ist, anhand
des öffentlichen Schlüssels zu erraten, wie der private aussieht.
Durch eine weitere mathematische Besonderheit der für die Verschlüsselung benutzten
Algorithmen kann umgekehrt ein Kommunikationsteilnehmer mithilfe seines privaten Schlüssels eine
Nachricht signieren, indem er eine bestimmte Beschreibung des Inhalts (sozusagen eine "Quersumme")
der Nachricht mit seinem privaten Schlüssel verschlüsselt. Nun können alle Leser der Nachricht die
Beschreibung der ihnen vorliegenden Nachricht nach den bekannten "Quersummenregeln" nachbilden,
und die sich dadurch ergebende Beschreibung mit der vergleichen, die sich ergibt, wenn sie die der
Nachricht beiliegende verschlüsselte Beschreibung mit dem öffentlichen Schlüssel des Unterzeichners
entschlüsseln - stimmen beide Beschreibungen überein, ist einerseits die Nachricht seit der Signatur
nicht verändert worden, und andererseits die Signatur unzweifelhaft vom Besitzer des zum benutzten
öffentlichen Schlüssel gehörigen privaten Schlüssels vorgenommen worden.
Ein Zertifikat ist nun eine Nachricht, die eine Kommunikationsinstanz, etwa einen Web- oder
Mailserver oder eine Privatperson, beschreibt, gekoppelt mit dem öffentlichen Schlüssel
dieser Instanz und signiert mit ihrem privaten Schlüssel. Zudem kann ein Zertifikat von
weiteren Instanzen signiert worden sein, d.h. weitere Instanzen bürgen mit ihrer
Unterschrift für die Richtigkeit der Beschreibung der ersten Instanz, für die Tatsache,
dass die erste Instanz tatsächlich im Besitz des relevanten privaten Schlüssels ist, und
schließlich für die Unversehrtheit des Zertifikats. Diese weiteren Instanzen, die sich
auch aneinander reihen können (eine dritte Instanz könnte für die Beglaubigungsautorität
der zweiten Instanz bürgen usw. bis zu "top-level"/"Root"-Instanzen wie der
Regulierungsbehörde für Post und Telekommunikation
o.ä.), nennt man "Certificate Authorities" (CA's).
Siehe dazu eine ganze Menge von Dokumenten im Internet, stellvertretend:
http://www.experteam.de/startd/publikationen/Artikel/Ber03_GEK.html
Genug Theorie, wir benutzen jetzt das Programm OpenSSL, um uns ein Zertifikat zu bauen, das wir dem Uni-Mailserver vorzeigen, wenn wir das seine sehen wollen...
[ ca ]
default_ca = CA_default # The default ca section
[ CA_default ]
dir = /var/ssl # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $certs/my-ca-cert.pem # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/my-ca-key.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
default_days = 365 # how long to certify for
default_crl_days = 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
localityName = match # wasn't there before
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
default_md = sha1 # wasn't there before
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = nombstr
#########################################
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = DE
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Germany
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Internet Widgits Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 40
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
[ crl_ext ]
authorityKeyIdentifier = keyid:always,issuer:always
} elsif (/^-newcert$/) {
# create a certificate
system ("$REQ -new -x509 -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Certificate (and private key) is in newreq.pem\n"
} elsif (/^-newreq$/) {
# create a certificate request
system ("$REQ -new -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Request (and private key) is in newreq.pem\n";system ("$REQ -new... muss ein Parameter "-nodes"
eingefügt werden, der die Verschlüsselung unterdrückt. Danach sieht das so aus: } elsif (/^-newcert$/) {
# create a certificate
system ("$REQ -new -x509 -nodes -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Certificate (and private key) is in newreq.pem\n"
} elsif (/^-newreq$/) {
# create a certificate request
system ("$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS");
$RET=$?;
print "Request (and private key) is in newreq.pem\n";
Dann speichern, und| CA.pl -newca | Dies erstellt ein Unterverzeichnis "demoCA", darin das Zertifikat "cacert.pem", welches wir nach "/var/ssl/certs/my-ca-cert.pem" verschieben, und den Schlüssel "cakey.pem", welchen wir nach "/var/ssl/private/my-ca-key.pem" verschieben. |
| CA.pl -newreq | Dies erstellt eine Datei "newreq.pem", in der der "Beglaubigungsantrag" und der vertrauliche Schlüssel für die Ausgabe dieses (zukünftigen) Zertifikats zusammengeführt sind. |
| CA.pl -sign | Dies signiert die Datei "newreq.pem" und generiert die gültige Zertifikatdatei "newcert.pem", die wir nach "/var/ssl/certs/my-mailclient-cert.pem" verschieben, so wie wir das mit dem Schlüssel (key) machen, den wir nach "/var/ssl/private/my-mailclient-key.pem" verschieben. |
| chmod 600 /var/ssl/private/my-mailclient-key.pem chmod 600 /var/ssl/private/my-ca-key.pem cmhod 700 /var/ssl/private | Zum Schluss stellen wir sicher, dass unsere "Schlüssel" nicht von unauthorisierten Augen gelesen werden können. |
transport_maps = hash:/etc/postfix/transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/saslpass
smtp_sasl_security_options =
smtp_tls_cert_file = /var/ssl/certs/my-mailclient-cert.pem
smtp_tls_key_file = /var/ssl/private/my-mailclient-key.pem
smtp_tls_CAfile = /var/ssl/certs/my-ca-cert.pem
smtp_tls_CApath = /var/ssl/certs
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = sdbm:/etc/postfix/smtp_scache
smtp_use_tls = yes
smtp_tls_enforce_peername = no
smtp_tls_per_site = hash:/etc/postfix/tls_per_site
smtp_tls_note_starttls_offer = yes
tls_random_exchange_name = /etc/postfix/prng_exch
tls_random_source = dev:/dev/urandom
tls_daemon_random_source = dev:/dev/urandom
t-online.de smtp:[smtpauth.rz.uni-frankfurt.de]:27
.t-online.de smtp:[smtpauth.rz.uni-frankfurt.de]:27
aol.com smtp:[smtpauth.rz.uni-frankfurt.de]:27
.aol.com smtp:[smtpauth.rz.uni-frankfurt.de]:27
gmx.de smtp:[smtpauth.rz.uni-frankfurt.de]:27
.gmx.de smtp:[smtpauth.rz.uni-frankfurt.de]:27
hotmail.com smtp:[smtpauth.rz.uni-frankfurt.de]:27
.hotmail.com smtp:[smtpauth.rz.uni-frankfurt.de]:27
rr.com smtp:[smtpauth.rz.uni-frankfurt.de]:27
.rr.com smtp:[smtpauth.rz.uni-frankfurt.de]:27
smtpauth.rz.uni-frankfurt.de account:passsmtpauth.rz.uni-frankfurt.de MUST_NOPEERMATCH
Informationen zur Erstellung von Zertifikaten sind oben ersichtlich. Du brauchst hierfür ein Zertifikat "my-mailclient-cert.pem" mit dem dazugehörigen "my-mailclient-key.pem"...
set postmaster [*youraccount*]
set no bouncemail
set no spambounce
set invisible
set daemon 1800
set logfile [*yourmaildir*]/fetchmail.log
set syslog
defaults proto POP3
options fetchall mda "/usr/bin/procmail"
poll popmail.server.uni-frankfurt.de
user '[*youraccount*]' there with password '[*yourpassword*]' is '[*youraccount*]' here
ssl
sslcert "/var/ssl/certs/my-mailclient-cert.pem"
sslkey "/var/ssl/private/my-mailclient-key.pem"
sslcertpath "/var/ssl/certs"
(ganz offenkundig sind für die Einrichtung der Verschlüsselung die letzten Zeilen
(ab "poll popmail.server.uni-frankfurt.de") zuständig, die übrigen können von
Fall zu Fall auch ganz anders aussehen. Und ganz offensichtlich muss [*youraccount*] durch den
Benutzernamen, [*yourpassword*] durch Dein Passwort ersetzt werden.)
Ganz genau genommen, sind für die Einrichtung der Verschlüsselung nur die Zeilen
ab "ssl" zuständig - dieser Befehl weist fetchmail an, als allererstes auf dem für
verschlüsselte POP-Verbindungen definierten Standardport (Nr. 995) direkt mit dem Aufbau einer
verschlüsselten Verbindung zu beginnen - es werden noch nicht einmal Klartext-Anmeldeinformationen
(à la "HELO", "USER" usw.) vor dem Aufbau der Verschlüsselung
übertragen.
Das war's schon - beim nächsten fetchmail wird nur noch verschlüsselt kommuniziert.