Ist der Besuch von HTTPS-Websites an einem öffentlichen Hotspot sicher?

waiwai933

2011-01-09 16:51:24 UTC

view on stackexchange narkive permalink

HTTPS ist über öffentliche Hotspots sicher. Während der Einrichtung von TLS, der von HTTPS verwendeten Sicherheitsschicht, werden nur ein öffentlicher Schlüssel und verschlüsselte Nachrichten übertragen (und auch diese werden von Stammzertifikaten signiert). Der Client verwendet den öffentlichen Schlüssel, um ein Hauptgeheimnis zu verschlüsseln, das der Server dann mit seinem privaten Schlüssel entschlüsselt. Alle Daten werden mit einer Funktion verschlüsselt, die das von jeder Seite generierte Hauptgeheimnis und die Pseudozufallszahlen verwendet.

Somit sind

die Daten sicher, da sie von signiert sind Die Hauptgeheimnis- und Pseudozufallszahlen
Die Hauptgeheimnis- und Pseudozufallszahlen sind sicher, da beim TLS-Handshake die Verschlüsselung mit öffentlich-privaten Schlüsseln verwendet wird.
der öffentlich-private Schlüssel Die Verschlüsselung ist sicher, weil:
- die privaten Schlüssel geheim gehalten werden
- die Verschlüsselung mit öffentlich-privaten Schlüsseln ohne den privaten Schlüssel nutzlos ist
- die öffentlichen Schlüssel bekannt sind um legitim zu sein, da sie von Stammzertifikaten signiert sind, die entweder
- mit Ihrem Computer geliefert wurden
- oder speziell von Ihnen autorisiert wurden (beachten Sie die Browser-Warnungen!)

Somit sind Ihre HTTPS-Verbindungen und -Daten sicher, solange:

Sie den Zertifikaten vertrauen, die mit Ihrem Computer geliefert werden,
Sie achten darauf, nur Zertifikate zu autorisieren, denen Sie vertrauen.

Oh, ich habe vergessen, dass wir asymmetrische Verschlüsselungssysteme haben.

3. Sie stellen sicher, dass alle Ihre Daten tatsächlich über HTTPS übertragen werden (einige Websites sind teilweise verschlüsselt und teilweise nicht).

Meine örtlichen Schwimmbäder (Hillingdon, UK) geben ihre eigenen Zertifikate zurück, sodass Sie tatsächlich sehen können, was Sie senden, auch wenn das https angezeigt wird.99,9% der Benutzer würden dies nicht bemerken.

Frage: Können Sie klarstellen, wie eine Antwort vom HTTPS-Server so verschlüsselt werden kann, dass jemand, der in der Mitte zuhört, sie nicht interpretieren kann?Der einzige Schlüssel, über den der Client verfügt, ist der öffentliche Schlüssel, der auch dem Listener / Hacker zur Verfügung steht.

@JoshG Der Client verfügt auch über einen privaten Schlüssel, den nur er kennt.Dies ist die Essenz der asymmetrischen Verschlüsselung (öffentliches / privates Schlüsselpaar).Um eine Antwort vom Server zu entschlüsseln, benötigt ein Mann in der Mitte den privaten Schlüssel des Clients.

AviD

2011-01-11 12:37:30 UTC

view on stackexchange narkive permalink

Kurze Antwort: es kommt darauf an.

SSL / TLS selbst ist über eine öffentliche WLAN-Verbindung nicht anfälliger als über "normales" Internet. Es wurde für den Einsatz in offenen Kanälen entwickelt.

Es sind jedoch noch einige andere Aspekte zu berücksichtigen:

Oft navigieren Benutzer nicht direkt zur HTTPS-Site, sondern starten an der HTTP-Site und leiten von dort weiter . Navigieren Sie beispielsweise zu http://example.org/ und klicken Sie auf den Link E-Mail , der Sie zu https://mail.example.org/ weiterleitet. . Da die ursprüngliche HTTP-Seite nicht verschlüsselt ist, kann dieser böswillige Benutzer Ihren Datenverkehr ändern, wodurch der Link E-Mail NICHT zu HTTPS umgeleitet wird, sondern möglicherweise woanders. Wenn Sie beispielsweise auf der Homepage von example.org auf den Link E-Mail klicken, werden Sie feststellen, dass Sie zu http://mail.exxxample.org/ gelangen? (als Beispiel). Sie könnten, jemand anderes möglicherweise nicht.
Wenn der Benutzer Ihre Verbindung entführt, aber anstelle von example.org sein eigenes gefälschtes SSL-Zertifikat bereitstellt, wird Ihr Browser zeige einen Fehler, dass das Zertifikat ungültig ist. Die meisten Benutzer klicken jedoch einfach darauf, sodass der Angreifer über SSL mit MITM auf Ihre sichere Site zugreifen kann.
Ein weiterer zu berücksichtigender Aspekt: Gehen Sie nicht davon aus, dass der öffentliche Hotspot sicher konfiguriert ist. Wie diese Frage zeigt, sind pwned Router allzu häufig und können weitaus mehr Schaden verursachen, der für Ihr SSL irrelevant ist.

