Categories
Datenschutz German Mailserver OccuMail

Ein Spamfreies Postfach mit OccuMail ZeroSpam

Heute soll es um unseren Maildienst OccuMail gehen, für den auch du eine kostenlose Adresse bekommen kannst. Typischerweise vergeben wir etwa 1GB Speicher kostenlos. Mehr Speicher können wir gerne zur Verfügung stellen, aber wir bitten dann um eine geringfügige Beteiligung an den Serverkosten. Für mehr Informationen, bitte anfragen!

Mögliche, kostenlose Mailaliase sind:

  • nickname@occumail.net
  • nickname@new-visual-dimension.de
  • nickname@the-digital-native.de
  • nickname@the-digital-native.net
  • nickname@your-domain.tld (zum Selbstkostenpreis)

Unser Dienst ist Datenschutzfreundlich, Werbefrei und deine Mailinhalte werden von uns nicht eingesehen oder kontrolliert. Außerdem geben wir deine Mailinhalte niemals an Behörden oder sonstige staatliche Institutionen heraus. Im Zweifelsfall würden wir es auf einen Gerichtsprozess ankommen lassen. Glücklicherweise gab es eine solche Anfrage bis heute noch nie.

Bei OccuMail gibt es keinen Spamfilter

Einige Nutzer von OccuMail fragten mich bereits, warum es denn keinen Spam-Ordner in Ihrem Postfach geben würde. Die Antwort ist einfach: Wir bieten keinen Spamfilter an. Warum das so ist? Weil man seine E-Mailadresse Spamfrei halten kann. Ich habe meine aktuelle E-Mailadresse seit Oktober 2013, also knapp 7 Jahre, und erhalte immernoch keinerlei Spam.

Dafür muss man jedoch ein paar Regeln einhalten:

  • Poste deine E-Mailadresse niemals öffentlich im Internet auf irgendeiner Website.
  • Wenn du deine E-Mailadresse doch irgendwo publizieren musst (z.B. Impressum), dann nimm dafür, wenn möglich, einen Alias, der auf deine E-Mailadresse weiterleitet. Du kannst diesen Alias dann im Notfall einfach deaktivieren, ohne deine Hauptadresse zu verlieren.
  • Wenn du deine E-Mailadresse publizierst, tue dies niemals im Klartext, sondern als Privacy Captcha. Als Bild, oder besser als Privacy Captcha, kann deine E-Mailadresse nicht durch Bots gefunden und für Spam missbraucht werden. Solche Bots durchsuchen tagtäglich so gut wie alle Webseiten und schnüffeln E-Mailadressen auf!
  • Wann immer du dich bei irgendeinem Service oder Dienstleister mit einer E-Mailadresse registrierst, tue dies mit OccuMail ZeroSpam.

Über OccuMail ZeroSpam

Die Idee ist, wann immer du dich irgendwo mit einer E-Mailadresse registrierst, eine neue Mailadresse zu benutzen. Diese E-Mailadresse ist dann ausschließlich für diesen einen Anbieter bestimmt. Der Hintergrund: Meist wird deine E-Mailadresse nicht durch Freunde und Bekannte an Spammer und Phisher gegeben, sondern durch irgendeinen Serviceanbieter oder Dienstleister.

Wie funktioniert das bei OccuMail ZeroSpam?

Wenn du bei uns eine Adresse nickname@occumail.net hast, kannst du selbst über unsere Administrationsoberfläche Postfix Admin E-Mailadressen der Form alias@nickname.occumail.net anlegen. Wenn du deine eigene Top-Level Domain hast, dann natürlich auch alias@your-domain.tld. Wir empfehlen, sprechende Namen zu verwenden.

Erstelle dir z.B. eine der folgenden E-Mailadressen:

  • amazon@nickname.occumail.net
  • buch7@nickname.occumail.net
  • facebook@nickname.occumail.net
  • diaspora@nickname.occumail.net
  • twitter@nickname.occumail.net
  • mastodon@nickname.occumail.net

Das sieht in unserer Administrationsoberfläche wie folgt aus:

Wenn du Spam erhältst, kannst du einen Mailalias nun jederzeit wieder löschen. Wir empfehlen jedoch den Eintrag einfach zu deaktivieren. Dann kommen auch keine Mails mehr an, aber du hast den Überblick von wo schon mal Spam- oder Phishingmails kamen.

Tritt den Übeltätern auf die Füße!

Eine weitere tolle Eigenschaft dieser Methode: Erhältst du Mails auf eine Adresse, weißt du ja wo du diese Adresse benutzt hast. Von daher hast du die Möglichkeit dem Verantwortlichen auf die Füße zu treten. Entweder dieser hat die Daten selbst an Spammer oder Phisher weitergegeben, oder es gab ein Sicherheitsleck, über das die Kundendaten entwendet wurden. Auch letzteres gilt es zu Verfolgen, da die Kunden darüber informiert werden müssen. Das gilt sogar qua Gesetz!

