Ist STARTTLS weniger sicher als TLS / SSL?

In Thunderbird (und ich nehme an, auch in vielen anderen Clients) habe ich die Möglichkeit, zwischen "SSL / TLS" und "STARTTLS" zu wählen.

Nach meinem Verständnis bedeutet "STARTTLS" in einfachen Worten "verschlüsseln, wenn beide Seiten TLS unterstützen, andernfalls verschlüsseln Sie die Übertragung nicht" . Und "SSL / TLS" bedeutet in einfachen Worten "immer verschlüsseln oder überhaupt nicht verbinden" . Ist das richtig?

Oder mit anderen Worten:

Ist STARTTLS weniger sicher als SSL / TLS, weil es auf Klartext zurückgreifen kann, ohne mich zu benachrichtigen?

Die auf dem STARTTLS-RFC für SMTP ( RFC 3207 ) basierende Antwort lautet:

STARTTLS ist weniger sicher als TLS.

Anstatt selbst zu sprechen, erlaube ich dem RFC, für sich selbst zu sprechen, wobei die vier relevanten Bits in Fettdruck hervorgehoben sind :

Ein Man-in-the-Middle-Angriff kann gestartet werden, indem die Antwort "250 STARTTLS" vom Server gelöscht wird. Dies würde dazu führen, dass der Client nicht versucht, eine TLS-Sitzung zu starten. Ein weiterer Man-in-the-Middle-Angriff besteht darin, dem Server zu ermöglichen, seine STARTTLS-Funktion anzukündigen, aber die Anforderung des Clients zum Starten von TLS und die Antwort des Servers zu ändern. Um sich gegen solche Angriffe zu verteidigen beide Clients und Server müssen fähig sein , zu konfiguriert werden , um erfolgreiche TLS Aushandlung eines entsprechenden Cipher - Suite für ausgewählte Hosts zu verlangen , bevor Nachrichten erfolgreich übertragen werden. Die zusätzliche Option der Verwendung von TLS, wenn möglich, sollte ebenfalls bereitgestellt werden. Eine Implementierung MAI Stellen Sie die Möglichkeit bereit, aufzuzeichnen, dass TLS für die Kommunikation mit einem bestimmten Peer verwendet wurde, und eine Warnung zu generieren, wenn es in einer späteren Sitzung nicht verwendet wird.

Wenn die TLS-Aushandlung fehlschlägt oder der Client eine Antwort 454 erhält, muss der Client entscheiden, was als Nächstes zu tun ist. Es gibt drei Hauptoptionen: Fahren Sie mit dem Rest der SMTP-Sitzung fort , [...]

Wie Sie sehen, gibt der RFC selbst an (nicht sehr klar, aber klar genug), dass NICHTS erforderlich ist, dass Clients eine sichere Verbindung herstellen und Benutzer informieren, wenn eine sichere Verbindung fehlschlägt. Es gibt Clients explizit die Möglichkeit, im Hintergrund Klartextverbindungen herzustellen.

Es gibt keinen Unterschied in der Sicherheit zwischen den beiden Optionen.

• SSL / TLS öffnet zuerst eine SSL / TLS-Verbindung und startet dann die SMTP-Transaktion. Dies muss an einem Port erfolgen, an dem noch kein Nicht-SSL / TLS-SMTP-Server ausgeführt wird. Aufgrund der Art der Protokolle ist es nicht möglich, einen einzelnen Port für die Verarbeitung von Nur-Text- und verschlüsselten Verbindungen zu konfigurieren.

• STARTTLS startet die SMTP-Transaktion und sucht in der Antwort auf EHLO Unterstützung für TLS vom anderen Ende. Wenn der Client STARTTLS in der Liste der unterstützten Befehle sieht, sendet er STARTTLS und beginnt mit der Aushandlung für die Verschlüsselung. All dies kann (und wird in der Regel) auf dem Standard-SMTP-Port 25 erfolgen, teilweise aus Gründen der Abwärtskompatibilität, aber auch, um eine opportunistische Verschlüsselung zwischen Endpunkten zu ermöglichen, die beide unterstützt, jedoch nicht unbedingt erforderlich sind.

Im Allgemeinen wird SSL / TLS nur zwischen Endclients und Servern verwendet. STARTTLS wird häufiger zwischen MTAs verwendet, um den Transport zwischen Servern zu sichern.