Alle Google-Websites sind HSTS-ed. Besser `example.org` verwenden.

@Pacerier yeah, * now *, war früher nicht :-) Auch ihre Zertifikate sind meistens gepinnt (bezüglich meines 2. Punktes), also ... yeah. Vielen Dank!

Alex Howell

2011-01-09 17:11:23 UTC

view on stackexchange narkive permalink

Eine Sitzung, die vollständig über HTTPS stattfindet, ist ziemlich sicher, da alle Anforderungen des Browsers und die vom Server übertragenen Seiten verschlüsselt sind.

Beim Zugriff über HTTPS werden jedoch nur viele Websites ausgeführt Führen Sie den Authentifizierungsschritt über HTTPS durch, und kehren Sie dann für den Rest der Sitzung zu HTTP zurück. Ihr Passwort selbst ist also sicher, aber die Sitzungs-ID, mit der der Server Sie für diese Sitzung identifiziert, wird von Ihrem Browser im Klartext übertragen. Dies reduziert die Belastung des Webservers (da die Verschlüsselung / Entschlüsselung CPU-intensiv ist), macht die Site jedoch viel weniger sicher. Google Mail ist sicher, da es HTTPS für die gesamte Sitzung verwendet, Facebook und viele andere Websites jedoch nicht.

Auf diese Weise können Tools wie Firesheep die Konten von Benutzern entführen, wenn Ein Angreifer teilt ein unverschlüsseltes drahtloses Netzwerk.

Sie können sich vor diesem Angriff schützen, indem Sie entweder ein VPN zum Verschlüsseln aller Sitzungsdaten verwenden oder nur Netzwerke verwenden, die eine starke Verschlüsselung pro Benutzer aufweisen, z. B. WPA -PSK (WEP verwendet für jeden Benutzer den gleichen Schlüssel und bietet daher keinen Schutz vor diesem Angriff.)

