Frage:
Kann jemand, der Wireshark verwendet, die vollständige URL erhalten, wenn mein Programm HTTPS verwendet?
Icann
2015-02-06 08:14:56 UTC
view on stackexchange narkive permalink

Beim Durchsuchen des Inhalts von pcap-Dateien habe ich festgestellt, dass einige URLs trotz HTTPS sichtbar sind. Diese treten hauptsächlich in Nutzdaten auf, die auch Zertifikats-URLs enthalten, aber ich sehe auch HTTPS-URLs in scheinbar HTTP-Nutzdaten.

Kann jemand abschließend sagen, ob HTTPS-URLs wirklich geheim gehalten werden?

Ich mache mir darüber Sorgen, weil ich einige Parameter in die URL einfügen möchte und dies nicht möchte leicht aufgedeckt werden.

Es hört sich so an, als würden Sie einfachen HTTP-Verkehr betrachten, der zufällig Hyperlinks zu HTTPS-Seiten enthält. Die Tatsache, dass der Hyperlink zu einer HTTPS-Seite führt, wenn er befolgt wird, verschlüsselt die Daten auf der damit verknüpften Seite nicht auf magische Weise.
Die Antwort ist einfach. Ist die Person, auf der Wireshark ausgeführt wird, ein Administrator des Computers, auf dem Ihr Programm ausgeführt wird? IFF ja, dann ja.
@Izam: klingt plausibel. Eine teilweise Antwort auf "Werden HTTPS-URLs wirklich geheim gehalten?" ist "nicht, wenn Sie diese URLs im Internet veröffentlichen" ;-)
Um alle Antworten zusammenzufassen: Die Anforderungs-URL (außer Hostname) ist genauso geschützt wie der Rest der Daten, außer sie werden möglicherweise im Browserverlauf gespeichert. Mithilfe der Verkehrsanalyse können Angreifer herausfinden, was jemand auf Ihrer Website tut. Vertrauliche Informationen in Formularparametern, die mit GET-Anforderungen gesendet werden, sind über das Netzwerk in Ordnung, solange SSL nicht besiegt wird (mit mehreren Antworten auf diese nützliche Tangente), sollten aber möglicherweise vermieden werden, um sie auf eine Weise zu verwenden, die für Benutzer geeignet ist Browserverlauf.
@Icann ist zwar nicht mit Ihrer spezifischen Frage verbunden, es ist jedoch wichtig, sich daran zu erinnern, dass https-URLs auf der Serverseite der Protokolldateien landen können (möglicherweise sogar mehrere Protokolle, z. B. stunnel> haproxy> nginx> appserver). Das ist wahrscheinlich ein Grund genug, um "geheime" Dinge aus der URL und der URL-Abfragezeichenfolge herauszuhalten, unabhängig davon, ob HTTP oder HTTPs
Fünf antworten:
Steffen Ullrich
2015-02-06 12:08:22 UTC
view on stackexchange narkive permalink

Bei HTTPS werden der Pfad und die Abfragezeichenfolge der URL verschlüsselt, während der Hostname im SSL-Handshake als einfacher Text angezeigt wird, wenn der Client die Servernamenanzeige (SNI) verwendet. Alle modernen Clients verwenden SNI, da dies die einzige Möglichkeit ist, unterschiedliche Hosts mit eigenen Zertifikaten hinter derselben IP-Adresse zu haben.

Der Rest der URL (dh alles außer dem Hostnamen) wird nur innerhalb von verwendet verschlüsselte Verbindung. Theoretisch ist es daher vor dem Angreifer verborgen, es sei denn, die Verschlüsselung selbst wird unterbrochen (Gefährdung des privaten Schlüssels, Man-in-the-Middle-Angriffe usw.). In der Praxis hat ein Angreifer möglicherweise indirekte Möglichkeiten, Informationen über den verbleibenden Teil der URL abzurufen:

  • Verschiedene Seiten auf demselben Server liefern unterschiedliche Inhalte mit unterschiedlichen Größen usw. Wenn der Angreifer die Site scannt Finden Sie alle möglichen Seiten heraus. Er kann dann möglicherweise anhand der Größe der übertragenen Daten herausfinden, auf welche Seiten Sie zugegriffen haben.
  • Links zu anderen Websites enthalten den Referer-Header. Normalerweise wird der Referer beim Verknüpfen von https zu http entfernt. Wenn der Angreifer jedoch eine der mit https verknüpften Sites kontrolliert, kann er möglicherweise herausfinden, woher der Link stammt, dh die Site, auf die Sie zugegriffen haben.

Aber in den meisten Fällen sind Sie mit HTTPS ziemlich sicher, zumindest viel sicherer als mit einfachem HTTP.

Ich gehe davon aus, dass eine andere indirekte Methode darin besteht, Ihren Browserverlauf anzuzeigen.
Das ist eigentlich kein schlechter Punkt. Ich meine, wenn ein Angreifer Ihren Browserverlauf lesen kann, kann er wahrscheinlich viel mehr tun. Es kann jedoch eine gute Idee sein, vertrauliche Informationen aus URLs herauszuhalten, damit sie nicht in den Browserverlauf aufgenommen werden, um den Schaden zu begrenzen, wenn jemand verliert, dessen Browserverlauf kompromittiert wird.
zakjan
2015-02-06 10:16:58 UTC
view on stackexchange narkive permalink

Sowohl HTTP-Header (mit der angeforderten URL) als auch Anwendungsdaten in HTTPS sind verschlüsselt.

Sie können den angeforderten Hostnamen anzeigen, da Browser ihn in Service Name Indication senden Erweiterung während des Handshakes, sodass der Server das passende SSL-Zertifikat auswählen kann.

