Sichere Mailübertragung mit den Uni-Mailservices

Worum geht's?

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.

Disclaimer

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!:

Zum Seitenanfang


Den SMTP-AUTH Mechanismus der Uni mit einem Postfix mailserver zu Hause benutzen

Voraussetzungen

Los geht's - mit Zertifikaten

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...

  1. Überprüfe zunächst /etc/openssl.cnf
    (möglicherweise sind nur die Einträge bis zur Markierung ("#####...") relevant, ich habe hier aber zur Sicherheit die (fast) komplette Datei abgebildet):
    [ 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
  2. Erstelle Dein Zertifikat
    Dies ist - zumindest meiner Erinnerung nach - der komplizierteste Schritt, vielleicht aber auch nur, weil ich mich selbst dabei etliche Male verhaspelt habe. Das Problem ist, dass Zertifikate von sog. "Certification Authorities (CA)" beglaubigt sein müssen. Da wir uns dies fürs erste sparen wollen, spielen wir unsere eigene CA - das generiert aber alle naslang Warnmeldungen...
    Die hier vorliegende Beschreibung kann sicher noch einige Verbesserungen vertragen - die ich mir auch vorgenommen habe, aber hier ist erstmal ein Anfang:
    Das vorgehen ist im Prinzip so:
    1. Generiere einen Schlüssel, mit dem Du als CA Zertifikate beglaubigen kannst.
    2. Generiere ein Zertifikat für den Betrieb im Clienten und erstelle einen "Beglaubigungsanstrag".
    3. Beglaubige das Zertifikat als CA aus Schritt 1.
    4. Verteile die Zertifikate und Schlüssel, je nach ihrer Vertraulichkeit.
    Für den ganzen Kram benutzen wir das Skript "CA.pl", welches mit OpenSSL installiert wird.
  3. Aber hier geht der Ärger schon los: CA.pl erstellt normalerweise verschlüsselte Zertifikate, und die können wir nicht brauchen, sonst werden alle Server bockig...
    Also suchen wir erstmal das Skript: which CA.pl sollte den Speicherort des Skriptes ausgeben, bei mir ist das "/usr/sbin/CA.pl", was aber nur eine Verknüpfung zu "/usr/lib/ssl/CA.pl" ist.
    Wie (wo) auch immer, wir öffnen CA.pl in einem Editor und suchen die folgende Passage (ziemlich zu Beginn nach den Kommentaren, ungefähr bei Zeile 60):
    } 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";
    In die beiden Zeilen mit 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
  4. mit cd /var/ssl an den Ort des Geschehens (/var/ssl) wechseln.
  5. Dann kann's ja losgehen mit der Erstellung...
    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.
    Nähere Informationen und andere Quellen insbesondere zu diesem Punkt finden sich bei:
  6. Installiere die benötigten Fremdzertifikate
  7. Mache die Zertifikatsverzeichnisse ordentlich zurecht:
    c_rehash /var/ssl/certs
  8. kopiere /var/ssl/certs nach /var/spool/postfix/var/ssl/certs wenn Du postfix chrooted betreibst.
    (Wenn Dir das nix sagt, brauchst Du wahrscheinlich hier auch nix zu unternehmen ;-)

Endspurt - Postfix Einstellungen

  1. Überprüfe /etc/postfix/main.cf:
    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
  2. Überprüfe /etc/postfix/transport
    (Beispieleinträge, die aber Sinn machen, da die genannten Provider MTA's abweisen, die von einer Dialin-IP-Adresse aus anfragen. Bei denen benutzen wir den Uni-Mailserver als Relay, sonst können wir die mails mit unserem Postfix direkt ausliefern.):
    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
  3. Überprüfe /etc/postfix/saslpass:
    smtpauth.rz.uni-frankfurt.de account:pass
    (Dabei soll natürlich statt account:pass dein Benutzername und dein Passwort stehen, getrennt durch einen Doppelpunkt.)
  4. Überprüfe Besitz und Berechtigungen von /etc/postfix/saslpass:
    chown root:root /etc/postfix/saslpass chmod 600 /etc/postfix/saslpass
    (Die Befehle entweder einzeln oder - durch ein Semikolon (";") voneinander getrennt - als einen einzigen langen Befehl an der Kommandoaufforderung eingeben und mit <return> ausführen.)
  5. Überprüfe /etc/postfix/tls_per_site:
    smtpauth.rz.uni-frankfurt.de MUST_NOPEERMATCH
  6. Übernehme die Änderungen und lade postfix neu:
    postmap /etc/postfix/transport postmap /etc/postfix/saslpass postmap /etc/postfix/tls_per_site rcpostfix reload
    (Die Befehle entweder einzeln oder - durch ein Semikolon (";") voneinander getrennt - als einen einzigen langen Befehl an der Kommandoaufforderung eingeben und mit <return> ausführen.)

Verweise

Zum Seitenanfang


Fetchmail mit Verschlüsselung

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"...

Dann überprüfe Deine ~/.fetchmailrc:

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.

Zum Seitenanfang


Änderungen

02. Februar 2006
kleine Änderungen - die Server lukas und emma sind rausgeflogen, im Moment tut' dort nur smtpauth. Außerdem den Hinweis auf msmtp eingefügt. (Dank an Joost Kremers)
14. April 2004
kleine Änderungen - Umbrüche, SMTP-after-POP statt POP-before-SMTP u.ä.
30. März 2004
Erstmalige Veröffentlichung

Zum Seitenanfang