In Anbetracht dieser beiden Implementierungen kann STARTTLS als unsicher angesehen werden, wenn der Benutzer oder Administrator davon ausgeht, dass die Verbindung verschlüsselt ist, sie jedoch nicht so konfiguriert hat, dass sie verschlüsselt werden muss. Die verwendete Verschlüsselung entspricht jedoch genau der von SSL / TLS und ist daher für einen Man-in-the-Middle-Angriff über diese Art von Konfigurationsfehler hinaus nicht mehr oder weniger anfällig.

Insbesondere für E-Mails wurde im Januar 2018 RFC 8314 veröffentlicht, in dem ausdrücklich empfohlen wird, "Implizites TLS" anstelle des STARTTLS-Mechanismus für IMAP-, POP3- und SMTP-Übermittlungen zu verwenden.

In Kürze empfiehlt dieses Memo nun Folgendes:

• TLS Version 1.2 oder höher kann für den gesamten Datenverkehr zwischen MUAs und Mail-Übermittlungsservern sowie zwischen MUAs und Mail-Zugriffsservern verwendet werden.
• MUAs und Mail Service Providers (MSPs) (a) raten von der Verwendung von Klartextprotokollen für den Mailzugriff und die Mailübermittlung ab und (b) lehnen die Verwendung von Klartextprotokollen für diese Zwecke ab, sobald dies praktikabel ist.
• Verbindungen zu Mail-Übermittlungsservern und Mail-Zugriffsservern werden mithilfe von "Implicit TLS" (wie unten definiert) hergestellt, anstatt eine Verbindung zum "Klartext" -Port herzustellen und TLS mithilfe des Befehls STARTTLS oder eines ähnlichen Befehls auszuhandeln .

(Betonung hinzugefügt)

Die Antwort hängt bis zu einem gewissen Grad davon ab, was Sie mit "sicher" meinen.

Erstens erfasst Ihre Zusammenfassung den Unterschied zwischen SSL / TLS und STARTTLS nicht ganz.

• Mit SSL / TLS öffnet der Client eine TCP-Verbindung zu dem "SSL-Port", der dem Anwendungsprotokoll zugewiesen ist, das er verwenden möchte, und beginnt sofort mit dem Sprechen von TLS.
• Mit STARTTLS öffnet der Client eine TCP-Verbindung zu dem "Klartext-Port", der dem zu verwendenden Anwendungsprotokoll zugeordnet ist, und fragt den Server "Welche Protokollerweiterungen unterstützen Sie?". Der Server antwortet dann mit einer Liste von Erweiterungen. Wenn eine dieser Erweiterungen "STARTTLS" ist, kann der Client "Okay, lass uns TLS verwenden" sagen und die beiden beginnen TLS zu sprechen.

Wenn der Client so konfiguriert ist, dass TLS erforderlich ist, sind die beiden Ansätze mehr oder weniger gleichermaßen sicher. Es gibt jedoch einige Feinheiten, wie STARTTLS verwendet werden muss, um die Sicherheit zu gewährleisten, und es ist für die STARTTLS-Implementierung etwas schwieriger, diese Details richtig zu machen.

Wenn der Client dagegen so konfiguriert ist, dass TLS nur verwendet wird, wenn TLS verfügbar ist, und wenn TLS nicht verfügbar ist, muss der Client zunächst versuchen, eine Verbindung zum vom Protokoll verwendeten SSL-Port herzustellen, und wenn dies der Fall ist schlägt fehl, stellen Sie eine Verbindung zum Klartext-Port her, und versuchen Sie, STARTTLS zu verwenden, und greifen Sie schließlich auf Klartext zurück, wenn TLS in beiden Fällen nicht verfügbar ist. Für einen Angreifer ist es ziemlich einfach, die SSL-Port-Verbindung zum Scheitern zu bringen (es sind lediglich einige zeitlich gut abgestimmte TCP-RST-Pakete oder das Blockieren des SSL-Ports erforderlich). Für einen Angreifer ist es etwas schwieriger, die STARTTLS-Aushandlung zu vereiteln und den Datenverkehr im Klartext zu halten. Und dann kann der Angreifer nicht nur Ihre E-Mail lesen, sondern auch Ihren Benutzernamen / Ihr Kennwort für die zukünftige Verwendung erfassen.

Wenn Sie also eine Verbindung zu einem Server herstellen, von dem Sie bereits wissen, dass er TLS unterstützt (wie dies beim Senden oder Lesen von E-Mails der Fall sein sollte), sollten Sie SSL / TLS verwenden. Wenn die Verbindung angegriffen wird, schlägt der Verbindungsversuch fehl, aber Ihr Kennwort und Ihre E-Mail-Adresse werden nicht gefährdet.

