it-swarm-eu.dev

Bedeutet eine hergestellte HTTPS-Verbindung, dass eine Leitung wirklich sicher ist?

Ist es aus Sicht von jemandem, der eine Webanwendung anbietet, sicher, alle vertraulichen Daten über diese Leitung zu übertragen, wenn sich jemand mit TLS (https) zu unserem Dienst verbindet und die richtigen Authentifizierungsdaten übermittelt, oder kann es sein, dass immer noch abgehört wird?

Diese Frage war IT-Sicherheitsfrage der Woche.
Lesen Sie den 29. Juli 2011 Blogeintrag für weitere Details oder eigene einreichen Frage der Woche.

112
Peter Smit

Es ist wichtig zu verstehen, was SSL tut und was nicht, zumal dies eine sehr häufige Ursache für Missverständnisse ist.

  • Es verschlüsselt den Kanal
  • Es wendet die Integritätsprüfung an
  • Es bietet Authentifizierung

Die schnelle Antwort sollte also lauten: "Ja, es ist sicher genug, um sensible Daten zu übertragen." Die Dinge sind jedoch nicht so einfach.

  • Die neuesten Versionen von SSL - Version 3 oder noch besser: TLS, sogar TLS 1.2, sind definitiv besser als frühere Versionen. Z.B. SSL 2 war für MITM (Man in the Middle) relativ einfach. Also hängt es zuerst von der Protokollversion ab.
  • Sowohl die Kanalverschlüsselung als auch die Integritätsprüfung sind im Protokoll konfigurierbar, d. H. Sie können auswählen, welche Algorithmen verwendet werden sollen (Cipher Suite). Wenn Sie RSA1024/SHA512 verwenden, sind Sie natürlich viel besser dran ... SSL unterstützt jedoch sogar einen Modus der NULL-Verschlüsselung - d. H. Überhaupt keine Verschlüsselung, sondern packt die Anforderungen nur in einen Tunnel über das SSL-Protokoll. Das heißt, kein Schutz. (Dies kann sowohl auf dem Client als auch auf dem Server konfiguriert werden. Die ausgewählte Verschlüsselungssuite ist der erste Übereinstimmungssatz gemäß der konfigurierten Reihenfolge.).
  • Die Authentifizierung in SSL hat zwei Modi: Nur Serverauthentifizierung und gegenseitige Authentifizierung (Clientzertifikate). In beiden Fällen ist die Sicherheit, die durch die kryptografischen Zertifikate gewährleistet wird, definitiv stark genug, jedoch ist die Gültigkeit der tatsächlichen Authentifizierung nur so gut wie Ihre Gültigkeitsprüfungen: Haben Sie überhaupt die Mühe, das Zertifikat zu überprüfen? Stellen Sie die Gültigkeit sicher? Vertrauenskette? Wer hat es ausgestellt? Usw.
  • Dieser letzte Punkt der erneuten Authentifizierung ist im Web Anwendungen viel einfacher, wobei der Client das Serverzertifikat leicht anzeigen kann, das Schlosssymbol leicht sichtbar ist usw. Mit Web Dienste, In der Regel müssen Sie die Gültigkeit expliziter überprüfen (abhängig von der Wahl Ihrer Plattform). Beachten Sie, dass dieser Punkt so viele mobile Apps ausgelöst hat - selbst wenn der App-Entwickler daran gedacht hat, nur TLS zwischen dem Telefon und dem Server zu verwenden. Wenn die App die Zertifikate nicht explizit überprüft, ist das TLS fehlerhaft.
  • Während es einige meist theoretische Angriffe auf die Kryptographie von SSL gibt, ist sie von meinem PoV immer noch stark genug für fast alle Zwecke und wird es noch lange sein.
  • Was wird eigentlich mit den Daten am anderen Ende gemacht? Z.B. Wenn es sich um überempfindliche oder sogar Kreditkartendaten handelt, möchten Sie dies nicht im Browser-Cache, im Verlauf usw.
  • Cookies (und damit die Authentifizierung) können zwischen einem sicheren SSL-Kanal und einem nicht sicheren HTTP-Kanal gemeinsam genutzt werden - sofern dies nicht ausdrücklich mit dem Attribut "sicher" gekennzeichnet ist.