Der Fall Foto Erhardt

Tatsächlich hatte ich schon mal einen solchen Fall, wo bei mir persönlich ein Phishingversuch auf meinen PayPal Account stattgefunden hat und das sogar unter Angabe meines Namens und meiner kompletten Adresse. Dank OccuMail ZeroSpam konnte ich den Ursprung des Ganzen nachverfolgen. An dieser Stelle nehme ich auch kein Blatt vor den Mund und sage, dass dieser Fall Foto Erhardt betraf, wo ich einige Zeit zuvor eine Onlinebestellung getätigt hatte. Ich ging zunächst von keiner böswilligen Absicht aus und unterstellte ein Sicherheitsleck, also dass die Daten gestohlen wurden. Ich informierte Foto Erhardt sofort telefonisch, wo man sich wenig zu interessieren schien und man mir sagte, ich sollte doch eine E-Mail schreiben. Das tat ich auch. Diese blieb jedoch unbeantwortet. Es gab auch keine Information der Kunden über ein Datenleck, sodass Foto Erhardt seinen gesetzlichen Pflichten nicht nachgekommen ist. Ich entschied mich deswegen damals, zumindest den Fall publik zu machen. Ich postete den Vorfall in einigen Foren für Fotografie. Angesichts dieses Verhaltens, sollte man doch noch mal überdenken, ob man denn gerade bei diesem Anbieter bestellen möchte (sei es auch gerade der günstigste).

Fazit

Mit ein paar grundlegenden Regeln und OccuMail ZeroSpam kann man den Spammern und Phishern ein Schnippchen schlagen. Möglich wird dies durch das Prinzip “eine Adresse pro Dienst”. Als Zusatznutzen kann man die Schuldigen identifizieren. Ich selbst habe übrigens inzwischen etwa 370 Aliase, wovon 40 deaktiviert sind. Das Prinzip hat mein Postfach also wirkungsvoll geschützt.

Wer noch keinen Adresse von OccuMail hat, der darf sich nun gerne melden und in den Genuss von OccuMail ZeroSpam kommen. Wer schon einen Account hat und ZeroSpam noch nicht nutzt, der möge sich zwecks Einrichtung kurz bei mir melden. Ich wünsche ein Spamfreies Wochenende!

Categories
Administration / Webmaster German Linux Mailserver

Serverseitige Mailfilter mittels Sieve. Einrichtung von Dovecot & Roundcube

Sieve-Skripte sind eine einfache Möglichkeit Mailfilter auf Mailservern umzusetzen. So können serverseitig etwa Regeln definiert werden, die eingehende Nachrichten z.B. bei vorliegen eines bestimmten Absenders, Empfängers oder Betreffs in einen Ordner verschiebt. Nachrichten können z.B. auch gelöscht oder als gelesen markiert werden. Man kann auch Nachrichten weiterleiten oder mit automatisierter Antwort ablehnen. Auch Abwesenheitsnotizen sind ein Typischer Anwendungsfall.

Die Möglichkeiten sind im Prinzip sehr ähnlich zu den Filterregeln, die man in Thunderbird hinterlegen kann. Der Wesentliche Vorteil: Das Filtern erfolgt auf dem Server. Das ist insbesondere dann von Vorteil, wenn man von mehreren Clients auf ein IMAP-Account zugreift. Da wir heutzutage in der Ära der Smartphones angelangt sind, tut das quasi jeder. Manch einer neben Desktop und Smartphone womöglich noch auf der Arbeit oder per Webmail. Mittels Sieve muss man die Filter nur ein mal pflegen und zwar auf dem Server.

Sieve Clients

Sieve stellt ein eigenes Protokoll zur Verfügung und ist unter Port 4190 zu erreichen. Nun könnte man seine Filter tatsächlich sogar per Telnet pflegen. Komfortabler ist aber ein Sieve Client (Überblick hier). Viele Clients sind jedoch veraltet. Empfehlenswert ist Manage Sieve (Windows und Linux), welches das editieren von Sieve Skripten mit Syntax-Hervorhebung ermöglicht. Das ist toll für Informatiker und Enthusiasten, wird aber den Otto-Normal-Verbraucher abschrecken. Wer seinen Nutzern die Filter komfortabel per GUI erstellen lassen möchte, dem sei die Sieve Erweiterung für den Webmailclient Roundcube empfohlen. Weiterer Vorteil: Man braucht keine weitere Software installieren. Wir besprechen daher im Folgenden auch die Installation von Sieve in Roundcube.