Guntram Blohm supports Monica
2015-02-06 16:09:51 UTC
view on stackexchange narkive permalink

Mit wireshark können Sie den Hostnamen herausfinden, wie in einigen anderen Antworten aufgrund von SNI erwähnt. Außerdem können Sie einige Teile von Zertifikaten sehen. Die https-URLs, die Sie gesehen haben, waren wahrscheinlich die URLs von CRL oder OCSP.

Wenn jemand Ihre URLs durch Gehen auf Ihrer Website erreichen könnte Wenn Sie die Größe der zurückgegebenen Seiten mit der Größe der auf Ihrer verschlüsselten Seite zurückgegebenen Seiten vergleichen, können sie Annahmen darüber treffen, welche Seite Ihr Programm aufgerufen hat. Da Sie jedoch einige Parameter in die URL einfügen und diese ausblenden möchten, ist dies in Ihrem Fall kein großer Angriffsvektor. Wenn Ihre URL https: //my.server/api? User = scott&password = tiger&highscore = 12345 lautet und Ihre API immer Seiten zwischen 1000 und 1010 Bytes zurückgibt, hilft es niemandem, 1007 zurückgegebene Bytes zu sehen Bestimmen Sie den Benutzer oder das Kennwort oder wie Sie einen Highscore eingeben.

JEDOCH

https ist nur dann sicher, wenn Sie MITM-Angriffe verhindern. Tools wie fiddler, charles oder mitmproxy leiten Ihren Datenverkehr an sich selbst weiter, legen dem Client ein gefälschtes Zertifikat vor, entschlüsseln den Datenverkehr, protokollieren ihn erneut -verschlüsseln Sie es und senden Sie es an die ursprüngliche Site.

Wenn Ihr Client auf den Truststore des Betriebssystems angewiesen ist, kann der Angreifer sein eigenes Zertifikat in den Truststore einfügen, und Ihr Client bemerkt nichts . Die READMEs der oben genannten Tools enthalten Anweisungen dazu.

Wenn Sie also https verwenden, um die Entschlüsselung zu verhindern, müssen Sie überprüfen, ob das vom Server zurückgegebene Zertifikat korrekt ist, bevor Sie Ihre URL tatsächlich senden . Überprüfen Sie, wie das Anheften von Zertifikaten für Ihr Betriebssystem / Ihre Programmiersprache funktioniert, und verwenden Sie die oben genannten Tools, um sicherzustellen, dass Ihr Client ein gefälschtes Zertifikat erkennt und die URL nicht sendet, bevor Sie es veröffentlichen.

Gute Antwort zur Erwähnung der Möglichkeit, dass der Browser die CRL-Veröffentlichungsseite kontaktiert, um ein Zertifikat zu erhalten. Ich habe nie verstanden, warum Zertifizierungsstellen diese nicht auf https-Websites veröffentlichen. Sie scheinen hauptsächlich auf http-Sites zu sein, was wenig Sinn macht.
@SteveSether Die CRL-Datei ist signiert und nicht verschlüsselt. Daher ist unsicheres http in Ordnung. Außerdem wäre die Verwendung von https schwierig: Wie stellen Sie eine Verbindung zu "https: // crl.example.com /" her, um das eigene Zertifikat von "crl.example.com" zu validieren? http umgeht dieses Problem.
@MattNordhoff Danke! Das beantwortet die Frage. Obwohl ich glaube, dass die CRL nur zum Widerruf gedacht ist, vertrauen Sie der Zertifizierungsstelle und dem Stammzertifikat der Zertifizierungsstelle. Ich gehe davon aus, dass es mit dem Stammzertifikat der Zertifizierungsstelle signiert ist.
@MattNordhoff - Unsicheres http ist * nie * in Ordnung.
wireghoul
2015-02-06 12:37:16 UTC
view on stackexchange narkive permalink

Es ist möglich, eine Verkehrsanalyse durchzuführen, indem die Website gecrawlt und Paketgrößen usw. verglichen werden. Je nachdem, wie viel dynamischer Inhalt vorhanden ist oder auf welche Bilder von der URL verwiesen wird, kann eine sehr genaue Analyse durchgeführt werden Verständnis, welche URLs besucht wurden.

Die Präsentation SSL-Verkehrsanalyse-Angriffe - Vincent Berg (YouTube) erklärt dies und enthält einige Funktionsdemonstrationen.

Dies ist zwar interessant, beantwortet aber eindeutig nicht die Frage, da wireshark das nicht tut. Ich mag es nicht, Pedant zu sein, aber die Antwort hängt nur tangential mit der Frage zusammen. Dies scheint eher als Kommentar als als Antwort angemessener zu sein.
Ich habe auf die sicherheitsspezifischen Bedenken geantwortet. Ich denke nicht, dass Sicherheitsentscheidungen auf der Grundlage der wahrgenommenen Grenzen von Tools getroffen werden sollten. Da wireshark Plugins unterstützt, kann die Funktion hinzugefügt werden.
Alim Özdemir
2018-05-11 19:03:15 UTC
view on stackexchange narkive permalink

Wenn der Angreifer Zugriff auf den Client hat, finden Sie eine Übersicht unter: https://wiki.wireshark.org/SSL#Using_the_.28Pre.29-Master-Secret

Beispielsweise kann auf Java-Clients ein Agent wie jSSLKeylog angehängt werden, um den vermeintlich verschlüsselten Inhalt / URL abzufangen und zu protokollieren. Wenn das PreMaster-Geheimnis einer Kommunikation auf irgendeine Weise im Prozess erhalten werden kann, kann verschlüsselte Kommunikation erfasst werden danach dekodiert werden.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...