Also, kürzere Antwort? Ja, SSL kann sicher genug sein, aber (wie bei den meisten Dingen) hängt es davon ab, wie Sie es verwenden. :) :)

94
AviD

Hier gibt es einige Probleme, von denen das Hauptproblem die Authentifizierung ist. Beide Ziele müssen sicher sein, dass sie mit der richtigen Person oder Institution sprechen, um Man-in-the-Middle-Angriffe zu verhindern. Auf Ihrer Seite ist es wichtig, dass Sie ein SSL-Zertifikat verwenden, dem der Browser des Benutzers vertraut. Auf diese Weise kann der Browser des Benutzers sicher sein, dass er wirklich mit der richtigen Site spricht. Sobald die Verbindung hergestellt ist, können Sie sicher sein, dass Sie die ganze Zeit mit diesem Benutzer sprechen und die Verbindung verschlüsselt ist, d. H. Sicher gegen Abhören.

Die Authentifizierung in die andere Richtung (d. H. Sicherstellen, dass Sie mit dem realen Benutzer sprechen) erfolgt normalerweise außerhalb des SSL-Protokolls auf Anwendungsebene, z. B. durch Benutzername/Kennwort, openID oder eine andere Form von Anmeldeinformationen.

Als letzte Anmerkung sollte erwähnt werden, dass Client und Server während der SSL-Verbindung Handshake eine Cipher Suite vereinbaren und der Client so tun könnte, als würde er nur "Null-Verschlüsselung" durchführen, dh keine der Daten verschlüsseln . Wenn Ihr Server dieser Option zustimmt, verwendet die Verbindung SSL, die Daten sind jedoch immer noch nicht verschlüsselt. Dies ist in der Praxis kein Problem, da Serverimplementierungen normalerweise keine Nullverschlüsselung als Option anbieten.

23
Tronic

Zusätzlich zu den von AviD aufgeführten Informationen ist SSL nur so sicher wie die DNS-Infrastruktur, die Sie zu diesem Server geleitet hat, und alle Unternehmens-Proxys im Kommunikationspfad.

Wenn die DNS-Infrastruktur gehackt wird (Cache-Vergiftung usw.), kann der Angreifer Ihren Benutzer vielen Angriffen aussetzen.

Wenn der Client Software wie Fiddler oder einen Unternehmens-Proxy durchläuft, kann diese Software außerdem Ihre SSL-Konversation vereinfachen.

Um dies zu vermeiden, sehen Sie sich den "Aussteller" des SSL-Zertifikats an. Wenn die SSL-Verbindung über einen Proxy erfolgt, ist der Aussteller der des Proxys. Wenn Sie eine direkte Verbindung herstellen, wird die entsprechende öffentlich vertrauenswürdige Zertifizierungsstelle angezeigt.

[Weitere Informationen]

Ein Unternehmens-HTTPS-Proxy verwaltet die Verbindung zwischen dem Webbrowser und dem Proxy (dessen IP-Adresse in Ihren Webserver-Protokollen angezeigt wird). In diesem Fall wird der Webinhalt (auch das HTTPS-Kennwort) entschlüsselt und später am Unternehmens-Proxy erneut verschlüsselt und Ihrem Server angezeigt.

Abhängig davon, wer den Proxy verwaltet und wie seine Protokolle verwendet werden, kann dies aus Ihrer Sicht akzeptabel oder eine schlechte Sache sein.

Weitere Informationen zum Abfangen von SSL finden Sie unter Link :

Wenn der SSL-Proxy eine SSL-Verbindung abfängt, zeigt er dem Client-Browser ein emuliertes Serverzertifikat an. Der Client-Browser gibt ein Sicherheits-Popup an den Endbenutzer aus, da der Browser dem vom ProxySG verwendeten Aussteller nicht vertraut. Dieses Popup wird nicht angezeigt, wenn das vom SSL-Proxy verwendete Ausstellerzertifikat als vertrauenswürdiges Stammverzeichnis in den Zertifikatspeicher des Clientbrowsers importiert wird.