Soweit ich weiß, ist [WPA-PSK keine wirksame Verteidigung gegen Firesheep-ähnliche Angriffe] (http://www.kennynet.co.uk/2010/11/26/ubuntu-firesheep-aircrack-and-wpa/ ). Ich verstehe, dass [aircrack-ng die WPA-PSK-Verschlüsselung entschlüsseln kann] (http://www.aircrack-ng.org/doku.php?id=airdecap-ng), wenn Sie den ersten Handshake erfassen, der einfach zu erfassen ist machen. WPA-PSK ist [nicht sicher gegen diese Art von Angriffen] (http://wifinetnews.com/archives/2003/11/weakness_in_passphrase_choice_in_wpa_interface.html) und [bietet ein falsches Sicherheitsgefühl] (http: //wiki.wireshark). org / HowToDecrypt802.11).

Diese Antwort übersieht auch das Risiko von MITM-Angriffen (aktive Angriffe). Firesheep führt derzeit keine MITM-Angriffe durch, dies könnte jedoch der Fall sein, und es können Risiken bestehen, selbst wenn die Site ausschließlich HTTPS verwendet. (z. B. wenn es seine Cookies nicht mit dem SECURE-Flag markiert.)

@D.W., Danke - deshalb habe ich vorgeschlagen, die ursprüngliche Frage von superuser.com nach hier zu verschieben - diese Frage kam von dort, nicht von einem "Sicherheitsmann". Übrigens, wenn Sie schlechte Antworten sehen, insbesondere Antworten, die ausdrücklich FALSCH sind, sollten Sie sie ablehnen. Das hilft, die richtigen Antworten nach oben zu bringen und die falschen zu versenken.

Wahrscheinlich erwähnenswert, dass "Verschlüsselung / Entschlüsselung" nicht mehr CPU-intensiv ist. Es ist wichtig, den Mythos nicht aufrechtzuerhalten, dass die CPU-Auslastung eine Überlegung wert ist, wenn Sie über die Verwendung von HTTPS auf allen Teilen Ihrer Website nachdenken. siehe: https://istlsfastyet.com/

PulpSpy

2011-01-13 05:06:37 UTC

view on stackexchange narkive permalink

Da die Antworten überall zu sein scheinen (ja, nein, könnte sein, sollte sein), lassen Sie mich zuerst die Antwort von @ waiwai933 wiederholen:

Um genau zu sein, haben Sie gefragt : "Wenn dieser böswillige Benutzer alle meine eingehenden und ausgehenden Pakete beschnüffelt hat. Kann er dieselben Schlüssel berechnen und auch meinen verschlüsselten Datenverkehr lesen oder sogar verschlüsselte Nachrichten in meinem Namen an den Server senden?" Die Antwort ist nein und nein. Mit einer Fußnote.

Der Grund, warum er nicht dieselben Schlüssel berechnen kann, scheint paradox und war tatsächlich ein großer Durchbruch in der Kryptographie, als sie erstmals von Diffie und Hellman veröffentlicht wurde. TLS verwendet ein Schlüsselaustauschprotokoll wie Diffie-Hellman, das jedoch ausgefeilter ist, um vor Man-in-the-Middle-Angriffen zu schützen. Mit dem Protokoll können zwei Personen, die noch nie Informationen ausgetauscht haben, einen geheimen Schlüssel berechnen, den niemand sehen kann, der alle Nachrichten sieht.

Sobald Sie einen gemeinsamen geheimen Schlüssel haben, können Sie ihn zum Verschlüsseln Ihres Datenverkehrs verwenden. Da der böswillige Benutzer den Schlüssel nicht kennt, kann er keinen Datenverkehr verschlüsseln, der so aussieht, als ob er von Ihnen stammt.

Nun diese Fußnoten.

Wir gehen davon aus, dass das SSL / TLS-Protokoll korrekt ist. Bei den meisten kryptografischen Protokollen werden von Zeit zu Zeit Fehler gefunden und behoben. SSL / TLS hatte kürzlich einen Fehler (in einigen Antworten als Grund für die Ungewissheit genannt), der jedoch vorübergehend behoben und jetzt behoben wurde (RFC 5746) und der Fix ist in verschiedene Phasen der Bereitstellung. (In Ihrem Szenario hat der Fehler einem böswilligen Benutzer ermöglicht, Pakete in Ihrem Namen zu senden, aber Ihren Datenverkehr nicht zu lesen.) Es ist immer möglich, dass der Angreifer aufgrund eines unveröffentlichten Protokollfehlers weiß, wie TLS / SSL beschädigt wird.
Ein offensichtlicher Punkt, der jedoch wiederholt werden sollte: Der böswillige Benutzer kann Ihre Anfrage sehen und seine eigene Antwort mit seinem eigenen Zertifikat senden. Überprüfen Sie daher das Zertifikat.
Vielleicht ein weiterer offensichtlicher Punkt: Sie können nur sicher sein, dass SSL / TLS für zukünftige Seiten verwendet wird, wenn die aktuelle Seite HTTPS ist. Wenn Sie sich beispielsweise auf einer HTTP-Seite befinden, auf der Sie sich anmelden möchten, und aus früheren Erfahrungen wissen, dass Sie durch Klicken auf die Schaltfläche "Anmelden" zu einer HTTPS-Verbindung weitergeleitet werden, kann diese Funktion von einem aktiven böswilligen Benutzer entfernt werden in Ihrem Netzwerk. Melden Sie sich also nur bei Seiten an, die bereits HTTPS sind (es sei denn, Sie wissen, wie Sie feststellen können, ob die Anmeldeseite geändert wurde).

RedGrittyBrick

2011-01-09 16:51:55 UTC

view on stackexchange narkive permalink

HTTPS ist ziemlich widerstandsfähig gegen Entschlüsselung durch Paket-Sniffing. Die Seite der Serverauthentifizierung hängt jedoch von einer etwas schwachen Methode zum Verteilen von CA-Zertifikaten ab, und die CAs tun nicht viel, um Identitäten zu überprüfen. Vor einigen Jahren wurde ein Microsoft-Zertifikat an einen Betrüger ausgestellt. Siehe Bruce Schneiers Artikel zu diesem Thema - in der Praxis haben wir für allgemeine öffentliche Websites nichts Besseres.

Ungültige Zertifikate sind ein Problem bei allen Verbindungstypen - nicht nur bei einem öffentlichen WI-FI-Hotspot.

Richard hat recht, es gibt nichts Besonderes an öffentlichen WLAN-Hotspots in Bezug auf Zertifikate. Ich fand es erwähnenswert, da es auch dort gilt. Ein betrügerischer Hotspot-Betreiber könnte Sie mithilfe eines betrügerischen Zertifikats auf seinen eigenen Webserver umleiten.

Ungültige Zertifikate und MITM sind jedoch ein viel größeres Risiko für das öffentliche WLAN

Rory Alsop

2011-01-09 20:25:06 UTC

view on stackexchange narkive permalink

In der Praxis haben sowohl SSL als auch TLS Probleme, aber es handelt sich um den Angriffstyp Man In the Middle. Ein Beispiel für ein TLS MITM-Neuverhandlungsproblem finden Sie unter hier

. Natürlich muss sich der Angreifer bei diesem Angriff in der Mitte des Kommunikationspfads befinden, was die Bedrohung ein wenig einschränkt :-)

