Das HTTPS -Protokoll entspricht der Verwendung von HTTP über eine SSL- oder TLS -Verbindung (über TCP).

Also zuerst ein Die TCP-Verbindung (an Port 443) zum Server wird geöffnet. Dies reicht normalerweise aus, um dem Angreifer den Hostnamen des Servers (in Ihrem Fall www.mysite.com ) mitzuteilen. Die IP-Adresse wird direkt beobachtet und:

1. Sie haben normalerweise zuvor eine unverschlüsselte DNS-Abfrage durchgeführt.
2. Viele HTTPS-Server bedienen nur eine Domäne pro IP-Adresse.
3. Das Serverzertifikat wird in einfacher Form gesendet und enthält den Servernamen (möglicherweise zwischen mehreren).
4. In neueren TLS-Versionen gibt es die Angabe des Servernamens, anhand derer der Client dem Server angibt Server, welcher Hostname gewünscht wird, damit der Server das richtige Zertifikat vorlegen kann, wenn er mehrere hat. (Dies geschieht, um von 2 wegzugehen.)
ol>

Dann findet ein TLS-Handshake statt. Dies beinhaltet die Aushandlung einer Verschlüsselungssuite und anschließend einen Schlüsselaustausch. Angenommen, mindestens einer Ihrer Browser und der Server haben die NONE -Verschlüsselung nicht in die akzeptierten Suites aufgenommen, wird alles nach dem Schlüsselaustausch verschlüsselt.

Und vorausgesetzt, es gibt keinen Erfolg Man-in-the-Middle-Angriff (dh ein Angreifer, der die Verbindung abfängt und ein gefälschtes Serverzertifikat vorlegt, das Ihr Browser akzeptiert), der Schlüsselaustausch ist sicher und kein Lauscher kann alles entschlüsseln, was dann zwischen Ihnen und dem Server gesendet wird und auch kein Angreifer kann einen Teil des Inhalts ändern, ohne dass dies bemerkt wird. Dies umfasst die URL und jeden anderen Teil der HTTP-Anforderung sowie die Antwort vom Server.

Natürlich als D.W. Erwähnungen: Die Länge sowohl der Anfrage (die nicht viel mehr variable Daten als die URL enthält, möglicherweise einige Cookies) als auch der Antwort kann dem verschlüsselten Datenstrom entnommen werden. Dies kann die Geheimhaltung untergraben, insbesondere wenn sich nur eine geringe Anzahl unterschiedlicher Ressourcen auf dem Server befindet. Auch alle nachfolgenden Ressourcenanforderungen.

Ihr Passwort in der URL (oder einem anderen Teil der Anfrage) sollte jedoch immer noch sicher sein - höchstens kann seine Länge bekannt sein.

Wie Ihnen @ Paŭlo Ebermann und @ Jeff Ferland mitgeteilt haben, ist die GET-Anforderung unter SSL verschlüsselt und somit sicher. Vergessen Sie jedoch nicht, dass viele Webserver GET-Anforderungen und -Parameter protokollieren und dass Anmeldeinformationen oder andere vertrauliche Informationen, die Sie über GET senden, möglicherweise irgendwo in ein Protokoll geschrieben werden. Aus diesem Grund sollten Sie beim Übermitteln vertraulicher Daten POST (das auch unter SSL verschlüsselt wird) verwenden.

Dies fällt in die Kategorie "Verschlüsselung ist keine magische Sicherheit, die alle Ihre Probleme löst."

Sie sollten davon ausgehen, dass die URL nicht geschützt ist, dh dass ein passiver Lauscher möglicherweise erfahren kann, welche URL Sie besuchen.

Mir ist klar, dass dies im Widerspruch zu den Behauptungen anderer Leute steht, also ich Es ist besser zu erklären.