Der ProxySG stellt alle konfigurierten Zertifikate über seine Verwaltungskonsole zum Download bereit. Sie können Endbenutzer bitten, das Ausstellerzertifikat über Internet Explorer oder Firefox herunterzuladen und als vertrauenswürdige Zertifizierungsstelle in einem Browser ihrer Wahl zu installieren. Dadurch wird das Zertifikat-Popup für emulierte Zertifikate entfernt ...

Einige Unternehmen umgehen das oben erwähnte Problem mit dem Zertifikat-Popup, indem sie die Stammzertifikate (des Proxys) über ein Gruppenrichtlinienobjekt auf jeder Arbeitsstation bereitstellen. Dies betrifft jedoch nur Software, die den Microsoft Certificate Store verwendet. Software wie Firefox und Chrome muss anders aktualisiert werden.

20

Da SSL auf Zertifizierungsstellen (Certificate-Authorities, CA) basiert und grundsätzlich jede Organisation zu einer Zertifizierungsstelle werden kann, sind Man-in-the-Middle-Angriffe mit gefälschten, jedoch von der CA signierten Zertifikaten immer möglich. Obwohl SSL immer noch eine enorme Verbesserung gegenüber der Nichtverschlüsselung darstellt, wird seine Sicherheit aufgrund des defekten CA-Systems überbewertet. In dieser Hinsicht wären selbstsignierte Zertifikate genauso sicher wie jedes CA-signierte Zertifikat, doch Browser markieren diese als verdächtig.

11
Jörn Zaefferer

SSL ist sehr sicher, obwohl jemand das Sitzungscookie eines anderen stehlen kann, wenn Sie eine Seite über eine unverschlüsselte Zeile ausführen. Wenn Sie könnten, würde ich die Site komplett SSL machen. Oder lassen Sie das Cookie möglicherweise nur für verschlüsselte Verbindungen senden und haben Sie ungesicherte öffentliche Seiten, die nicht spezifisch für diesen Benutzer sind.

10
James T

Es besteht weiterhin die Möglichkeit eines Man-in-the-Middle-Angriffs. In Ihrem Fall würde der Benutzer eine Verbindung zu einem Dritten herstellen, der behauptet, Ihre Site zu sein, und dann die Anfrage weiterleiten. Natürlich sollte ein versierter Benutzer das Fehlen einer SSL-Verbindung oder des falschen Zertifikats bemerken, aber die meisten Benutzer sind nicht so eingeschaltet und werden von einem Vorhängeschloss-Favicon betrogen.

Dies ist kein wirkliches Problem mit SSL selbst, nur etwas, das Sie beachten sollten. Sie können davon ausgehen, dass niemand die SSL-Verbindung zwischen Ihrer Site und der Quelle der Verbindung abhören kann. Sie können jedoch nicht sicher sein, dass die Quelle der Verbindung wirklich der Benutzer ist.

9
Magnus

Da SSL die Übertragung krypiert, können keine Daten abgehört werden (da das Zertifikat vertrauenswürdig ist).

Obwohl das Problem darin besteht, wo (und wie oft) Sie SSL in Ihrer Webanwendung verwenden: Beispielsweise benötigen Sie eine SSL-Verbindung nur, um Ihren Benutzer zu authentifizieren (damit sie verschlüsselte Benutzer/Pass-Paare an Ihren Server senden können). Wenn Sie dann ein Cookie zurücksenden, sollten Sie sich darüber im Klaren sein, dass es leicht abgefangen werden kann (z. B. wenn sich Ihr Benutzer in einer ungeschützten drahtlosen Verbindung befindet).

Das jüngste FireSheep-Drama handelt davon.

9
gbr

Nein. Verkehrsanalyse kann noch viel erzählen.

Bei der Verkehrsanalyse werden Nachrichten abgefangen und untersucht, um Informationen aus Kommunikationsmustern abzuleiten. Dies kann auch dann durchgeführt werden, wenn die Nachrichten verschlüsselt und nicht entschlüsselt werden können. Im Allgemeinen kann aus dem Verkehr mehr abgeleitet werden, je mehr Nachrichten beobachtet oder sogar abgefangen und gespeichert werden.