Editieren eines Sieve Skripts mittels Manage Sieve unter Linux

Voraussetzungen

Wir verwenden folgendes System:

  • Debian 10 (Buster)
  • dovecot 2.3.4.1 (Befehl /usr/sbin/dovecot --version)

Wir gehen davon aus, dass Dovecot bereits vollständig für die Verwendung mit IMAP eingerichtet ist. Auch Roundcube sollte schon installiert sein. Wir besprechen hier nur die nötige Konfiguration für Sieve!

Dovecot einrichten

Bekanntermaßen wird Sieve häufig auch für das Filtern von z.B. Spam in den Spam-Ordner verwendet. Während hier die Regeln lediglich durch den Administrator auf dem Server abgelegt werden, möchten wir dem Endanwender ermöglichen Sieve-Skripte anzuwenden. Hierzu verwenden wir neben dem sieve Plugin auch managesieve.

Zuerst installieren wir die Sieve-Erweiterung von Dovecot:

sudo apt-get install dovecot-sieve dovecot-managesieved

Sieve für LMTP aktivieren

Wir aktivieren nun das Sieve Plugin für den LMTP (Local Mail Transfer Protocol). Dazu editieren wir die Datei /etc/dovecot/conf.d/20-lmtp.conf:

protocol lmtp {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}

Sieve konfigurieren

Nun richten wir Sieve selbst ein. Dazu editieren wir /etc/dovecot/conf.d/90-sieve.conf. Generell gilt, dass ein Benutzer beliebig viele Sieve-Skripte haben kann. Diese müssen an einem Ort gespeichert werden. Hierfür bietet sich z.B. /var/vmail/sieve/scripts/%u an. Hierbei ist %u ein Platzhalter für den vollständigen Benutzernamen inklusive Domain, also der Form user@example.com. Außerdem muss der Ort für das aktuell aktive Sieve-Skript eines Nutzers angegeben werden. Ein Nutzer kann zwar beliebig viele Sieve-Skripte definieren, hat aber immer nur genau ein aktives Skript. Wir nehmen hier den Pfad /var/vmail/sieve/%u.sieve. Die 90-sieve.conf beinhaltet nun folgendes:

sieve = file:/var/vmail/sieve/scripts/%u;active=/var/vmail/sieve/%u.sieve

Wer ein Sieve-Skript für einen Spamfilter anlegen möchte, also z.B. bei vorliegen eines Spam-Headers in einen Spam-Ordner filtern möchte, tut dies in der Regel bevor das Skript des Benutzers ausgeführt wird. Daher wird sieve_before gesetzt. Folgendes könnte in 90-sieve.conf eingetragen werden:

sieve_before = /var/vmail/sieve/spam-global.sieve

Die Datei spam-global.sieve kann wie folgt aussehen:

require "fileinto";
if header :contains "X-Spam-Flag" "YES" {
  fileinto "Spam";
}

Managesieve konfigurieren

Um unsere Sieve-Skripte auch von außen bearbeiten zu können, müssen wir nun managesieve aktivieren. Wir bearbeiten /etc/dovecot/conf.d/20-managesieve.conf:

service managesieve-login {
  inet_listener sieve {
    port = 4190
   }
}

Damit hätten wir es geschafft. Jetzt noch neu starten!

sudo service dovecot restart

Roundcube

Zuerst richten wir das Plugin managesieve für Roundcube ein. Dazu legen wir die Configdatei config.inc.php durch Kopieren der Defaultconfig config.inc.php.dist an:

cp /path-to-roundcube/plugins/managesieve/config.inc.php.dist /path-to-roundcube/plugins/managesieve/config.inc.php

Nun editieren wir die config.inc.php wie folgt:

$config['managesieve_port'] = 4190;
$config['managesieve_host'] = '%h';
$config['managesieve_usetls'] = true;

Der Port 4190 ist der Standardport für Sieve und wir haben diesen in der managesieve.conf von Dovecot entsprechend gesetzt. Ich gehe davon aus, dass die Hostnamen in der Roundcube Konfigurationsdatei explizit gesetzt sind. So ist es mit dieser Konfiguration auch möglich Sieve-Skripte auf fremden Mailservern (ungleich localhost) zu editieren. Da dies möglich ist, sollten wir managesieve_usetls auf jeden Fall auf true setzen, damit wir Transportverschlüsselung haben. Wir müssen nun noch das managesieve-Plugin in der Roudcube Konfigurationsdatei aktivieren. Bei mir sieht /path-to-roundcube/config/config.inc.php ausschnittsweise wie folgt aus:

$config['default_host'] = array('tls://imap.occumail.net','tls://imap.digitalcourage.de');
$config['smtp_server'] = 'tls://smtp.%z';
$config['smtp_port'] = '587';
$config['plugins'] = array(
'emoticons',
'archive',
'zipdownload',
'password',
'managesieve',
);

Filter in Roundcube bearbeiten

Wir können uns nun in Roundcube einloggen. Oben rechts unter Einstellungen finden wir nun links den Eintrag Filter. Hier können wir neue Filtersätze anlegen und einen Filtersatz aktivieren. Filter können sehr komfortabel über die GUI zusammengeklickt werden. Roundcube generiert das Sieve-Skript und pusht dieses auf den Server.

Bezüglich der möglichen Filter sind bei mir keine Wünsche offen geblieben. Aktuell wäre mir nicht bekannt, dass die Sieve-Skriptsprache Operationen unterstützt, die hier nicht abgedeckt werden. Solltest du andere Erfahrungen gemacht haben, dann kontaktiere mich doch bitte und ich werde den Artikel entsprechend ergänzen!

Einstellen eines Sieve-Filters auf Roundcube
Categories
Administration / Webmaster IT-Security Linux Mailserver

Postfix & Dovecot: TLS-Konfiguration mit automatisch erneuernden Let’s Encrypt Zertifikaten

Täglich gehen zig Millionen Mails durch die Welt. Heute sollte es selbstverständlich sein, vom Mailclient zum Mailserver transportverschlüsselt zu arbeiten: Mails abrufen per IMAP (Dovecot), Mails versenden per SMTP (Postfix). Aber auch die Intra-Mailserverkommunikation (Postfix) sollte heutzutage nach aktuellen Standards verschlüsselt erfolgen.

Noch vor wenigen Jahren war es noch absolut üblich, dass Mailserver unverschlüsselt miteinander kommunizierten. Noch im Januar 2015 kommunizierten nur gut 50% der Mailserver untereinander verschlüsselt. Heute sind es über 90% (Quelle: Google Transparency Report, Stand: Mai 2020). Das wird im Auge vieler Administratoren dennoch nicht genug sein, um unverschlüsselte Kommunikation komplett auszuschließen. Meiner Meinung nach sollten sich große Anbieter wie GMail, Outlook.com, Web.de, Gmx.de, … zusammen schließen und unverschlüsselte Kommunikation konsequent blocken. Unter diesem Druck wäre es nur eine Frage der Zeit, bis schlecht konfigurierte uralt Server verschwinden.

E-Mail Verschlüsselung über die Zeit. Quelle: Google

Inhalt

Hier möchten wir uns nun mit der Konfiguration von Postfix und Dovecot beschäftigen: Wir werden einen Parallelbetrieb von ECDSA / RSA Zertifikaten vorstellen. RSA ist dabei etablierter Standard. ECDSA (Elliptische-Kurven-Kryptografie) ist Cutting-Edge Technologie und wird in Zukunft an Bedeutung gewinnen. Wer diesen Artikel liest, möchte wahrscheinlich auf der Höhe der Zeit sein und schon heute ECDSA einsetzen.

Dabei nutzen wir Let’s Encrypt als Zertifizierungsstelle und acme.sh als ACME Clients Implementierung zum beziehen und installieren von Zertifikaten. acme.sh ist eine Alternative zu certbot, die für unsere Zwecke einige Vorteile bietet. Besonderes Augenmerk habe ich darauf gelegt, dass Zertifikate automatisch erneuert werden, denn schließlich ist ein Let’s Encrypt Zertifikat nur 3 Monate gültig.

Vorwissen

Für diesen Artikel sind Grundkenntnisse im Bereich von Administration von Linuxsevern im Allgemeinen sowie von Mailservern im speziellen zu empfehlen. Außerdem sollte grundsätzlich verstanden sein, was es mit asymmetrischer Kryptografie auf sich hat und warum eine Zertifizierungsstelle wir Let’s Encrypt benötigt wird.

Wir gehen davon aus, dass Sie Postfix und Dovecot bereits im Einsatz haben oder zumindest so weit konfiguriert haben, dass Ihnen nur noch die Verschlüsselung fehlt. Sollte das noch nicht der Fall sein, befolgen Sie bitte ein entsprechendes Tutorial, bevor Sie hier weiter machen.

Als Betriebssystem kommt bei uns Debian 10 (Buster) zum Einsatz. Auf Ubuntu sollte es kaum Unterschiede geben, für andere Distributionen sind evtl. kleinere Anpassungen nötig.

Unsere Umgebung und Programmversionen:

  • Betriebssystem: Debian 10 (Buster)
  • Postfix: 3.4.8 (Befehl: postconf -d mail_version)
  • Dovecot: 2.3.4.1 (Befehl: dovecot --version)
  • OpenSSL: OpenSSL 1.1.1d (10. Sep 2019) (Befehl: openssl version)

