Frage:
Warum enthalten HTTPS-Anforderungen den Hostnamen im Klartext?
jay-charles
2015-04-23 21:46:40 UTC
view on stackexchange narkive permalink

Ich habe ein wenig Probleme zu verstehen, warum das HTTPS-Protokoll den Hostnamen im Klartext enthält. Ich habe gelesen, dass der Hostname und die IP-Adressen eines HTTPS-Pakets nicht verschlüsselt sind.

Warum kann der Hostname nicht verschlüsselt werden? Können wir die Ziel-IP nicht einfach im Klartext belassen (damit das Paket routingfähig ist)? Wenn das Paket dann am Zielserver ankommt, wird das Paket entschlüsselt und der Host / Index aus dem Header identifiziert?

Möglicherweise besteht das Problem darin, dass für eine bestimmte Ziel-IP unterschiedliche Zertifikate vorhanden sein können (unterschiedliche Zertifikate für unterschiedliche Subdomänen?), Sodass der Zielserver das Paket erst entschlüsseln kann, wenn es auf dem richtigen Host innerhalb dieses Servers eintrifft. Macht das irgendeinen Sinn oder bin ich weit weg?

Die Verschlüsselungsalgorithmen müssen eingerichtet werden, bevor die Verschlüsselung stattfinden kann. Deshalb ist zunächst alles klar. Der Domänenname ist im Allgemeinen Teil des Zertifikats, das der Server im Klartext sendet. Jede Domäne oder IP, die dem Zertifikat des Servers zugeordnet ist, ist ohnehin verfügbar. Dies ist Teil der Identifizierung des Servers. HTTPS bietet keine Anonymität, sondern nur Sicherheit.
Warum wird nach dem Handshake und der Auswahl der Verschlüsselungsalgorithmen nicht alles außer der Ziel-IP verschlüsselt?
Zur Verdeutlichung: Früher dachte ich, dass der HTTP-Host-Header bei Verwendung von HTTPS irgendwie sichtbar blieb.Das ist nicht der Fall.Alle HTTP-Header, Abfrageparameter, Textkörper usw. werden innerhalb der TLS-Verbindung verschlüsselt.Stattdessen beginnt die TLS-Verbindung selbst mit einem Handshake, der das Feld "Servername" enthält. Dies kann erforderlich sein, damit der Server mit dem entsprechenden Zertifikat antwortet und / oder ein Shared Hosting-Anbieter ermittelt, für welche Kundenanwendung die Anforderung bestimmt ist, da sie dieselbe IP-Adresse haben.
In fast allen Fällen (1) wurde unmittelbar vor der ersten (2) HTTPS-Verbindung eine DNS-Abfrage durchgeführt, bei der der Domainname im Klartext veröffentlicht wurde.(1) Ausnahmen sind, wenn der Domänenname in einer lokalen Datei (wie der Hosts-Datei) definiert ist oder wenn eine vorherige DNS-Abfrage eine Platzhalterantwort (`*` Antwort) zurückgegeben hat. (2) Nachfolgende Verbindungen verwenden die zwischengespeicherte DNS-Antwort wieder und können auch die TLS-Sitzung wiederverwenden.
Vier antworten:
Steffen Ullrich
2015-04-23 22:03:38 UTC
view on stackexchange narkive permalink

Der Hostname ist im ersten SSL-Handshake enthalten, um Server zu unterstützen, die mehrere Hostnamen (mit unterschiedlichen Zertifikaten) auf derselben IP-Adresse haben (SNI: Server Name Indication). Dies ähnelt dem Host-Header in einfachen HTTP-Anforderungen. Der Name ist in der ersten Nachricht des Clients (ClientHello) enthalten, dh bevor eine Identifizierung und ein Schlüsselaustausch durchgeführt werden, damit der Server das richtige Zertifikat zur Identifizierung anbieten kann.

Während das Verschlüsseln des Hostnamens nett wäre, wäre die Frage, welcher Schlüssel für die Verschlüsselung verwendet werden soll. Der Schlüsselaustausch erfolgt erst nach Identifizierung der Site durch Zertifikat, da Sie sonst möglicherweise Schlüssel mit einem Mann in der Mitte austauschen. Die Identifikation mit Zertifikaten erfordert jedoch bereits den Hostnamen, damit der Server das passende Zertifikat anbieten kann. Die Verschlüsselung des Hostnamens müsste also mit einem Schlüssel erfolgen, der entweder auf einer anderen Art der Identifizierung basiert oder nicht sicher gegen Man-in-the-Middle ist.