TLS wird normalerweise zur Wahrung der Vertraulichkeit eingesetzt. Ein Angreifer sollte kein hohes Maß an Vertrauen in die Inhalte der Kommunikation erreichen.

Vorausgesetzt,

  1. ein Angreifer kennt Ihr Protokoll.
  2. ein Angreifer weiß, wer mit wem kommuniziert
  3. der Angreifer kann keine Nachrichten entschlüsseln.
  4. sie verdecken Ihren realen Verkehr nicht in viel Unsinnverkehr (Spreu)

Ein Angreifer kann wahrscheinlich erkennen, wann Sie wach sind und wann Sie schlafen, unabhängig vom Protokoll, und kann je nach Art des verwendeten Protokolls möglicherweise viel mehr sagen.


Wenn Ihr Protokoll sehr einfach ist:

  1. Sie senden eine Nachricht "Feuer die Atomwaffen auf ...", wenn Sie Atomwaffen abfeuern möchten
  2. Sie senden keine Nachricht, wenn Sie keine Atomwaffen abfeuern möchten.

Ein Lauscher, der Ihre Daten nicht entschlüsseln kann, kann durch das bloße Vorhandensein einer Nachricht feststellen, dass Sie Atomwaffen abfeuern möchten, aber möglicherweise nicht auf wen.


Wenn Ihr Protokoll komplexer ist:

  1. Sie fragen nach einem Buch.
  2. Ich sende dir den Inhalt.

Ein Angreifer kann möglicherweise nicht erkennen, wer gerade liest "Krieg und Frieden" gegen "Atlas Shrugged" , kann jedoch anhand der Nachrichtengröße unterscheiden, ob er eine der ersteren gegen Kafkas 55 liest Seitenroman "Die Metamorphose".

7
Mike Samuel

SSL führt zwei grundlegende Aufgaben aus: Authentifizierung und Verschlüsselung.

Die Authentifizierung erfolgt mithilfe von Zertifizierungsstellen. Browser werden mit einer Liste von SSL-Zertifikaten für die Signaturschlüssel der Zertifizierungsstellen geliefert. Zertifizierungsstellen signieren Zertifikate, die den öffentlichen Schlüssel einer Entität beschreiben. Wenn ich beispielsweise Google.com besitze, würde ich dies Verisign beweisen und sie würden mein Zertifikat für einen bestimmten Zeitraum unterschreiben. Probleme mit einer Zertifizierungsstelle, die ein Zertifikat signiert, das sie nicht signieren sollten. Dies kann vorkommen, wenn jemand vorgibt, eine andere Domain zu besitzen, ein zu breites Wildcard-Zertifikat erwirbt oder einfach XKCDs die CA dazu auffordert, etwas Schändliches (Regierungen) herauszugeben , vielleicht?). Wir haben Fälle von all dem gesehen, aber es ist ziemlich selten.

Wenn ein Zertifikat für eine Site ordnungsgemäß signiert ist und kein gefälschtes Zertifikat in Ihrer Vertrauenskette vorhanden ist, können Sie (zu Diskussionszwecken) beim Herstellen einer Verbindung zu einer Site sicher sein, dass das Zertifikat übereinstimmt. Unter normalen Umständen wird diese Verbindung verschlüsselt. Das verhindert, dass jemand Ihre Daten liest.

SSL-Zertifikate sind sehr komplex und es gibt eine Reihe von Angriffen gegen SSL-Implementierungen. Was SSL effektiv tun kann, ist zu verhindern, dass ich Ihren Datenverkehr bei den lokalen Starbucks beobachte, wenn Sie Ihre E-Mails auf GMail abrufen. Was es nicht tun kann, ist zu verhindern, dass ich einen MITM-Angriff verwende, bei dem ich alles ohne SSL an Sie weitergebe und Ihr Client nicht so eingerichtet ist, dass Sie die Tatsache stören, dass nie eine verschlüsselte Sitzung gestartet wurde.