Vorarbeiten

RSA- und ECDSA-Schlüsselpärchen

Wir erzeugen nun ein RSA– und ein ECDSA-Schlüsselpärchen, welche wir von der CA Let’s Encrypt mittels eines Zertifikats beglaubigen lassen. Für diesen Zweck verwenden wir das Shell-Skript acme.sh.

acme.sh installieren

Wir klonen zuerst das git-Repository von acme.sh. Falls git nicht installiert ist, holen Sie dies bitte jetzt nach:

sudo apt-get install git

Nun das git klonen und die Installation anstoßen. Es ist zu empfehlen, dies als root-User zu tun:

sudo su
git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install

Der Installer sorgt für drei Dinge:

  1. Erstellt und kopiert acme.sh in das home-Verzeichnis: ~/.acme.sh/. Alle Zertifikate werden später hier abgelegt und dann mittels einer Installationsroutine an ihren Zielort kopiert.
  2. Es wird ein Alias erzeugt: acme.sh=~/.acme.sh/acme.sh
  3. Es wird ein Cronjob angelegt, der ein mal am Tag Zertifikate checkt und, wenn nötig, neu beantragt und automatisch installiert.

Nach der Installation muss das Terminal ein mal neu gestartet werden, damit der Alias acme.sh funktioniert (ggf. neuer Login per ssh). Die Hilfe von acme.sh kann wie folgt aufgerufen werden: acme.sh -h

Zertifikate erzeugen

Wir könnten nun einerseits ein Wildcard Zertifikat generieren, was aber mit zusätzlichen Aufwänden verbunden ist (DNS Challenge) und ggf. sogar ein Sicherheitsrisiko darstellt. Daher sollten wir ein Zertifikat für den MX-Eintrag generieren (hier: mail.occumail.net) und, falls nötig, alias Domains für den IMAP Server (hier: imap.occumail.net) und für den SMTP Server (hier: smtp.occumail.net) anlegen.

Es stellt sich noch die Frage: Läuft auf dem Server ein Webserver wie apache2 oder nginx? Da acme.sh einen eigenen Webserver startet, kommt es natürlich zu einem Konflikt auf Port 80. Daher bauen wir hier einen Pre-Hook ein, der vor Generierung des Zertifikats apache2 stoppt (--pre-hook "service apache2 stop") und einen Post-Hook, der apache2 wieder startet (--post-hook "service apache2 start"). Für nginx geht dies äquivalent.

RSA Zertifikat erzeugen

Für den RSA Schlüssel empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) noch bis Ende 2023 eine Schlüssellänge von 2048 Bits, die als sicher gelte. Danach werden 3072 Bits empfohlen. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Wer nach aktuellem Kenntnisstand sicher sein möchte, wählt also 2048 Bits , wer für die Zukunft gewahrt sein möchte 3072 Bits und wer paranoid ist 4096 Bits. Man bedenke bei der Wahl immer, dass ein längerer Schlüssel einen (womöglich deutlichen) Rechenaufwand bedeutet. Bei schwacher Hardware oder schwachen VServern sollte man daher vorsichtig sein, einen zu langen Schlüssel zu wählen. Wir nehmen in unserem Beispiel 3072 Bits (Parameter--keylength 3072).

Nun testen wir erst mal, ob unsere Zertifikatsbeantragung funktioniert. Mit der Option --test wird vorerst nur ein Dummy-Zertifikat erzeugt. Wir sollten vorsichtig vorgehen und nicht ohne Tests arbeiten, da Beantragungen bei Let’s Encrypt auf 5 Ausstellungen pro Woche pro (Sub-)Domain beschränkt sind. Es darf also nicht zu oft schief gehen.

Wir führen also folgendes aus:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength 3072 \
--standalone \
--test

Hat alles geklappt? Dann nun das echte Zertifikat beantragen:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength 3072 \
--standalone

Es liegen nun unter ~/.acme.sh/mail.occumail.net folgende Dateien:

  • mail.occumail.net.csr: Certificate Signing Request mit den notwendigen Informationen, die zur Antragsstellung des Zertifikats bei Let’s Encrypt benutzt wurden.
  • mail.occumail.net.csr.conf: Konfigurationsdatei für die zukünftige Generierung von CSRs beim automatischen erneuern von Zertifikaten.
  • mail.occumail.net.cer: Unser Zertifikat für die beantragten (Sub-)Domains.
  • fullchain.cer: Zertifikat für die beantragten (Sub-)Domains zusammen mit Zwischenzertifikaten, die für die Chain of Trust benötigt werden. Diese Datei benötigen wir im Folgenden noch.
  • mail.occumail.net.key: Unser privater Schlüssel. Auch diese Datei benötigen wir noch.
  • ca.cer: Zertifikat der Certification Authority, also Let’s Encrypt.
  • mail.occumail.net.conf: Informationen für die neue Beantragung von Zertifikaten, wenn das Alte abläuft (alle 2 Monate)

