Frage Ist STARTTLS weniger sicher als TLS / SSL?


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

Soweit ich es verstehe, bedeutet "STARTTLS" in einfachen Worten "Verschlüsseln, wenn beide Enden TLS unterstützen, andernfalls die Übertragung nicht verschlüsseln". Und "SSL / TLS" bedeutet in einfachen Worten "Immer verschlüsseln oder gar nicht verbinden". Ist das richtig?

Oder mit anderen Worten:

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


43
2017-07-16 19:07


Ursprung




Antworten:


Die Antwort basiert auf dem STARTTLS-RFC für SMTP (RFC 3207) ist:

STARTTLS ist weniger sicher als TLS.

Anstatt selbst zu reden, werde ich dem RFC erlauben, für sich selbst zu sprechen, wobei die vier relevanten Bits hervorgehoben sind FETT GEDRUCKT:

Ein Man-in-the-Middle-Angriff kann gestartet werden, indem der "250      STARTTLS "Antwort vom Server. Dies würde den Client nicht verursachen      um zu versuchen, eine TLS-Sitzung zu starten. Ein anderer Mann-in-der-Mitte-Angriff ist      um dem Server zu ermöglichen, seine STARTTLS-Fähigkeit anzukündigen, aber zu ändern      die Anforderung des Clients zum Starten von TLS und die Antwort des Servers. Im      Um sich gegen solche Angriffe zu wehren, MÜSSEN sowohl Clients als auch Server eingesetzt werden Sein      fähig konfiguriert werden, um eine erfolgreiche TLS-Aushandlung eines zu erfordern      geeignete Cipher-Suite für ausgewählte Hosts vor Nachrichten sein kann      erfolgreich übertragen. Das zusätzliche Möglichkeit Verwenden von TLS wann      Möglich SOLL auch zur Verfügung gestellt werden. Eine Implementierung KANN das ____ bereitstellen      Fähigkeit aufzuzeichnen, dass TLS bei der Kommunikation mit einem gegebenen verwendet wurde      Peer und generieren eine Warnung, wenn es in einer späteren Sitzung nicht verwendet wird.

Wenn die TLS-Verhandlung fehlschlägt oder wenn der Client eine 454 erhält      Antwort muss der Kunde entscheiden, was als nächstes zu tun ist. Dort sind drei      Hauptauswahlmöglichkeiten: Fahren Sie mit dem Rest der SMTP-Sitzung fort, [...]

Wie Sie sehen, gibt der RFC selbst an (nicht sehr deutlich, aber deutlich genug), dass NICHTS von den Clients verlangt wird, eine sichere Verbindung herzustellen und die Benutzer zu informieren, wenn eine sichere Verbindung fehlgeschlagen ist. Es ausdrücklich gibt Kunden die Möglichkeit, stillschweigend einzurichten Klartext Verbindungen.


43
2017-12-01 16:43