6
Jeff Ferland

Ohne die verschiedenen Antworten anderer zu anderen potenziellen Problemen zu berücksichtigen, sollte es sicher sein, dass Sie SSL 3.0 und eine starke Verschlüsselung verwenden.

Die Verwendung älterer SSL-Protokolle (2.0) oder eines schwachen Verschlüsselungsschlüssels kann zu Sicherheitslücken führen.

4
Doozer Blake

SSL erhöht im Allgemeinen die Sicherheit, indem es Folgendes bietet:

  1. Serverauthentifizierung (der Benutzer weiß, dass er mit der "richtigen" Site spricht)
  2. Datenintegrität (Benutzer und Server wissen, dass der Datenverkehr unterwegs nicht geändert wird)
  3. (optional, aber normalerweise) Datenschutz (der Benutzer und der Server wissen, dass der Datenverkehr unterwegs nicht abgefangen wird)
  4. (optional, aber selten) Client-Authentifizierung, wenn der Client auch über ein Zertifikat verfügt

Grundsätzlich gibt es nur zwei Arten von SSL-Zertifikaten: das Serverzertifikat (das immer beteiligt ist) und ein Clientzertifikat (das optional ist).

Dies ist nur eine Skizze, und es gibt viele Wenn und Aber. In dem typischsten Szenario, browserbasiertem SSL, kann das Schema in vielen Fällen beschädigt werden, ohne die Kryptographie oder das Protokoll zu beschädigen, sondern einfach, indem der Benutzer das Falsche tut (d. H. Die Browser-Warnungen ignoriert und trotzdem eine Verbindung herstellt). Phishing-Angriffe können auch funktionieren, indem der Benutzer an eine gefälschte SSL-geschützte Site gesendet wird, die in jeder Hinsicht der echten ähnelt, mit Ausnahme der URL.

Trotzdem sind SSL und sein Cousin TLS immer noch sehr nützlich, da sie zumindest eine sichere Kommunikation ermöglichen, wenn auch alles andere als narrensicher.

4
frankodwyer

@Vladimir hat Recht, dass http://en.wikipedia.org/wiki/Forward_secrecy wünschenswert ist, aber die Details falsch sind. Der Server hat diese Chiffresuite unter den vom Browser angebotenen ausgewählt. "Mit RC4_128 mit SHA1 zur Nachrichtenauthentifizierung verschlüsselt" verwendet RC4 128-Bit-Verschlüsselung und HMAC-SHA-1-Integritätsprüfung. (Ciphersuite-Namen in SSL/TLS sagen bis vor kurzem SHA, aber sie bedeuten SHA-1 und tatsächlich HMAC-SHA-1.) "ECDHE_ECDSA als Schlüsselaustauschmechanismus" gilt nicht für einzelne Nachrichten Dies ist ein Teil (der größte Teil) des Handshakes, der zu Beginn der Sitzung einmal auftritt: ECDHE verwendet die Variante Elliptic Curve von Diffie-Hellman im Ephemeral-Modus (plus einige zusätzliche Schritte, die hier nicht wichtig sind), um die Sitzung zu erstellen Schlüssel , die für Verschlüsselung und HMAC verwendet werden, und der ECDHE-Schlüsselaustausch (nur) werden von der Elliptic Curve-Variante des Digital Signature-Algorithmus signiert. (Mit DH können Sie niemals etwas direkt verschlüsseln oder ECDH, sie machen nur Schlüssel- oder andere kleine geheime Vereinbarungen.)

2

Wenn Sie kein SSL verwenden, kann die gesamte Kommunikation leicht abgefangen werden. Das einzige, was Sie tun müssen, ist, den Paket-Sniffer (d. H. Wireshark) zu starten.
SSL verhindert, dass alle Pakete verschlüsselt werden, sodass Sie nicht wissen können, was Sie senden. Grundsätzlich wird es zum Schutz von Passwörtern und privaten Inhalten vor dem Abfangen verwendet. Sie möchten natürlich nicht, dass jemand anderes Ihre privaten E-Mails liest, oder?
Bei der Google-Suche haben sie es einfach getan, um zu verbergen, wonach die Leute fragen. Dies liegt daran, dass einige Regierungen einfach zu neugierig sind.