Ein Vorteil von acme.sh im Vergleich zu certbot ist, dass der private Schlüssel nicht bei jeder Neubeantragung neu erzeugt wird. Das ermöglicht, die Zertifikate auch für TLSA-Records (DANE) und HPKP (Public Key Pinning) einzusetzen. Wer mit diesen Begriffen jetzt nichts anfangen kann, sollte sich diese nach Abschluss des Tutorials noch mal zur Gemüte führen, da sie für Mailserver durchaus relevant sind.

ECDSA Zertifikat erzeugen

Nun zum ECDSA (Elliptic Curve Digital Signature Algorithm). Let’s Encrypt stellt uns stand heute zwei Varianten zur Verfügung: ec-256 mit 256 Bit Schlüssellänge und ec-384 mit 384 Bit Schlüssellänge. Hier entspricht ec-256 bereits einer RSA-Schlüssellänge von 3072 Bit und ist damit auch auf längere Sicht hinreichen sicher (über Jahr 2023 hinaus). ec-384 entspricht einer RSA-Schlüssellänge von 7680 Bit und ist damit quasi auf Ewig unknackbar (Fehler im Algorithmus und unerwartete Technologiesprünge ausgenommen). Da diese Art von Algorithmus ob des ohnehin relativ kurzen Schlüssels sehr effizient ist, spricht aus Performancegründen aber auch kaum etwas gegen den Einsatz von ec-384.

Zur Generierung führen wir Äquivalent zu oben folgendes aus:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength ec-384 \
--standalone \
--test

Wenn alles funktioniert hat, dann wieder ohne --test:

acme.sh --pre-hook "service apache2 stop" \
--post-hook "service apache2 start" \
--issue \
-d mail.occumail.net \
-d imap.occumail.net \
-d smtp.occumail.net \
--keylength ec-384 \
--standalone

Es wird der Ordner ~/.acme.sh/mail.occumail.net_ecc erzeugt. Darin enthalten sind die gleichen Dateien wie für den RSA Fall.

Zertifikate Installieren

Nun müssen wir die Zertifikate noch installieren, d.h. von ~/.acme in die richtigen Zielordner verschieben. Auch das übernimmt acme.sh für uns. Wir benötigen den Private Key und unser Zertifikat einschließlich Chain of Trust. Außerdem müssen sowohl Postfix als auch Dovecot nach Abschluss neu gestartet werden, insbesondere auch beim automatischen Ausstellen neuer Zertifikate. Die Berechtigungen für die kopierten Dateien werden von acme.sh automatisch auf 600 gesetzt, sodass ein Zugriff nur vom Besitzer der Datei möglich ist.

Der Code für RSA:

acme.sh --install-cert -d mail.occumail.net \
--key-file /etc/ssl/private/mail.occumail.net.key \
--fullchain-file /etc/ssl/certs/mail.occumail.net.cer \
--reloadcmd "service postfix restart; service dovecot restart"

Und für ECDSA:

acme.sh --install-cert -d mail.occumail.net \
--key-file /etc/ssl/private/mail.occumail.net_ecc.key \
--fullchain-file /etc/ssl/certs/mail.occumail.net_ecc.cer \
--reloadcmd "service postfix restart; service dovecot restart" \
--ecc

Auch diese Operationen werden in der Datei ~/.acme.sh/mail.occumail.net/mail.occumail.net.conf bzw. ~/.acme.sh/mail.occumail.net_ecc/mail.occumail.net.conf persistiert, sodass das Installieren von Zertifikaten in Zukunft ebenfalls automatisiert erfolgt.

3.2 (E)DH-Key erzeugen

Postfix nutzt Forward Secrecy bereits ohne weitere Konfiguration. Allerdings werden für den Schlüsselaustausch via Forward Secrecy geeigneten Cipher-Suiten (EDH) bereits vorberechnete DH-Schlüssel mit 2048-Bit und 512-Bit verwendet. Wir berechnen einen neuen Schlüssel.

Das BSI empfiehlt aktuell noch einen Key mit mindestens 2048 Bits. Ab dem Jahr 2022 sollen Keys mit einer Größe von mindestens 3072 Bits verwendet werden. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Die ganze sicheren unter uns können dann noch 4096 Bits einsetzen. Ich habe mich für den Mittelweg entschieden und damit langfristig vorgesorgt.

Die Generierung kann wie folgt angestoßen werden:

openssl dhparam -out /etc/postfix/dh_3072.pem -2 3072

TLS-Konfiguration von Postfix

Unter GNU/Linux finden Sie die zentrale Konfigurationsdatei von Postfix unter:

/etc/postfix/main.cf

Hier finden Sie mehrere Paramater der folgenden Form:

  • Ist smtp_XXX vorangestellt, gelten die Einstellungen für das Versenden von E-Mails. Also E-Mails, die Postfix an einen anderen Mailserver versendet.
  • Ist smtpd_XXX vorangestellt, geht es um zu unserem Server eingehende Mails. Also E-Mails, die Postfix von einem anderen Mailserver empfängt.

Wir konfigurieren Postfix für eingehende Mails wie folgt:

smtpd_tls_security_level = may
#smtpd_tls_security_level = encrypt
smtpd_tls_cert_file = /etc/ssl/certs/mail.occumail.net.cer
smtpd_tls_key_file = /etc/ssl/private/mail.occumail.net.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.occumail.net_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.occumail.net_ecc.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high
smtpd_tls_dh1024_param_file = /etc/postfix/dh_3072.pem
smtpd_tls_received_header = yes
smtpd_tls_eecdh_grade = ultra
smtpd_tls_loglevel = 1
  • smtpd_tls_security_level: may bedeutet, dass standardmäßig verschlüsselt werden soll, aber unverschlüsselte Verbindungen als Fallback zugelassen werden. encrypt bedeutet, dass Verschlüsselung erzwungen wird. Letzteres wäre eigentlich wünschenswert, aber, wie bereits weiter oben beschrieben, verschlüsseln derzeit (Mai 2020) “nur” etwa 90% der Mailserver ihre Verbindung. Es könnten also Mails abgewiesen werden, was dem Sender jedoch mitgeteilt wird. Im Allgemeinen wird (noch) empfohlen hier may zu wählen. Idealisten mögen encrypt bevorzugen.
  • smtpd_tls_cert_file: Unser Zertifikat für RSA
  • smtpd_tls_key_file: Unser Private Key für RSA
  • smtpd_tls_eccert_file: User Zertifikat für ECDSA
  • smtpd_tls_eckey_file: User Private Key für ECDSA
  • smtpd_tls_session_cache_database: Ein Cache für User Sessions. Steigert die Performance von Loginprozessen.
  • smtpd_tls_ciphers: Stärke der Kryptografie bei opportunistischer Kryptografie (smtpd_tls_security_level=may) Der Standardwert ist hier medium und ermöglicht auch die Kommunikation mit veralteten Mailservern. Der Wert sollte auf high gesetzt werden. Wir werden später noch anpassen, welche Chiphers bei high erlaubt sind. Im Zweifelsfall ist es nicht schlimm den Wert high zu nehmen, denn wir haben im Notfall immernoch ein Fallback auf unverschlüsselte Kryptografie.
  • smtpd_tls_mandatory_ciphers: Stärke der Kryptografie bei erzwungener Verschlüsselung (smtpd_tls_security_level=encrypt). Hier sollte eventuell überdacht werden, ob medium eine gute Wahl ist, weil Mails evtl. abgewiesen werden, wenn der Kommunikationspartner keine starke Verschlüsselung untersützt. Idealisten sollten hier trotzdem bei high bleiben. Irrelevant, falls (smtpd_tls_security_level=may).
  • smtpd_tls_protocols: Hier werden alte Protokolle wie SSLv2 (1995), SSLv3 (1996), TLS 1.0 (1999) und TLS 1.1 (2006) augeschlossen. Dies entspricht den aktuellen Empfehlungen. Es bleiben die aktuelle TLS 1.3 Spezifikation von 2018 und als Fallback TLS 1.2 von 2008, welches auch noch als hinreichend sicher gilt. Gilt für (smtpd_tls_security_level=may).
  • smtpd_tls_mandatory_protocols: Protokolle bei smtpd_tls_security_level=encrypt.
  • smtpd_tls_dh1024_param_file: Der Diffie-Hellman Schlüssel, den wir in einem vorherigen Schritt erzeugt haben. Wir ersetzten hier den standardmäßigen 1024 Bit Schlüssel durch einen 2048, 3072 oder 4096 Bit großen Schlüssel (je nach dem, wie Sie sich entschieden haben).
  • smtpd_tls_received_header: Fügt jeder E-Mail einen Header hinzu, welche Kryptografie zum Empfang der Mail verwendet wurde. Für Interessierte.
  • smtpd_tls_eecdh_grade: Sicherheit bei EECDH (elliptische Kurven Kryptografie). Im Default hier strong, was eine 128-bit Sicherheit verspricht. Bei ultra werden 192-bit verwandt, was zusätzliche Sicherheit verspricht. Der Rechenaufwand ist hier etwa doppelt so hoch wie bei 128-bit.
  • smtpd_tls_loglevel: Loglevel für TLS Aktivitäten. Wert zwischen 0 und 4. Bei 1 wird ein guter Trade-Off erreicht. Höhere Werte loggen sehr viel und werden unübersichtlich.