Es könnte Möglichkeiten zum Schutz geben Der Hostname im SSL-Handshake, jedoch auf Kosten des zusätzlichen Overheads bei Handshake und Infrastruktur. Es wird derzeit diskutiert, ob und wie verschlüsselte SNI in TLS 1.3 aufgenommen werden können. Ich schlage vor, Sie sehen sich diese Präsentation und die IETF-TLS-Mailingliste an.

Abgesehen davon kann es auch bei anderen zu einem Verlust des Hostnamens kommen bedeutet, wie die vorhergehende DNS-Suche nach dem Namen. Und natürlich ist das in der Serverantwort gesendete Zertifikat auch nicht verschlüsselt (dasselbe Problem, noch kein Schlüssel), und daher kann das angeforderte Ziel aus der Serverantwort extrahiert werden.

Es gibt viele Websites da draußen Dies funktioniert nicht ohne SNI, wie alle kostenlosen SSL-Angebote von Cloudflares. Wenn ein Client darauf zugreift, der SNI nicht unterstützt (wie IE8 unter Windows XP), führt dies entweder zu einem falschen Zertifikat oder zu einem SSL-Handshake-Fehler wie "unbekannter_name".

Ich sehe einige Parallelen zwischen diesem und dem Google-Push "https überall". Es wäre zwar großartig, alles zu verschlüsseln und alle MitM-Möglichkeiten (auch für Streaming-Sites) zu verhindern, aber wie werden wir mit all den Einsparungen bei Caching und Bandbreite umgehen, die durch die Verschlüsselung zunichte gemacht werden?
@JoshvonSchaumburg Ich würde sagen, das Argument ist, dass die Infrastruktur jetzt hauptsächlich von Dingen verwendet wird, die sowieso nicht zwischengespeichert werden (z. B. das Ansehen von YouTube-Videos). Wenn es funktionieren würde, warum sollten sich Unternehmen dann mit ihren eigenen CDNs beschäftigen? Die ISPs und Infrastrukturbetreiber haben keine Motivation mehr, Caching gut zu machen, weil sie byteweise bezahlt werden;)
Ich bin mir bei dieser Erklärung nicht sicher. Zum einen haben ISPs die Motivation, gut zwischenzuspeichern. Die meisten von ihnen (zumindest in den USA und ich nehme an, anderswo) bieten eine unbegrenzte monatliche Pauschalgebühr an. Dies bedeutet, dass sie absolut einen Anreiz zum Cachen haben. Selbst wenn sie datengesteuerte Pläne anbieten (zum Beispiel Mobilfunkanbieter oder die Testmärkte, in denen ISPs kabelgebundenes Breitband begrenzen), haben Dienstanbieter immer noch einen Anreiz, innerhalb ihrer Netzwerke zwischenzuspeichern, da dann die Geschwindigkeiten höher sind. Außerdem müssen sie nicht mit anderen Netzwerken vergleichen, um die Videostreams mit Caching-Servern abzurufen.
@JoshvonSchaumburg Da ein Angreifer weiß, welche Site er angreifen möchte, und auf legale Weise Informationen über diese Site sammelt (Google, Öffnen der Site in seinem Browser usw.), erhält er die Informationen, die Sie unbedingt ausklicken möchten, auf Knopfdruck eine Schaltfläche, nämlich die Zuordnung eines Hostnamens zu seiner IP. Es gibt Angriffe mit Klartextinjektion - etwas, das nicht benötigt würde, wenn der Hostname verschlüsselt wäre. Das Verschlüsseln des Hostnamens würde also eine Sicherheitsanfälligkeit für die Sicherung von Informationen erzeugen, die auf andere Weise leicht abgerufen werden können.
@MarkusWMahlberg: Das Ziel der Verschlüsselung von SNI wäre nicht, die Zuordnung von Hostname zu IP zu verbergen, sondern den tatsächlichen Hostnamen, auf den Sie zugreifen, auf Systemen zu verbergen, die viele Hostnamen pro IP haben (typische Hosting-Dienste, CDN ...). Und ich sehe Ihr Argument nicht, dass das Verschlüsseln von SNI neue Sicherheitslücken schaffen würde, ich sehe nur, dass es entweder einen erheblichen Overhead oder einfach ineffektiv wäre.
@SteffenUllrich Einige verwendete Chiffren weisen Schwächen gegen bekannte Klartextangriffe auf. Da jede Anfrage bekannten Klartext enthalten würde, würde dies eine theoretische Schwäche auferlegen. Ich bin mir nicht sicher, ob das Verbergen des Hostnamens, auf den man zugreift, tatsächlich andere Sicherheit als plausible Verleugnung bringt.
@MarkusWMahlberg - Ich glaube nicht, dass es kaum mein "verzweifelter Versuch ist, etwas zu verbergen", eine Frage zu stellen, um ein Protokoll besser zu verstehen. Fühlen Sie sich frei, den sarkastischen und herablassenden Ton in Zukunft wegzulassen!
@JoshvonSchaumburg Mein Kommentar sollte weder sarkastisch noch herablassend sein, und ich möchte mein äußerstes Bedauern für jedes beleidigte Gefühl zum Ausdruck bringen. Es war nur ein intellektuelles Spiel und bitte seien Sie so freundlich, meinen Kommentar wie beabsichtigt als Teil eines akademischen Streits zu sehen.
Ihre Andeutung, dass ich "verzweifelt" versucht habe, Informationen zu verbergen, die durch "Klicken auf eine Schaltfläche" ermittelt werden konnten, war meiner Meinung nach herablassend für mein begrenztes Wissen zu diesem Thema, aber ich werde Ihre Entschuldigung akzeptieren.
@MarkusWMahlberg: Ich denke nicht, dass Ihr Argument über bekannten Klartext relevant ist. Jede HTTP-Anforderung / Antwort innerhalb einer TLS-Verbindung (d. H. HTTPS) enthält mehr bekannten Klartext als den SNI-Namen.
@Luaan Da Caching es ihnen ermöglicht, für Bytes zu berechnen, die sie nicht tatsächlich übertragen, natürlich.Und YouTube-Videos könnten zwischengespeichert werden, wenn Google nicht überall HTTPS pusht.
@immibis Nun, das ist nicht wirklich spezifisch für Google.Es würde mich nicht wundern, wenn der größte Teil des Website-Verkehrs über das Internet heutzutage HTTPS wäre.Es gibt sogar ISPs, die versuchen, Sie zu zwingen, ihre eigenen Stammzertifizierungsstellen zu installieren!
Wenn der Hostname nach DHKE, aber vor SSL übertragen wurde, kann er vor passivem Snooping geschützt werden.
@Bengie: Zumindest in TLS-Versionen, die kleiner als TLS 1.3 sind, wird der Schlüsselaustausch erst nach Erhalt des Zertifikats gestartet.Die Auswahl des Zertifikats erfordert jedoch die Kenntnis des erwarteten Hostnamens auf Systemen mit mehreren Zertifikaten auf derselben IP-Adresse.Dies bedeutet, dass das Senden des Namens nach DHKE zu spät ist, da dies früher bekannt sein muss, um das entsprechende Zertifikat auszuwählen.
Tom Leek
2015-04-24 00:04:41 UTC
view on stackexchange narkive permalink