Wie erhöht SSL die Sicherheit? Es geht nicht von alleine. Was tut, ist eine Kombination aus Verschlüsselung (SSL-Schlüssel) und PKI (Public Key Infrastructure) - hauptsächlich Zertifikate. OK, die Frage war wie. Auf der einen Seite wird Ihr Kommunikationskanal gesichert (siehe oben), auf der anderen Seite wird sichergestellt, dass Sie mit einem legitimen Unternehmen sprechen - authentifiziert den Server. Der Kanal ist also sicher und vertrauenswürdig.

Es gibt einige SSL-Zertifikate, da es einige PKI-Dienste gibt. Grundsätzlich erfordern unterschiedliche Dienste unterschiedliche Arten von SSL-Zertifikaten. Es gibt also Zertifikate für die Codesignatur, die E-Mail-Verschlüsselung und die Signatur, die sich auf die Serverauthentifizierung usw. beziehen.

2
Paweł Dyda

Wenn sich jemand mit SSL (https) mit unserem Dienst verbindet und die korrekten Authentifizierungsdaten übermittelt, ist es sicher, alle vertraulichen Daten über diese Leitung zu übertragen, oder kann es sein, dass immer noch Abhören erfolgt?

Das schwache Glied in dieser Kette ist mit ziemlicher Sicherheit nicht SSL, sondern der Benutzer, der im Allgemeinen dazu verleitet werden kann, eine Verbindung zu einer gefälschten Zwischenwebsite herzustellen, entweder über Web-Spoofing/Hyperlink-Spoofing oder indem ihm ein ungültiges Zertifikat vorgelegt wird und die Browser-Warnung verworfen wird und mit fortgefahren wird trotzdem verbinden.

Das von Ihnen beschriebene System ist jedoch ohnehin eine bewährte Methode. Sie können nicht viel anderes tun (abgesehen davon, dass Sie Ihre Benutzer dazu erziehen, SSL-Warnungen ernst zu nehmen, wenn Sie können).

2
frankodwyer

Kurze Antwort ist nein. Längere Antwort: Eine Sammlung der obigen Antworten plus: Wenn wir die Authentifizierung lösen, also Man-in-the-Middle, könnte bei einer herkömmlichen SSL-Verbindung jemand, der den Datenverkehr auflistet, ihn später noch entschlüsseln, wenn er einen geheimen Serverschlüssel erhält (denken Sie of NSA und National Security Letters). Im TLS-Protokoll gibt es eine Option zur Verwendung des Diffie-Helman-Protokolls, um die vertrauliche Verknüpfung sicherzustellen. Siehe das folgende Bild, wenn ich mit Chrome auf gmail.com zugreife. connection security

Sehen Sie sich den Text RC4_128 mit SHA1 für die Nachrichtenauthentifizierung ECDHE_ECDSA an. Dies lautet:

  1. Der Server bot den SSL-Kanal RC4_128b mit SHA Digest) an
  2. Innerhalb dieses Tunnels wird jede Nachricht mit Ekliptikkurven verschlüsselt, wobei der Schlüssel mithilfe der Diffie-Helman-Funktion abgeleitet und mithilfe des Digital Signature-Algorithmus mit der Verschlüsselung für Ekliptikkurven signiert wird

Mit anderen Worten, selbst wenn jemand einen privaten Schlüssel des SSL-Servers hat, wurden die Nachrichten mit temporären Schlüsseln verschlüsselt, die kurz nach der Verwendung aus dem Speicher verworfen werden. Viel Glück NSA!

2