Ihr Punkt ist sicherlich gültig, aber aufgrund fehlender RFC- oder offizieller Spezifikationen bezüglich SMTPS (dh SMTP + "implizites SSL / TLS", bei dem zuerst SSL / TLS eingerichtet wird) könnten SMTP / SMTPS-Clients auch auf eine einfache Verbindung zurückgreifen wenn es ihnen nicht gelingt, eine SSL / TLS-Verbindung an Port 465 zu initiieren. Dies ist immer noch eine reine Implementierungswahl. - Bruno
Es gibt viele RFCs zum Einrichten von TLS-Verbindungen. Nirgends dort gibt es "erlauben Klartext-Verbindung" als eine Option für die Einhaltung der RFC (zumindest das wäre Nachrichten für viele Leute). Daher benötigt SMTPS keinen separaten RFC, um sicherer zu sein als STARTTLS. - Greg
Es gibt RFCs über TLS (RFC 5246 und Vorgänger), PKI (RFC 5280), Namensprüfung (RFC 6125), aber nichts, um die Interaktion zwischen SMTP und SSL / TLS in SMTPS offiziell AFAIK zu beschreiben, nicht auf die gleiche Weise wie Sie bekommen eine Spezifikation für HTTPS: RFC 2818. Man könnte sagen, "es ist offensichtlich, nur die SSL / TLS-Verbindung zuerst zu etablieren", aber nicht alles ist so offensichtlich (insbesondere der Aspekt der Identitätsprüfung, erst kürzlich in RFC 6125 formalisiert). - Bruno


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 auf einem Port erfolgen, auf dem bereits kein Nicht-SSL / TLS-SMTP-Server ausgeführt wird. Aufgrund der Art der Protokolle ist es unmöglich, einen einzelnen Port für die Verarbeitung von reinem Text und verschlüsselten Verbindungen zu konfigurieren.

  • STARTTLS startet die SMTP-Transaktion und sucht Unterstützung von dem anderen Ende für TLS in der Antwort auf EHLO. Wenn der Client STARTTLS in der Liste der unterstützten Befehle sieht, sendet er STARTTLS und beginnt mit der Aushandlung der Verschlüsselung. All dies kann (und tut es normalerweise) am Standard-SMTP-Port von 25, zum Teil aus Gründen der Abwärtskompatibilität, aber auch zur opportunistischen Verschlüsselung zwischen Endpunkten, die beide unterstützen, aber nicht unbedingt benötigen.

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

Bei diesen beiden Implementierungen könnte STARTTLS als unsicher interpretiert werden, wenn der Benutzer oder Administrator davon ausgeht, dass die Verbindung verschlüsselt ist, sie jedoch nicht so konfiguriert ist, dass eine Verschlüsselung erforderlich ist. Die verwendete Verschlüsselung ist jedoch genau dieselbe wie SSL / TLS und daher nicht mehr oder weniger anfällig für einen Man-in-the-Middle-Angriff, der über diese Art von Konfigurationsfehler hinausgeht.


21
2017-07-16 19:40



Wenn die Verbindung verschlüsselt ist, sind sowohl SSL / TLS als auch STARTTLS identisch, ja. Aber das habe ich nicht gefragt. Ich meinte: Wenn ich STARTTLS verwende, wie weiß ich dann (als Benutzer), ob meine Verbindung wirklich gesichert ist? Wenn ich versuche, SSL / TLS zu verwenden, kann ich keine Verbindung herstellen, wenn der Server es nicht unterstützt, aber zumindest wird nichts als Klartext gesendet. Aber wenn STARTTLS zurück in den Klartext geht, dann werden meine Mails im Klartext gesendet, ohne dass ich weiß, dass sie im Klartext gesendet wurden (was mich glauben lässt, dass ich in Sicherheit bin, wenn ich es nicht bin). - Foo Bar
Ich weiß nicht, warum diese Antwort richtig gewählt wurde. Es ist falsch. Wie Christopher hervorhebt, ist STARTTLS weniger sicher als TLS, weil es den Kunden ein falsches Sicherheitsgefühl vermittelt. - Greg
@greg es ist nichts falsch mit dem Protokoll. Der Fehler liegt bei Clients, die nicht dem RFC folgen und den Benutzer nicht warnen, wenn die Verbindung nicht verschlüsselt ist. - longneck
@longneck so ... vielleicht ist das eine semantische Sache, aber Clients können dem TLS-Protokoll nicht "folgen" und eine E-Mail durchlaufen lassen, Punkt. Das ist ein bedeutungsvoller Unterschied. - Greg
@Bruno "Es ist nur weniger sicher, wenn der Client schlecht implementiert ist" <= Du machst nur meinen Standpunkt für mich. Wenn der Client irgendetwas tun kann, um die Verbindung unsicher zu machen und trotzdem eine funktionierende Verbindung herzustellen, ist STARTTLS weniger sicher als explizites TLS (wo das nicht möglich ist). - Greg


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