SNI ist für das virtuelle Hosting vorgesehen (mehrere Server mit unterschiedlichen Namen und derselben IP-Adresse). Wenn ein SSL-Client eine Verbindung zu einem SSL-Server herstellt, möchte er wissen, ob er mit dem richtigen Server kommuniziert. Dazu sucht es im Zertifikat nach dem Namen des vorgesehenen Servers. Jeder böse Hacker kann ein Zertifikat für seinen eigenen Server ( evilhacker.com ) kaufen, aber er kann es nicht für einen gefälschten Server verwenden, der sich als ehrlich-bank-inc ausgibt. com , da der Client-Browser, der versucht, eine Verbindung zu https://honest-bank-inc.com/ herzustellen, die Zeichenfolge im angeblichen Serverzertifikat ziemlich unnachgiebig findet ehrlich-bank-inc.com und schon gar nicht evilhacker.com .

So weit so gut. Dann wird der technische Teil. In "HTTPS" haben Sie HTTP in SSL gekapselt. Dies bedeutet, dass der SSL-Tunnel zuerst eingerichtet wird (das "Handshake" -Verfahren) und erst dann der Client die HTTP-Anforderung innerhalb dieses Tunnels sendet. Während des Handshakes muss der Server sein Zertifikat an den Client senden. Zu diesem Zeitpunkt hat der Client dem Server jedoch noch nicht mitgeteilt, mit wem er zu sprechen versucht. Der Server kann davon ausgehen, dass der Name, den der Client erreichen möchte, seit er die Verbindung erhalten hat, wahrscheinlich einer der Site-Namen ist, die der Server hostet. Dies ist jedoch eine Vermutung und schlägt fehl, wenn der Server mehrere Sites mit unterschiedlichen Namen hostet.