D.W.

2011-01-12 08:02:56 UTC

view on stackexchange narkive permalink

Wenn Sie Bedenken haben, über ein unsicheres Netzwerk sicher zu einer Site zu navigieren, können Sie die besten Schritte zur Gewährleistung der Sicherheit unternehmen:

Stellen Sie sicher, dass die Site HTTPS verwendet , nicht HTTP.
Stellen Sie sicher, dass die Site über ein gültiges Zertifikat verfügt. Klicken Sie nicht durch Warnungen. Akzeptieren Sie keine ungültigen Zertifikate.
Verwenden Sie HTTPS Everywhere oder Force-TLS, um sicherzustellen, dass Sie ein HTTPS verwenden (dh SSL-verschlüsselte) Verbindung für alles, was mit dieser Site zu tun hat.

tobylane

2011-01-09 16:49:26 UTC

view on stackexchange narkive permalink

Ganz in der Praxis. Die Verschlüsselung beginnt mit den Root-SSL-Personen (Verisign, Thawte usw.) und ist daher für unsichere Leitungen geeignet. AFAIK TLS hat kein Problem mit Man-in-the-Middle-Angriffen, seinen einzigen schwächeren / älteren Handshakes, die dieses Problem haben.

TLS ist anfällig für MITM

IrqJD

2011-01-09 23:44:02 UTC

view on stackexchange narkive permalink

Die meisten vergessen den Benutzeraspekt und wie sie diesen PC auch am Hotspot verwenden könnten. Die meisten Leute verwenden ähnliche Passwörter auf anderen Websites, können bloggen, ... usw. Diese sind möglicherweise nicht so sicher wie HTTPS / SSL-Google Mail, mit dem Sie möglicherweise eine Verbindung herstellen. Problem Ich sehe aus Sicherheitsgründen, dass die meisten Leute auf andere Websites gehen und ein Paket-Sniffing-Programm mit genügend Informationen bereitstellen, um auf einige Ihrer Konten zugreifen zu können. Das Beste ist, wie bereits erwähnt, wenn Sie eine unverschlüsselte drahtlose Verbindung verwenden. Hoffentlich haben Sie einen VPN, mit dem Sie sich danach verbinden können, um die zusätzliche Sicherheitsebene zu schaffen.

Arjun sharma

2016-10-24 16:37:08 UTC

view on stackexchange narkive permalink

Die Verbindung ist ziemlich sicher, was sichere Verbindungen (ssl) betrifft. Vorausgesetzt, wenn es bewusst verwendet wird:

Es sollte keine Umleitung von HTTPS zu HTTP geben.
Einige Websites verwenden HTTP-cmd auch über HTTPS-Seiten Alle vertraulichen Informationen, die über diese
schwach konfigurierten https-Server und veralteten Browser übertragen werden, können auch über sichere Sockets

noch ausgenutzt werden

FrostyFire

2017-12-06 07:59:51 UTC

view on stackexchange narkive permalink

Die Sortierantwort lautet, soweit wir wissen, dass Sie in 99% der Fälle sicher sind, wenn HTTPS korrekt eingerichtet ist. Das ist ein großes Wenn. Es ist nicht so einfach, nur HTTPS in Ihrem Browser zu sehen. SSL-Strip funktioniert immer noch auf einigen sicheren Sites / Browsern.

Vergessen wir nicht, dass vor SSL-Strip niemand gedacht hat, dass ein solches Tool funktionieren könnte. Cybersicherheit ist ein sich ständig veränderndes Feld und sozusagen ein Whak-a-Mole-Spiel. Irgendwann wird ein neuer Exploit veröffentlicht, mit dem Sie den von Ihnen erwähnten Angriff auf einer beliebigen Site ausführen können. Schauen Sie sich den "unzerbrechlichen" WPA2-Standard an. Immerhin nicht so unzerbrechlich. Es wird gepatcht, aber es tut nicht viel für die zuvor gehackten Personen.

Derzeit gibt es eine Möglichkeit, ordnungsgemäß konfigurierten SSL-Verkehr zu entschlüsseln. Es erfordert den Zugriff auf eine Zertifizierungsstelle und die Ausstellung vollständig vertrauenswürdiger Zertifikate. Ihr Browser erkennt damit keinen MiTm-Angriff. Die gute Nachricht ist, dass es extrem schwer ist, es durchzuziehen ... fürs Erste. Die Verwendung eines VPN garantiert keine Sicherheit, da das VPN selbst der Mitm-Angreifer sein kann.

Grundsätzlich kann und wird alles, was online ist, gehackt. Es gibt Dinge, die Sie tun können (VPN, aktualisierter Browser usw.), um das Risiko zu minimieren, aber Sie sind niemals 100% sicher. Lassen Sie sich von niemandem etwas anderes sagen.