Wenn Sie jedoch eine Verbindung zu einem Dienst herstellen, von dem Sie nicht wissen, ob er TLS unterstützt, ist STARTTLS möglicherweise geringfügig besser.

Als STARTTLS erfunden wurde, waren "passive" Angriffe nur zum Abhören sehr verbreitet, "aktive" Angriffe, bei denen der Angreifer Datenverkehr injizierte, um die Sicherheit zu verringern, waren weniger verbreitet. In den rund 20 Jahren seitdem sind aktive Angriffe praktikabler und häufiger geworden.

Wenn Sie beispielsweise versuchen, einen Laptop an einem Flughafen oder an einem anderen öffentlichen Ort zu verwenden und Ihre E-Mails über das dort bereitgestellte WLAN zu lesen, wissen Sie nicht, wie sich das WLAN-Netzwerk auf Ihren Datenverkehr auswirkt. In WLAN-Netzwerken werden bestimmte Arten von Datenverkehr häufig an "Proxys" weitergeleitet, die sich zwischen Ihren Client-Anwendungen und den Servern befinden, mit denen sie kommunizieren möchten. Für diese Proxys ist es trivial, STARTTLS zu deaktivieren und "einen Port nach dem anderen zu testen", um Ihren Client dazu zu bringen, auf Klartext zurückzugreifen. Ja, das passiert und ist nur ein Beispiel dafür, wie Ihr Datenverkehr von einem Netzwerk ausspioniert werden kann. Und solche Angriffe sind nicht auf staatlich unterstützte Drei-Buchstaben-Agenturen beschränkt.

Ja, Sie haben die Grundlagen richtig. Und ja, STARTTLS ist definitiv weniger sicher. Es kann nicht nur ohne Benachrichtigung zu Klartext zurückkehren, sondern es kann auch Man-in-the-Middle-Angriffen unterliegen. Da die Verbindung im Klartext beginnt, kann ein MitM den STARTTLS-Befehl entfernen und verhindern, dass die Verschlüsselung jemals auftritt. Ich glaube jedoch, dass Mailserver festlegen können, dass Übertragungen nur stattfinden, nachdem ein verschlüsselter Tunnel eingerichtet wurde. Sie können das also umgehen.

Warum gibt es so etwas überhaupt? Aus Kompatibilitätsgründen. Wenn keine der beiden Seiten die Verschlüsselung unterstützt, möchten Sie möglicherweise trotzdem, dass die Verbindung ordnungsgemäß hergestellt wird.

Stimmen Sie mit @Greg überein. Diese Angriffe sind möglich. Die MTAs können jedoch (je nach MTA) so konfiguriert werden, dass "obligatorisches TLS" und nicht "opportunistisches TLS" verwendet wird. Dies bedeutet, dass TLS und nur TLS (dies beinhaltet auch STARTTLS) für die E-Mail-Transaktionen verwendet wird. Wenn der Remote-MTA STARTTLS nicht unterstützt, wird die E-Mail zurückgeschickt.

Nein, es ist nicht weniger sicher, wenn Ihre Anwendung es richtig handhabt.

Es gibt vier Möglichkeiten, mit TLS umzugehen, und bei vielen Programmen können Sie wählen:

• Kein TLS
• TLS am dedizierten Port (versucht nur TLS)
• TLS verwenden , wenn verfügbar (Tries starttls, verwendet eine unverschlüsselte Verbindung , wenn es fehlschlägt)
• Immer TLS verwenden (Verwendet starttlsund schlägt fehl, wenn es nicht funktioniert)

Der Vorteil von TLS an einem dedizierten Port ist, dass Sie sicher sein können, dass es keinen Fallback gibt, wenn Sie ein Programm verwenden, das Sie noch nicht kennen oder das die Detaileinstellungen für die Fehlerbehandlung in seinem Erststart-Assistenten nicht offenlegt.

Im Allgemeinen hängt die Sicherheit jedoch vom Umgang mit Sicherheitsfehlern ab. Ein Programm könnte entscheiden, auf den Klartext-Port zu wechseln, wenn TLS auf dem TLS-Port ebenfalls ausfällt. Sie müssen wissen, was es tun wird, und sichere Einstellungen auswählen. Und Programme sollten sichere Standardeinstellungen verwenden.