Es gibt meist drei Möglichkeiten, um dieses Rätsel zu lösen:

  • Eine IP pro Site. Da der Server die Ziel-IP-Adresse vom Beginn der Verbindung an kennt, kann der Server diese IP-Adresse verwenden, um zu wissen, welcher Server das wahre Ziel ist. Natürlich macht der relative Mangel an IP-Adressen diese traditionelle Lösung heutzutage weniger attraktiv.

  • Mehrere Namen im Serverzertifikat. Dies ist vollkommen gültig. Google selbst hat in der Regel mehr als 70 Namen in sein Zertifikat aufgenommen. Eine Variante sind "Platzhalternamen", die '*' enthalten und mit vielen Namen übereinstimmen. Dies funktioniert jedoch nur, solange alle Namen bekannt sind, wenn das Zertifikat ausgestellt wird. Für einen Website-Hosting-Service bedeutet dies den Kauf eines neuen Zertifikats, wenn sich ein Kunde registriert.

  • SNI. Mit SNI sendet der Client den beabsichtigten Namen früh im Handshake, bevor der Server sein Zertifikat sendet. Dies ist die moderne Lösung, und jetzt, da Windows XP über den Rand hinausgegangen ist, kann es endlich weit verbreitet werden (IE unter Windows XP war der letzte Browser, der SNI nicht unterstützte).

Gute Erklärung. Wenn ich also noch IE unter XP verwenden und zu einer HTTPS-Site auf einem Server navigieren würde, auf dem mehrere HTTPS-Sites mit mehreren Zertifikaten gehostet werden, wie würde der Server wissen, welches Zertifikat ohne SNI-Unterstützung bereitgestellt werden soll?
@JoshvonSchaumburg: Der Server weiß es nicht und würde entweder das Standardzertifikat der Site bereitstellen (was zur Ablehnung durch den Browser aufgrund von Namensinkongruenzen führt) oder eine Warnung "unbekannter Name" oder ähnliches zurückgeben.
"Für einen Website-Hosting-Service würde dies den Kauf eines neuen Zertifikats bedeuten, wenn sich ein Kunde registriert." Willst du mich veräppeln? Ich habe vermutet, dass Wildcard-SSL JEDE Zeichenfolge unter der Hauptdomäne zulässt, aber nur auf der ersten Ebene mit * domain.com (IE: 1st.main.com, 2st.1st.main.com).
John Deters
2015-04-23 22:10:38 UTC
view on stackexchange narkive permalink

Die Tatsache, dass Sie mit einem Server kommunizieren, kann offensichtlich nicht vor IP verborgen werden. Die Pakete müssen Ihren Computer verlassen, in das Netzwerk eintreten, zum Ziel geleitet und zugestellt werden. Es ist kein Geheimnis, dass Sie einen Server kontaktieren, der Seiten von https://www.fred.com liefert.

Die URL enthält jedoch nicht die IP. Stattdessen enthält es mehr als eine Information. Es enthält nicht nur den Hostnamen (der in eine IP-Adresse aufgelöst werden muss), sondern auch Details zu der spezifischen Anforderung: Leiten Sie ihn an einen Server mit der Adresse www, search, mail usw. und entlang dieses Verzeichnispfads weiter Name.

Hosting-Dienste haben diese Indirektion ausgenutzt, um mehrere Sites auf einem einzelnen Webserver über die Angabe des Servernamens zu unterstützen. Daher können sowohl https://www.fred.com als auch https://www.barney.com auf einem Server unter 127.0.0.1 gehostet werden, und es ist nur der Name, der unterscheidet, wie der Server diese Nachricht intern weiterleitet. Es ist möglich, dass es aus Sicherheitsgründen an einen separaten Server weitergeleitet werden muss, auf dem die eigentlichen Schlüssel gespeichert werden. Die Schlüssel zum Entschlüsseln dieser Nachricht sind möglicherweise nicht auf diesem Front-End-Server vorhanden, sodass sie erst entschlüsselt werden können, wenn sie auf dem Computer ankommen, auf dem sich die Fred-Site befindet.

Gibt es einen besonderen Grund, warum Sie fred.com anstelle von example.com verwendet haben?Wenn Sie zwei benötigen, können Sie example.org hinzufügen oder, wenn Sie besser unterscheidbare Namen wünschen, {fred, barney} .example verwenden.Diese Domänen sind für die Verwendung in Beispielen reserviert.
gavenkoa
2018-01-27 23:12:39 UTC
view on stackexchange narkive permalink

Neben der Notwendigkeit, den Hostnamen zum Auflösen des Zertifikats anzugeben, gibt es eine gängige Praxis im Zusammenhang mit der Verwendung von SNI, die wichtig zu wissen ist: Sie ermöglicht die Implementierung von https://en.wikipedia.org/wiki/Virtual_hosting über SSL / TLS.

SNI wird von allen gängigen Webservern verwendet:



ⓘ
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...