Kurz gesagt, dieses Memo empfiehlt nun Folgendes:

  • TLS Version 1.2 oder höher wird für den gesamten Datenverkehr zwischen MUAs verwendet     und Mail Submission Server, und auch zwischen MUAs und Mail Access     Server.
  • MUAs und Mail Service Provider (MSPs) (a) raten von der Verwendung von     Klartextprotokolle für Mail-Zugriff und Mail-Übermittlung und     (b) die Verwendung von Klartextprotokollen für diese Zwecke als ablehnen     so bald wie möglich.
  • Verbindungen zu Mail Submission Servern und Mail Access Servern sein     mit "implizites TLS" (wie unten definiert) bevorzugt gegen     Verbinden mit dem "Klartext" -Port und Verhandeln TLS mit der     STARTTLS Befehl oder ein ähnlicher Befehl.

(Betonung hinzugefügt)


6
2018-02-01 19:38





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

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

  • 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, TLS zu sprechen.
  • Mit STARTTLS öffnet der Client eine TCP-Verbindung zum "Klartext-Port", der dem Anwendungsprotokoll zugeordnet ist, das er verwenden möchte, und fragt dann 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 dann sagen "Okay, lass uns TLS verwenden" 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. Aber es gibt einige Feinheiten, wie STARTTLS verwendet werden muss, um es sicher zu machen, und es ist ein bisschen schwieriger für die STARTTLS-Implementierung, diese Details richtig zu machen.

Wenn der Client dagegen so konfiguriert ist, dass er TLS nur verwendet, wenn TLS verfügbar ist, und Klartext verwendet, wenn TLS nicht verfügbar ist, versucht der Client zunächst, eine Verbindung mit dem vom Protokoll verwendeten SSL-Port herzustellen, und wenn dies der Fall ist schlägt fehl, dann verbinden Sie sich mit dem Klartext-Port und versuchen Sie, STARTTLS zu verwenden, und schließlich auf Klartext zurückzufallen, wenn TLS in beiden Fällen nicht verfügbar ist. Es ist ziemlich einfach für einen Angreifer, dass die SSL-Port-Verbindung fehlschlägt (alles was man braucht, sind einige gut eingestellte TCP-RST-Pakete oder das Blockieren des SSL-Ports). Es ist ein bisschen schwieriger - aber nur ein bisschen - für einen Angreifer, die STARTTLS-Verhandlung zu besiegen und den Verkehr im Klartext zu halten. Und dann kann der Angreifer nicht nur Ihre E-Mails lesen, sondern auch Ihren Benutzernamen / Ihr Passwort für die zukünftige Verwendung erfassen.

