- Details
Mit dem am 5. Juli dieses Jahres veröffentlichten Sendmail Release 8.16.1 unterstützt der alteingesessene MTA erstmals DANE (DNS-Based Authentication of Named Entities).
Um DANE aktivieren zu können, muss Sendmail wie hier mit _FFR_TLSA_DANE kompiliert werden:
[root@c7 mail]# sendmail -d0.1 </dev/null
Version 8.16.1
Compiled with: DANE DNSMAP IPV6_FULL LDAPMAP LDAP_NETWORK_TIMEOUT LOG
MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND
NETINET NETINET6 NETUNIX NEWDB=5.3 PIPELINING SASLv2 SCANF
SOCKETMAP STARTTLS TLS_EC TLS_VRFY_PER_CTX USERDB USE_LDAP_INIT
[...]
Einschalten in sendmail.mc:
define(`confDANE')dnl
Diese Konfiguration von DANE aktiviert gleichzeitig die nun notwendigen ResolverOptions use_dnssec und use_edns0.
Ganz einfach und schnell eingerichtet, Ende der Geschichte. Ja, was die Sendmail-Konfiguration für Opportunistic DANE betrifft, aber damit das in Sendmail (oder irgendeiner anderen Applikation) auch gemäß RFC 7672 funktioniert, müssen wir was kontrollieren und ggf. vorbereiten ...
- Details
Sendmail 8.16.1 (veröffentlicht am 5. Juli 2020) bringt in erster Linie Erweiterungen im Bereich TLS.
TLS
Die in Sendmail 8.15.2 bereits als FFR (For Future Release) vorhandenen session-basiert einstellbaren TLS Features sind jetzt offiziell unterstützter Bestandteil. Eingestellt werden können durch Semikolon getrennt folgende key=value Paare:
- ServerSSLOptions, ClientSSLOptions z.B. zur Einschränkung der erlaubten SSL-Versionen (siehe SSL_set_options(3))
- CipherList
- Cert- und KeyFile geben Zertifikats- und Schlüssel-Datei für diese Session an
- Flags (bisher 2)
- R für CRL (Certificate Revocation List) benötigt
- c, C zum Aus- bzw. Einschalten der neuen Option TLSFallbacktoClear (siehe unten)
Beispiel für Access-DB bei aktiviertem FEATURE `tls_session_features':
TLS_Clt_features:192.168.2.2 Options=SSL_OP_NO_TLSv1_2; CipherList=ALL:-EXPORT; Flags=C
Interoperabilitätsprobleme bei TLS kann Sendmail jetzt automatisch umschiffen, indem er nach gescheitertem Handshake die Verbindung zur Gegenstelle erneut aufbaut, dieses Mal ohne Verwendung von STARTTLS. Dieses Verhalten wird global durch die Konfiguration von TLSFallbacktoClear erreicht oder per Session durch Setzen des C-Flags der TLS_Clt_Features (siehe oben). Vor 8.16 konnte man lediglich für bekannte inkompatible Server statische TLS-Ausnahmen (Try_TLS:broken.server NO) einrichten.
- Details
Das im Januar 2018 veröffentlichte RFC 8314 "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access" beschreibt die Verwendung von TLS bei E-Mail-Abruf und -Einlieferung in modernen E-Mail-Systemen. E-Mail-Abruf und -Einlieferung durch Mail User Agents (MUAs) bei Mail Access Servern und Mail Submission Servern sollen demnach nur noch über TLS-verschlüsselte Verbindungen (TLS Version 1.2 oder höher) erfolgen.
Neu, beachtens- und begrüßenswert ist, dass jetzt "Implicit TLS" die favorisierte Methode für die Transport-Verschlüsselung bei Abruf und Einlieferung von Mails durch MUAs ist, während vorhergehende Regelungen noch STARTTLS empfahlen. Folgerichtig wurde der bereits vielerorts für Secure Submission verwendete Port 465 im Dezember 2017 auf den Dienst Submissions offiziell registriert. RFC 8314 ist auch ein Update für die Spezifikationen von POP3 (RFC 1939), IMAP (RFC 3501) und Submission (RFCs 6409 und 5068).
Mit STARTTLS stellt ein Client zunächst eine unverschlüsselte Verbindung auf dem (in der Regel Standard-)Klartext-Port des gewünschten Dienstes mit einem Server her und kann anschließend durch das Kommando STARTTLS (STLS bei POP3) eine TLS-Session initiieren ("Explicit TLS"). Im Unterschied dazu wird bei "Implicit TLS" direkt nach dem TCP Handshake ein TLS-verschlüsselter Kanal zwischen Client und Server aufgebaut.
Authentifizierungs-Daten sollen bei beiden Methoden erst dann über die Leitung gehen, wenn die Verbindung verschlüsselt ist. Für SMTP, IMAP und POP3 sind denn auch jeweils Methoden (siehe unten) definiert, genau dies vom Client zu fordern, will man keinen Klartext-Verkehr erlauben. Doch sind diese natürlich im Gegensatz zur impliziten TLS-Verschlüsselung auf dedizierten TLS Ports bereits protokollbedingt anfällig für Implementierungs-Schwächen auf Client-Seite und Man-in-the-middle-Angriffe.
- Details
Mit Version 8.15.x bietet Sendmail die Möglichkeit, ausgewählten E-Mails einen BCC-Empfänger auf MTA-Ebene hinzuzufügen.
Hierfür muss Sendmail im ersten Schritt mit der Option '_FFR_ADD_BCC' kompiliert werden:
[root@popc ~]# sendmail -d0.14 < /dev/null
Version 8.15.2
[...]
FFR Defines: _FFR_ADD_BCC _FFR_MAIL_MACRO _FFR_TLS_EC
_FFR_TLS_SE_OPTS
Anschließend lässt sich das Feature `bcc' wie folgt in sendmail.mc konfigurieren:
FEATURE(`bcc',`<map>’‚`[next hop]',`[default bcc address]'[‚`map for canonical recipients'])dnl
- Details
Am 3. Juli wurde Sendmail 8.15.2 veröffentlicht.
Der heimliche Star unter den Neuheiten ist das Feature 'tls_session_features', welches für TLS die Möglichkeit eröffnet, Optionen (z. B. das Abschalten best. Protokolle), Cipher Lists und Zertifikate/Keys in Abhängigkeit der Gegenstelle zu setzen.
Für den Einsatz von 'tls_session_features' muss Sendmail mit '_FFR_TLS_SE_OPTS' kompiliert werden:
[root@popc ~]# sendmail -d0.14
Version 8.15.2
[...]
FFR Defines: _FFR_TLS_EC _FFR_TLS_SE_OPTS
Mit der Konfiguration in sendmail.mc:
FEATURE(`tls_session_features')dnl
werden die Rulesets 'tls_srv_features' und 'tls_clt_features' in sendmail.cf aktiviert. Die Konfiguration erfolgt bequem in der Access-DB, z.B. wenn die Kommunikation seit dem letzten OpenSSL-Update aufgrund zu kurzer Diffie-Hellmann-Primzahlen mit einem bestimmten Server mit DHE-Ciphern nicht möglich ist (In vorherigen Versionen gab es, sofern sich der Server für einen DHE-Cipher entschied, nur die Möglichkeit, keine Mails mehr oder, weil es die meisten MTAs zulassen, unverschlüsselt zu versenden.):
TLS_Clt_features:10.2.2.2 Cipherlist=HIGH:MEDIUM:!aNULL:!eNULL:!DH
Ab Loglevel 14 lässt sich der Effekt gut beobachten:
Jul 10 17:41:03 popc sendmail[7302]: STARTTLS=client, init=1
Jul 10 17:41:03 popc sendmail[7302]: STARTTLS=client, start=ok
Jul 10 17:41:03 popc sendmail[7302]: tls_clt_features=Cipherlist=HIGH:MEDIUM:!aNULL:!eNULL:!DH, relay=test.sendmaid.org [10.2.2.2]
Jul 10 17:41:03 popc sendmail[7302]: tls_clt_features=parsed, Cipherlist=HIGH:MEDIUM:!aNULL:!eNULL:!DH, relay=test.sendmaid.org [10.2.2.2]
[...]
Jul 10 17:41:03 popc sendmail[7302]: STARTTLS=client, relay=test.sendmaid.org., version=TLSv1.2, verify=FAIL, cipher=AES256-GCM-SHA384, bits=256/256
Weiterlesen: Sendmail 8.15.2 glänzt mit Session-basierten TLS-Features
- Details
In ungewohnt nebulösen Worten fabuliert das beliebte Batbook um das in Sendmail 8.14 neu eingeführte Feature 'badmx' herum. Es werden Windows PCs angeführt, die per DHCP ihre IP-Adresse beziehen und deshalb oder weil sie gekapert wurden keinen MX-Record publizieren. Öh...?
Die Funktionsweise wird so erklärt, dass ein Sendmail Server für den sich verbindenden Client den Hostnamen per Reverse Lookup ermittelt, auf den Domain-Anteil reduziert und daran MX Lookups vornimmt. Das ist natürlich Quatsch für 'badmx'. Die Prüfungen des Features beziehen sich auf die Domain der Absender-Adresse. (Die IP der Gegenstelle benutzt das in Sendmail 8.14 ebenfalls neu eingeführte Feature 'require_rdns'.)
Die Release Notes von Sendmail 8.14.0 bringen es auf den Punkt:
CONFIG: New FEATURE(`badmx') to reject envelope sender addresses
(MAIL) whose domain part resolves to a "bad" MX record.
Based on contribution from William Dell Wisner
Der Aufruf des Rulesets 'BadMX' erfolgt am Ende von 'check_mail'. Zunächst ermittelt Sendmail darin die MX-Records für die Domain des Absenders mit Hilfe der Map 'bestmx' und führt den ersten Check auf Basis einer 'regex' Map durch:
1. Zeigt einer der MX-Records nicht auf einen Full Qualified Domainname, sondern auf eine IP-Adresse, ist er "bad" und die Mail wird abgelehnt mit der Meldung:
550 5.1.2 <user@domain>... Illegal MX record for host <domain>
Im zweiten Schritt werden die A-Records zu allen MX-Records ermittelt und mit Hilfe einer weiteren 'regex' Map geprüft:
2. Ist eine der IPs Loopback (beginnt mit 127.), nicht route-fähig (beginnt mit 10.) oder die 0.0.0.0, wird die Mail abgelehnt mit der Meldung:
550 5.1.2 <user@domain>... Invalid MX record for host <domain>
Referenzen:
1. Costales, Jansen, Aßmann with Shapiro. sendmail 4th Edition. a.k.a. "bat book", S. 291-292
- Details
Seit gefühlt ewigen Zeiten (seit V8) kennt Sendmail einzelne Timeouts für jede erdenkliche Situation des SMTP-Dialogs, drei ('iconnect', 'connect' und 'aconnect') davon alleine für den Verbindungsaufbau als Client zu einem SMTP-Server.
Die Default-Werte der Timeouts können in der laufenden sendmail.cf nachgeschlagen werden:
[root@popc mail]# grep "O Timeout" sendmail.cf
#O Timeout.initial=5m
#O Timeout.connect=5m
#O Timeout.aconnect=0s
#O Timeout.iconnect=5m
#O Timeout.helo=5m
O Timeout.mail=5m
#O Timeout.rcpt=1h
[...]
Alle mit dem Kommentarzeichen "#" versehenen Timeouts sind Defaults, die in Sendmail deutlich großzügiger sind, als die in RFC 5321 (siehe Abschnitt 4.5.3.2) empfohlenen Minimalwerte. Auffällig ist bspw. der Timeout für die Bestätigung jedes einzelnen Empfängers durch die Gegenstelle ('Timeout.rcpt'), auf die Sendmail geduldig eine Stunde wartet. Verständlich also, dass insb. bei Outgoing MTAs an den Timeouts gedreht wird.
Wer die Connection Timeouts heruntersetzen will, muss das spezielle Verhältnis zwischen 'connect' und 'aconnect' beachten!
'Timeout.connect' ist die Zeit, die Sendmail versucht, die Verbindung zu einer Gegenstelle herzustellen, während 'Timeout.aconnect' die Zeit bezeichnet, die Sendmail für den gesamten Zustellversuch zur Verfügung hat, z.B., um mehrere MX Hosts zu probieren, wenn die höher priorisierten nicht erreichbar sind. Ist dieser Timeout abgelaufen, wird der Zustellversuch abgebrochen und der nächste für die Mail erst im folgenden Queuerun wieder unternommen. 'Timeout.initial' verhält sich wie 'Timeout.connect', bezieht sich aber nur auf den allersten Versuch, eine Mail zuzustellen. Für alle weiteren Versuche kommt 'Timeout.connect' zum Einsatz.
Wird nun 'Timeout.aconnect' gleich 'Timeout.connect' gesetzt, kann Sendmail bei jedem Zustellversuch immer nur den ersten MX Server nehmen, so dass betroffene Mails bis zu dessen Wiedererreichbarkeit in der Queue verbleiben. Im Log ist das Phänomen daran zu erkennen, dass nicht der MX Server mit der niedrigsten Priorität in der Fehlermeldung steht, sondern in diesem Fall der mit der höchsten, nämlich der, den Sendmail aufgrund seiner Timeouts gerade noch versuchen durfte.
- Details
Adrian et al zeigen in ihrem spannenden Paper nicht nur den von ihnen Logjam genannten Angriff, der auf einem Downgrade auf nur 512-Bit Diffie-Hellman Parameter des unsicheren Ciphers DHE_EXPORT (abschalten!) basiert, sondern haben in HTTPs Scans auch beobachtet, dass in TLS vielfach quasi Standard-Gruppen sowohl für 512 als auch für 768 und 1024 Bit verwendet werden, dies sind entweder die Built-ins (dh512_p, dh1024_p) des weit verbreiteten Apache Webservers oder die in RFC 2409 definierten Oakley Gruppen 1 (768 Bit) und 2 (1024 Bit).
Auch wenn sich die Wissenschaftler selbst mit ihren Ressourcen außerstande sehen, 1024-Bit Diffie-Hellman Gruppen zu knacken, muss dies ihren Ausführungen zufolge nicht für Institutionen gelten, die weitaus mehr Geld für derlei Berechnungen ausgeben können. Da zudem die für Logjam verwendete Methode mit weitestgehenden Vorausberechnungen für die 512-Bit Built-in DH Parameter von Apache, die von den Kryptologen in nur einer Woche vorgenommen werden konnten, arbeitet, empfehlen sie den Einsatz eigens erzeugter Diffie-Hellman 2048-Bit Parameter.
Open Source Software arbeitet i.d.R. mit OpenSSL, das die notwendige Sicherheit bzgl. der Diffie-Hellman Parameter bietet. Ein genauer Blick auf die Dokumention und letztlich die Sourcen der eingesetzten Software lohnt sich jedoch und wer selbst bereits 2048-Bit DH Parameter mittels 'openssl dhparam' produziert hat, kann nachvollziehen, dass kein Server diese, nicht einmal 1024-Bit, beim Start erzeugen und trotzdem binnen einer Sekunde für TLS-Verbindungen bereitstehen kann. Wenn man selbst also keine Parameter zum simplen Einlesen für den Server produziert hat, muss er eigene "Tricks" anwenden, z.B. mittels Built-ins, dem Erzeugen geeigneter Primzahlen beim Kompilieren, "einfacheren" DH-Gruppen etc.
Weiterlesen: Sichere Diffie-Hellman Parameter vor und nach Logjam
- Details
Die neue Sendmail-Version 8.15.1 bringt, obwohl das erste Major Release seit mehr als 7 Jahren, keine dramatischen Änderungen, erleichtert jedoch mit ihren vielen kleinen Verbesserungen an der einen oder anderen Stelle die Arbeit.
Die komplette Liste der Änderungen ist hier zu finden.
Zu beachten ist die Entscheidung der Entwickler, IPv6-Adressen defaultmäßig nur noch in ihrer unkomprimierten Form zu verarbeiten. IPv6-Nutzer müssen ihre Maps, Klassen oder selbstgeschriebenen Rulesets also eventuell anpassen. Das alte Verhalten kann mittels der Compile Option '-DIPV6_FULL=0' in der 'devtools/Site/site.config.m4' wieder hergestellt werden. Welche Addressform der eigene Sendmail spricht, erkennt man an den 'Compiled with:' Optionen:
[root@popc ~]# sendmail -d0.1 < /dev/null
Version 8.15.1
[...]
Compiled with: DNSMAP IPV6_FULL LOG MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETUNIX NEWDB PIPELINING SASLv2 SCANF
STARTTLS USERDB XDEBUG
[...]
Fehlt hier 'IPV6_FULL', wird die alte, komprimierte Form verwendet.
Die Compile Option '_FFR_TLS_1' wurde entsorgt, so dass die früher erst duch sie hervorgezauberten SSL-Optionen ('ServerSSLOptions', 'ClientSSLOptions' und 'CipherList') jetzt standardmäßig zur Verfügung stehen und damit auch in mc-Notation (und nicht mehr nur als Optionen unterhalb von 'LOCAL_CONFIG') konfiguriert werden können:
define(`confSERVER_SSL_OPTIONS', `+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE')dnl
define(`confCLIENT_SSL_OPTIONS', `+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3')dnl
define(`confCIPHER_LIST', `HIGH:MEDIUM:!aNULL:!eNULL@STRENGTH')dnl
'_FFR_TLS_EC' für die Verwendung der Elliptic Curve Varianten des Diffie-Hellman-Verfahrens muss auch in 8.15.1 beim Kompilieren gesetzt werden.
Schön ist auch, dass 8.15.1 'SSL_get_version' anstatt von 'SSL_CIPHER_get_version' zu Rate zieht, weil es einfach abwechslungsreicher ist, die richtige SSL-Protokoll-Version im Log zu sehen und nicht immer nur 'TLSv1/SSLv3'.
Referenzen:
1. http://compgroups.net/comp.mail.sendmail/sendmail-8.15.1-available/3007787