Wir konfigurieren Postfix für ausgehende Mails wie folgt:

Die Konfiguration ist ähnlich zu der obigen zu lesen, nur dass es hier um ausgehende Mails geht:

smtp_tls_security_level = may
#smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_loglevel = 1

TLS Konfiguration

tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION

Die hier angegebene tls_high_cipherlist ist ein guter Kompromiss mit Fokus auf starke Kryptografie. Bei ImmuniWeb erhält man mit dieser Konfiguration eine A+ Rating (Stand Mai 2020). Wer es ausprobieren möchte: Server mit Port angeben (z.B. occumail.net:25). Bei CryptCheck erhält man ein A Ranking (96 von 100 Punkte).

tls_preempt_cipherlist sagt aus, dass der Server die Präferenzen bei der Cipher setzt und nicht auf ggf. vom Client kommende Präferenzen reagiert.

tls_ssl_options sollte auf NO_COMPRESSION aus Sicherheitsgründen auf NO_COMPRESSION gesetzt werden (BREACH, CRIME).

Nicht vergessen: Zum Schluss ein mal Postfix neu starten:

service postfix restart

TLS-Konfiguration von Dovecot

Dovecot hat für die SSL-Konfiguration eine Extra Konfigurationsdatei:

/etc/dovecot/conf.d/10-ssl.conf

Wir konfigurieren diese wie folgt:

ssl = required
ssl_cert = </etc/ssl/certs/mail.occumail.net.cer
ssl_key = </etc/ssl/private/mail.occumail.net.key
ssl_alt_cert = </etc/ssl/certs/mail.occumail.net_ecc.cer
ssl_alt_key = </etc/ssl/private/mail.occumail.net_ecc.key
ssl_client_ca_dir = /etc/ssl/certs
ssl_dh = </etc/postfix/dh_3072.pem
ssl_min_protocol = TLSv1.2
ssl_cipher_list = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
ssl_prefer_server_ciphers = yes
  • ssl: Sollte auf required stehen, sodass Verschlüsselung erzwungen wird. Eigentlich gibt es keinen ernst zu nehmenden Mailclient mehr, der die hier eingesetzte Verschlüsselung nicht unterstützt. Da wir nur das Beste für unsere Nutzer wollen, erzwingen wir daher Verschlüsselung. Wer einen Mailclient nutzt, der hier nicht funktioniert, der sollte lieber gebeten werden den Client zu wechseln als die Dovecot-Konfiguration anzupassen.
  • ssl_cert: Unser RSA Zertifikat
  • ssl_key: Unser RSA Private Key
  • ssl_alt_cert: Unser ECDSA Zertifikat als Alternative zu RSA
  • ssl_alt_key: User ECDSA Private Key als Alterntaive zu RSA
  • ssl_client_ca_dir: Liste vertrauter Zertifizierungsstellen. Wird durch das Betriebssystem unter /etc/ssl/certs zur Verfügung gestellt.
  • ssl_cipher_list: Unsere Ciphers. Wie bei Postfix auch.
  • ssl_dh: Der Diffie-Hellman Schlüssel, den wir vorhin schon für Postfix generiert haben. Je nach dem, dh_2048.pem, dh_3072.pem, dh_4096.pem
  • ssl_min_protocol: Minimale TLS Version. Mit der Angabe TLSv1.2 schließen wird SSLv2, SSLv3, TLS 1.0 und TLS 1.1 aus. TLS 1.3 ist natürlich zugelassen.
  • ssl_cipher_list: Die unterstützen Ciphers. Wie bei Postfix.
  • ssl_prefer_server_ciphers: Auswahl der Ciphers durch Server vor Cliententscheidung bevorzugen.

Damit wären wir auch schon fertig. Nicht vergessen, Dovecot neu zu starten:

service dovecot restart

Fazit

Nun haben wir es geschafft: Eine sichere Konfiguration von Postfix und Dovecot mit ausreichend Abwärtskompatibilität. Außerdem haben wir mit ECDSA-Zertifikaten aktuellste Kryptografie, die in Zukunft sicherlich vermehrt zum Einsatz kommen wird. Zudem erneuern sich unsere Zertifikate automatisch.

Ergebnisse für occumail.net von CryptCheck. Stand: 02.05.2020
Ergebnisse für occumail.net von ImmuniWeb. Stand: 02.05.2020