Es ist wahr, dass alles nach dem Domain-Namen verschlüsselt gesendet wird. Wenn die URL beispielsweise https://www.example.com/foo/bar.html lautet, ist www.example.com für den Angreifer sichtbar Die HTTP-Anforderung ( GET /foo/bar.html HTTP / 1.0 ) wird verschlüsselt. Dies verhindert, dass ein Lauscher den Pfadteil der URL direkt sieht. Die Länge des Pfadteils der URL kann jedoch für den Lauscher sichtbar sein. Darüber hinaus können für den Lauscher auch andere Informationen sichtbar sein, z. B. die Länge der von Ihnen besuchten Seite. Dies ist ein Fuß in der Tür für den Angreifer. Es wurden einige Untersuchungen durchgeführt, bei denen anhand dieses Fußes in der Tür ermittelt wird, welche URLs Sie besuchen, wenn der Angreifer Ihren https-Verkehr abhören kann.

Es gibt zwar keine Garantie dafür Diese Angriffe werden erfolgreich sein. Ich schlage vor, dass es ratsam ist, das Schlimmste anzunehmen: anzunehmen, dass ein Lauscher möglicherweise erfahren kann, welche URLs Sie besuchen. Daher sollten Sie nicht davon ausgehen, dass SSL / TLS vor einem Lauscher verbirgt, welche Seiten Sie besuchen.

Ja, https bietet Integrität für die von Ihnen besuchte URL.

PS Eine weitere Warnung: In der Praxis können sslstrip- und andere Man-in-the-Middle-Angriffe gegen viele oder die meisten Benutzer erfolgreich sein, wenn auf der Website kein HSTS verwendet wird. Diese Angriffe können sowohl die Vertraulichkeit als auch die Integrität der URL verletzen. Wenn Benutzer Websites besuchen, die HSTS nicht über ein unsicheres Netzwerk verwenden (z. B. offenes WLAN), sollten Sie daher vorsichtig sein, dass ein Angreifer möglicherweise erfahren kann, welche Seiten die Benutzer besuchen. Eine teilweise Minderung der sslstrip-Bedrohung besteht darin, dass Benutzer HTTPS Everywhere verwenden und Websites HSTS übernehmen.

Die folgenden Dinge werden vor Beginn Ihrer Sitzung auslaufen:

• IP-Adresse des Servers
• Zertifikat des Servers
  • Dazu gehört die Domäne Der auf dem Zertifikat veröffentlichte Name garantiert jedoch nicht, dass er mit dem von Ihnen verwendeten übereinstimmt.
• Sie DNS-Abfragen

Keine Daten oder Anforderungen, die nicht mit dem Erstellen der SSL-Verbindung zusammenhängen ( GET ... ), werden vor Beginn der SSL-Sitzung an den Server gesendet. Die URL wird als Teil der Seitenanforderung gesendet und genauso geschützt wie der gesamte Datenverkehr, der Teil der Sitzung ist.

Ja und Nein.

Die URL ist ordnungsgemäß verschlüsselt, daher sollten Abfrageparameter niemals direkt angezeigt werden.

Bei der Verkehrsanalyse kann jedoch häufig die Länge der URL ermittelt werden - und Die Kenntnis des Servers und der Länge der URL reicht oft aus, um zu belauschen, auf welche Seiten zugegriffen wird, insbesondere wenn davon ausgegangen wird, dass auf Links auf einer Seite geklickt wird. Google für "Traffic Analysis SSL Browsing" oder ähnliches, wenn das Thema Sie interessiert.

In Ihrem Anwendungsfall ist dies von marginaler Bedeutung. Eine geschickte Verwendung der Verkehrsanalyse kann die Länge des Benutzernamens und / oder die Länge des Kennworts anzeigen, je nachdem, ob die anderen abgerufenen URLs auch den Benutzernamen enthalten. Wenn Sie den Benutzernamen / das Kennwort auf eine konstante Länge auffüllen, können Sie diese Angriffe vermeiden, aber es lohnt sich möglicherweise nicht.

TLS-Stapel beginnen mit der Übertragung der Servernamenanzeige (SNI, http://en.wikipedia.org/wiki/Server_Name_Indication; http://www.ietf.org/rfc) /rfc3546.txt). Dies wird im Klartext gesendet, was bedeutet, dass Lauscher den Servernamen sehen können, den Sie in die Adressleiste eingeben.