TLS Encryption

Auf dieser Seite können Sie die Transport Layer Security-Optionen für den MTA konfigurieren. TLS gewährleistet nahtlos die Transportverschlüsselung von E-Mails bei der Zustellung über SMTP zwischen unterstützenden Servern.

TLS-Einstellungen

Libraesva ESG agiert sowohl beim Empfangen als auch beim Senden von E-Mails, sodass TLS auf beiden Seiten konfiguriert werden kann: Sie können unterschiedliche Richtlinien für den Empfang (Server) oder das Senden (Client) festlegen. Die Standardrichtlinie für eingehende und ausgehende Verbindungen kann eine der folgenden sein:

• none (kein TLS beim Empfangen von E-Mails)
• may (versucht, eine TLS-Verbindung auszuhandeln, dies ist der Standard)
• encrypt (erzwingt eine TLS-Verbindung beim Empfangen einer E-Mail; schlägt dies fehl, wird die eingehende E-Mail nicht angenommen)

Warnung: Gemäß RFC 2487 DARF die Verschlüsselung bei einem öffentlich referenzierten SMTP-Server NICHT erzwungen werden. Andernfalls würden Sie legitimen E-Mail-Verkehr ablehnen. Durch das Einrichten des Parameters SMTP Supported Ciphers können Sie den minimalen TLS-Cipher-Grad auswählen, den der MTA verwenden wird. Diese Einstellung ermöglicht die Einschränkung der verfügbaren Ciphers und Protokolle. Um mehr über die unterstützten TLS-Protokolle und Ciphers für jeden Cipher-Grad zu erfahren, lesen Sie den Wissensdatenbank-Artikel Supported TLS Ciphers. Warnung: Bei einem öffentlich referenzierten SMTP-Server besteht das Standardverhalten darin, auf Klartext zurückzufallen, wenn keine gemeinsame Cipher/Protokoll-Kombination mit der Gegenstelle ausgehandelt werden kann. Das bedeutet, dass durch die Einschränkung der Cipher-Liste die Wahrscheinlichkeit eines Rückfalls auf Klartext steigt.

Zielbasierte SMTP/TLS-Client-Policy-Maps

Eine abweichende TLS-Richtlinie kann für Next-Hop-Ziele festgelegt werden. Diese Einstellungen überschreiben die Standardeinstellungen für ausgehende Verbindungen. Jede Richtlinie wird durch 3 Parameter definiert:

• Destination (das Next-Hop-Ziel als Domain, Mailserver oder IP-Adresse. Bei Angabe eines Mailservers oder einer IP-Adresse diese in eckigen Klammern angeben [1.2.3.4])
• Policy
  • None (kein TLS)
  • May (opportunistisches TLS. Die optionalen Attribute „ciphers“, „exclude“ und „protocols“ sind verfügbar)
  • Encrypt (verpflichtende Verschlüsselung. Die E-Mail wird nur zugestellt, wenn der entfernte SMTP-Server STARTTLS anbietet und der TLS-Handshake erfolgreich ist. Auf dieser und höheren Stufen sind die optionalen Attribute „protocols“, „ciphers“ und „exclude“ verfügbar)
  • Dane (verpflichtende Verschlüsselung. Die E-Mail wird nur zugestellt, wenn der entfernte SMTP-Server STARTTLS anbietet und der TLS-Handshake erfolgreich ist. Auf dieser und höheren Stufen sind die optionalen Attribute „protocols“, „ciphers“ und „exclude“ verfügbar)
  • Dane-only (verpflichtendes DANE-TLS. Die TLS-Richtlinie für das Ziel wird über TLSA-Einträge in DNSSEC ermittelt. Werden keine TLSA-Einträge gefunden oder sind keine nutzbar, wird keine Verbindung zum Server hergestellt)
  • Fingerprint (Zertifikats-Fingerabdruck-Verifizierung. Auf dieser Sicherheitsstufe gibt es keine vertrauenswürdigen Zertifizierungsstellen. Die Zertifikatsvertrauenskette und das Ablaufdatum werden nicht geprüft. Stattdessen listet das optionale Attribut „match“ die Fingerabdrücke des Serverzertifikats oder der öffentlichen Schlüssel auf. Der zur Berechnung der Fingerabdrücke verwendete Digest-Algorithmus ist SHA256. Mehrere Fingerabdrücke können in einem einzigen match-Attribut mit dem Trennzeichen „|“ kombiniert werden)
  • Verify (verpflichtende Serverzertifikat-Verifizierung. Die E-Mail wird nur zugestellt, wenn der TLS-Handshake erfolgreich ist, das Zertifikat des entfernten SMTP-Servers validiert werden kann (nicht abgelaufen oder widerrufen und von einer vertrauenswürdigen Zertifizierungsstelle signiert) und der Name des Serverzertifikats mit dem optionalen „match“-Attribut übereinstimmt)
  • Secure (Secure-Channel-TLS. Auf dieser Sicherheitsstufe werden DNS-MX-Lookups, obwohl sie möglicherweise zur Bestimmung der Kandidaten-Next-Hop-IP-Adressen verwendet werden, nicht als ausreichend sicher für die TLS-Peer-Namensverifizierung angesehen. Stattdessen wird der Standardname, der im Serverzertifikat verifiziert wird, direkt vom Next Hop bezogen oder explizit über das optionale match-Attribut angegeben. Das match-Attribut ist besonders nützlich, wenn mehrere Domains von einem gemeinsamen Server unterstützt werden: Die Richtlinieneinträge für zusätzliche Domains geben Übereinstimmungsregeln für das primäre Domain-Zertifikat an. Während Transporttabellen-Überschreibungen, die sekundäre Domains zum primären Next-Hop leiten, ebenfalls eine sichere Verifizierung ermöglichen, besteht das Risiko einer Zustellung an das falsche Ziel, wenn Domains den Besitzer wechseln oder neuen Gateways zugewiesen werden. Mit dem „match“-Attribut-Ansatz wird das Routing nicht gestört, und E-Mails werden zurückgestellt, wenn die Verifizierung eines neuen MX-Hosts fehlschlägt)
• Attribute (geben Sie ein optionales Richtlinienattribut an)

Hinweis: Der zur Berechnung und Verifizierung von Zertifikats-Fingerabdrücken verwendete Digest-Algorithmus ist SHA256.