Ist es sicher für den Benutzer oder ist es sicher für Sie? Nehmen Sie einen Man-in-the-Middle-Angriff an. Der Angreifer schafft es, den Datenverkehr des Benutzers zu erfassen, gibt vor, Sie für den Benutzer zu sein, und gibt vor, der Benutzer für Sie zu sein. Diese Art von Angriff schlägt normalerweise fehl, da das dem Benutzer erteilte Zertifikat nicht richtig ist. Beispielsweise gibt der Angreifer dem Benutzer ein selbstsigniertes Zertifikat für Ihre Website. Wenn der Benutzer jedoch dumm handelt, akzeptiert er möglicherweise dieses selbstsignierte Zertifikat. Jetzt kann der Angreifer den gesamten Datenverkehr zwischen dem Benutzer und Ihnen lesen und ändern. Soweit ich weiß, können Sie dies nicht erkennen.

Wenn das Schnüffeln und Ändern des Datenverkehrs dem Benutzer weh tut, ist dies wirklich seine eigene Schuld und sein eigenes Problem. Und Sie können es sowieso nicht vollständig verhindern, da das MITM Sie vollständig ausschalten und einfach mit dem Benutzer sprechen kann, der vorgibt, Sie zu sein. Wenn Sie jedoch durch Schnüffeln und Ändern des Datenverkehrs verletzt werden, müssen Sie darauf vertrauen, dass der Benutzer nicht dumm ist, oder den Benutzer besser authentifizieren (der Benutzer würde ein Zertifikat benötigen, und Sie können dies auf eine Weise überprüfen, die das MITM nicht kann Fälschung).

2
gnasher729

Selbst die modernsten Versionen von HTTPS, die TLS verwenden, können leicht von einem MitM (z. B. einem Juniper-Gerät , das für diesen Zweck konfiguriert wurde) abgefangen werden, wenn der Client der Zertifizierungsstelle vertraut. In diesem speziellen Fall ist es nicht sicher.

1
user3260912

Ich denke, die Leute hier verstehen die Frage nicht:

Wenn Sie eine unsichere Leitung haben und über diese Leitung eine erfolgreiche SSH/SSL-Verbindung herstellen, fragt er nun, ob es sicher ist, anzunehmen, dass die Leitung "sicher" ist und dass unverschlüsselte Daten mit der verschlüsselten Verbindung ENTLANG weitergegeben werden können ( z. B. nicht sichtbar innerhalb der verschlüsselten SSL/SSH-Verbindung).

Ich würde nein sagen. In diesem Fall könnte es einen passiven Lauscher geben, der verschlüsselte Daten einfach ignoriert und unverschlüsselte Daten speichert.

ABER Sie können sicher sein, dass es keinen aktiven Lauscher (MITM) gibt, was bedeutet, dass Sie sicher eine nicht authentifizierte SSL/SSH-Verbindung mit derselben Quelle/demselben Ziel wie die authentifizierte Leitung herstellen können. Dies vorausgesetzt, es gibt keinen selektiven Lauscher, den MITM für bestimmte Konnektoren benötigt, ABER der Lauscher kann jedoch nicht wissen, ob Sie die Verbindung authentifizieren oder nicht, sodass er nicht weiß, welche Verbindung zu MITM der Erkennung entgeht. Der MITMer würde, wenn er MITM, MITM alle Verbindungen und hoffen, dass die Leute einfach durch alle Authentifizierungsdialoge klicken.

Also: Wenn Sie eine authentifizierte Verbindung zu einem SSL-Dienst von beispielsweise 123.123.123.123 bis 24.24.24.24 herstellen, können Sie auch sicher einen SSH-Client von 123.123.123.123 bis 24.24.24.24 verbinden, ohne den SSH-Fingerabdruck gegenseitig zu authentifizieren, vorausgesetzt, Sie können alles dahinter vertrauen NAT Router oder Firewall der anderen Seite).

Aber selbst wenn dies im Allgemeinen sicher ist, besteht IS ein geringes Risiko, dass ein Lauscher einfach zufällige MITM-Verbindungen hat und hofft, nicht erkannt zu werden. Da Sie also bereits eine authentifizierte Verbindung zur Ziel-IP haben, warum Verwenden Sie diese authentifizierte Verbindung nicht, um den SSH-Fingerabdruck gegenseitig zu überprüfen. Es ist ganz einfach, den richtigen SSH-Fingerabdruck auf einer SSL-gesicherten Website zu veröffentlichen!

1