Na wunderbar, da haben also unsere großen drei E-Mail-Provider GMX, web.de und Telekom endlich mal den Konfigurationsschalter gefunden, um die Verbindung (und auch nur die, nicht etwa die Mails selber…) der Mailserver zu verschlüsseln – und dann funktioniert das Ganze wohl bei vielen Standard-Debian-Mailservern nicht.
Der Grund scheint zu sein, dass Debian wegen der Lizenz (GPL) nicht OpenSSL sondern GnuTLS einsetzt – und dann bekommt man als Betreiber eines solchen Mailservers dann solche Einträge im Logfile:
TLS error on connection from mout.gmx.net [212.227.15.15] (gnutls_handshake): A TLS fatal alert has been received.
Für mich als Nutzer mit einem EXIM4 (heavy, gültiges SSL-Zertifikat von StartSSL) war somit der Empfang sämtlicher Mails zumindest von GMX nicht mehr möglich (ich hatte keine Tester für web.de und Telekom zur Hand).
Man findet auch einige Einträge dazu im Netz, welche sich erstmal an diversen Konfiguratuonsänderungen versuchen (insb. in den CIPHER-Einstellungen oder gar die Deaktivierung von STARTTLS bei diesen Mailserver – kann ja auch nicht Sinn der Sache sein), am Ende läuft es darauf hinaus, dass man sich Exim4 den Source besorgt und dann seine eigene Version gelinkt gegen OpenSSL kompiliert – das funktioniert dann auch und ich bekomme wieder alle Mails 🙂
Also, was darf man in seiner Freude tun?
- Sicherstellen, dass man einen deb-src Eintrag in seiner /etc/apt/sources aktiv hat – meiner lautet
deb-src http://http.debian.net/debian stable main
Nicht vergessen, ein apt-get update nachzuschieben 🙂
- Der Anleitung unter http://unix.stackexchange.com/questions/85231/how-to-recompile-exim4-daemon-heavy folgen (ggf. müsst Ihr noch das eine oder andere mittels apt-get install nachinstallieren)
Dabei vor
dpkg-buildpackage -rfakeroot -us -uc
in der Datei debian/rules den Eintrag mit OpenSSL aktivieren:# If you want to build with OpenSSL instead of GnuTLS, uncomment thisOPENSSL:=1
# Please note that building exim4-daemon-heavy with OpenSSL is a GPL
# violation
- Die dadurch neu entstandene .deb-Datei installieren:
dpkg -i exim4-daemon-heavy_4.80-7_amd64.deb
(oder ähnlich, Versionsnummer und Prozessorarchitektur können natürlich anders sein)
- Sollte eigentlich sofort gehen, wenn Ihr nicht kreative Konfigurationseinträge bzgl. SSL in Eurer Exim4-Config habt.
Danke Made in Germany 🙁
Seltsam. Bei mir funktioniert alles, ohne daß ich irgendwas machen mußte. Das Log zeigt, daß X=TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16 verwendet wurde. (Das war eine Mail von gmx.de.)
Moin,
ich hatte das gleiche Problem mit unserem Mailserver. Hatte aber nach diversen Experimenten die Verschlüsselung für 1&1+Telekom deaktiviert – Die war bei den Jungs ja sowieso Jahre lang aus …
Nun heute nochmal getestet (mit GMX) und läuft out-of-the-box. Die haben also scheinbar was verbessert.
Beste Grüße,
Sven
Super, Danke für den Tipp. Dann kann ich wieder zum Standard-Exim zurück 🙂
Nachdem ich (u.a.) dank Deines Beitrags das Problem im September lösen konnte, habe ich gerade getestet, ob es auch mit GnuTLS läuft. Tut es allerdings noch nicht wieder. Das Fehlerbild hat sich aber geändert. Jetzt kommt da folgender Fehler: „TLS error on connection from mout.gmx.net [212.227.15.15] (gnutls_handshake): A TLS fatal alert has been received.“ Danach wird TLS ausgeschaltet und die Mail unverschlüsselt übertragen.
Im März 2013 folgte die 1&1 Mail and Media GmbH mit ihren Marken GMX und web.de .
schaun wir uns mal die SSL verschlüsselung von gmx.at an: https://www.ssllabs.com/ssltest/a… 27.141.234 kategorie „C“, vieles passt nicht, offen für mindestens eine attacke. web.de: kategeorie B, allerdings für 2 attacken anfällig: https://www.ssllabs.com/ssltest/a… .227.222.8 die sollen mal auf die levels von gmail.com aufschließen bevor sie irgendwelche pressemeldungen rauslassen.
Habe einen neuen Debian Server aufgesetzt und das Problem tritt wie oben beschrieben auf, d.h. auch in der aktuellen Debian Version besteht das Problem!
Mit OpenSSL kann ich nun wieder Mails an GMX senden und von GMX emfpangen, allerdings erfolgt der Versand unverschlüsselt, da folgende Meldung angezeigt wird:
error:1409210A:SSL routines:SSL3_GET_SERVER_HELLO:wrong ssl version
TLS session failure: delivering unencrypted to mx01.gmx.net [213.165.67.115] (not in hosts_require_tls)
Naja, aber immerhin funktioniert der Mailversand jetzt!
Ich habe es (durch persönliche Kontakte bei 1&1) tatsächlich geschafft, eine Antwort von GMX auf meine Anfrage diesbezüglich zu erhalten. Aber natürlich nur Standardkram mit Sicherheit, bestimmte Suites nicht erlaubt (die z.B. Google erlaubt), und ich hätte veraltete Software.
Da mein Server auf Gentoo läuft, konnte ich recht problemlos tatsächlich mal mein GnuTLS updaten. Und siehe da, wenn man Exim gegen GnuTLS 3.2.8 kompiliert, funktioniert sowohl von als auch zu GMX die Übertragung verschlüsselt. Dabei wird jetzt ECDHE_RSA_AES_128_CBC_SHA1 bzw. ECDHE_RSA_AES_128_GCM_SHA256 verwendet. Die gab es vorher noch gar nicht. GnuTLS 3.2.8 gibt es zumindest in den wheezy-backports (als libgnutls28), leider wird aber exim noch nicht mal in sid dagegen kompiliert. Also muss man immer noch selbst Hand anlegen, will man Exim+GnuTLS mit GMX zum Laufen kriegen.
Ich hoffe, das hilft irgendwem.
Auch mit Exim4 unter Wheezy ohne Neukompilierung kann mann verschlüsselt Mails von GMX empfangen. Das Problem liegt nicht eigentlich bei der Übertragung sondern bei der Überprüfung des Zertifikates. Wenn man das GMX Zertifikat ungeprüft annimmt, so funktioniert die verschlüsselte Verbindung.
In main//00_exim4-config_listmacrosdefs oder wo auch immer, das Makro MAIN_TLS_TRY_VERIFY_HOSTS so setzen, dass die Zertifikate, welche mout.gmx.net liefert, von einer Überprüfung ausgeschlossen werden:
MAIN_TLS_TRY_VERIFY_HOSTS = !mout.gmx.net
Dann funktioniert es auch mit GMX wieder:
Received: from mout.gmx.net ([212.227.17.20])
by ente.limmat.ch with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
(Exim 4.80)
(envelope-from )
id 1bJeV1-0006tb-Pl
for XXXXX@XXXXX.com; Sun, 03 Jul 2016 12:19:41 +0200