Die einfache Antwort lautet also: Wenn Sie eine Verbindung zu einem Server herstellen, von dem Sie bereits wissen, dass er TLS unterstützt (wie es 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 Passwort und Ihre E-Mail-Adresse werden nicht kompromittiert.

Wenn Sie sich jedoch mit einem Dienst verbinden, von dem Sie nicht wissen, ob er TLS unterstützt, kann STARTTLS geringfügig besser sein.

Als STARTTLS erfunden wurde, waren "passive" Nur-Zuhören-Angriffe sehr häufig, "aktive" Angriffe, bei denen der Angreifer Verkehr injizieren würde, um die Sicherheit zu verringern, waren weniger verbreitet. In den etwa 20 Jahren seitdem sind aktive Angriffe praktikabler und häufiger geworden.

Zum Beispiel, wenn Sie versuchen, einen Laptop in einem Flughafen oder einem anderen öffentlichen Ort zu verwenden und versuchen, Ihre E-Mails über das Wlan zu lesen, die dort zur Verfügung gestellt wird, haben Sie keine Ahnung, was das Wifi-Netzwerk mit Ihrem Verkehr macht. Es ist sehr üblich, dass Wifi-Netzwerke bestimmte Arten von Datenverkehr an "Proxies" weiterleiten, die sich zwischen Ihren Client-Anwendungen und den Servern, mit denen sie sprechen möchten, befinden. Es ist trivial für diese Proxies, sowohl STARTTLS als auch "probiere einen Port dann einen anderen" zu deaktivieren, um deinen Client dazu zu bringen, auf Klartext zurückzugreifen. Ja, das passiert, und es ist nur ein Beispiel dafür, wie Ihr Traffic von einem Netzwerk ausgespäht werden kann. Und solche Angriffe sind nicht auf staatlich unterstützte Agenturen mit drei Buchstaben beschränkt, sie können von einem Teenager mit einem $ 35-Computer, der irgendwo an einem öffentlichen Ort versteckt ist, abgezogen werden.


2
2018-02-02 09:29





Ja, Sie haben die Grundlagen richtig. Und ja, STARTTLS ist definitiv weniger sicher. Es kann nicht nur ohne Benachrichtigung zum Klartext zurückkehren, sondern weil es Man-in-the-Middle-Angriffen ausgesetzt ist. 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 angeben können, dass Übertragungen nur stattfinden, nachdem ein verschlüsselter Tunnel eingerichtet wurde. Also kannst du das umgehen.

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


1
2017-07-16 19:20



Ein Server, der STARTTLS-fähig ist, wird also immer auch SSL / TLS-fähig sein, nicht wahr? Also ist es immer besser, zuerst SSL / TLS zu testen und zu sehen, ob es funktioniert? - Foo Bar
@ FooBar nein, man impliziert nicht, dass der andere verfügbar ist. Tatsächlich könnten sie mit völlig unterschiedlichen Authentifizierungsdomänen konfiguriert werden. - longneck
STARTTLS ist nicht anfällig für MitM, es sei denn, Sie validieren keine Zertifikate oder verwenden schwache. Das Zertifikat wird weiterhin wie immer angezeigt, und der Client kann verlangen, dass das TLS-Upgrade erfolgreich ist, bevor es fortgesetzt wird. Es ist erwähnenswert, dass dies genau die gleiche Situation wie bei SSL / TLS ist. - Falcon Momot
Ich weiß nicht, warum Leute dich ablehnen, das ist die richtige Antwort, STARTTLS ist weniger sicher als TLS und es gibt ein falsches Gefühl der Sicherheit. ISPs können es einfach festlegen: arstechnica.com/tech-policy/2014/11/... - Greg
Soweit das Protokoll selbst geht, ist STARTTLS weniger sicher als TLS, da es explizit Klartext-Kommunikation erlaubt, ohne den Benutzer zu warnen: serverfault.com/a/648282/207987 - Greg


Stimme mit @Greg überein. Diese Angriffe sind möglich. Die MTAs können jedoch (abhängig vom MTA) so konfiguriert werden, dass sie "obligatorische TLS" und nicht "opportunistische TLS" verwenden. Dies bedeutet, dass TLS und nur TLS für die E-Mail-Transaktionen verwendet wird (dies schließt auch STARTTLS ein). Wenn der Remote-MTA STARTTLS nicht unterstützt, wird die E-Mail zurückgewiesen.


1
2018-04-02 23:47





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

Es gibt vier Wege, TLS zu behandeln, und viele Programme erlauben Ihnen, zu wählen:

  • Kein TLS
  • TLS auf dediziertem Port (versucht nur TLS)
  • Verwenden Sie TLS, falls verfügbar (Versuche starttls, verwendet eine unverschlüsselte Verbindung, wenn es fehlschlägt)
  • Verwenden Sie immer TLS (Verwendungen starttls und schlägt fehl, wenn es nicht funktioniert)

Der Vorteil von TLS an einem dedizierten Port ist, dass Sie sicher sein können, dass kein Fallback vorhanden ist, wenn Sie ein Programm verwenden, das Sie noch nicht kennen oder das die Detaileinstellungen für die Fehlerbehandlung nicht im First-Start-Assistenten verfügbar macht.

Aber im Allgemeinen hängt die Sicherheit vom Umgang mit Sicherheitsfehlern ab. Ein Programm könnte entscheiden, zum Klartext-Port zu wechseln, wenn auch TLS am TLS-Port ausfällt. Sie müssen wissen, was es tun wird und sichere Einstellungen wählen. Und Programme sollten sichere Standardwerte verwenden.


0
2018-02-02 10:10