- Internetkommunikation ist so aufgebaut, dass mehrere Schichten Pakete getrennt verarbeiten. Dank geschichteter Protokolle müssen Entwickler Details von Übertragung, Routing und Sicherheit nicht selbst direkt implementieren
- Eine HTTP-Anfrage folgt einem schrittweisen Ablauf: von der Nachrichtenerstellung im Browser über DNS-Auflösung, TCP-3-Way-Handshake und den Weg über Router bis zur Serverantwort
- Normales HTTP überträgt Header und Body im Klartext und ist daher anfällig für Abhören und Server-Imitation. Um diese Grenzen zu schließen, wurde eine Sicherheitsschicht ergänzt
- HTTPS ist HTTP plus TLS-Verschlüsselung und Verifikation. Der TLS-Handshake ist der Prozess, in dem Version, cipher suite, Zertifikat und Informationen zum Schlüsselaustausch abgestimmt werden, um einen symmetrischen Sitzungsschlüssel zu erzeugen
- TLS 1.3 schließt RSA sowie unsichere cipher suites und Parameter aus und reduziert die Auswahl. Dadurch entsteht ein einfacherer, schnellerer und sichererer Handshake als zuvor
Das Schichtenmodell der Internetkommunikation
- Das Internet ist ein Netz aus miteinander verbundenen Computernetzwerken, und „Internet“ bedeutet wörtlich „zwischen Netzwerken“
- Es arbeitet als paketvermitteltes Mesh-Netzwerk mit einer best-effort delivery-Struktur, bei der weder die Zustellung von Paketen noch deren Ankunftszeit garantiert wird
- Dass das Internet scheinbar reibungslos funktioniert, liegt daran, dass mehrere Abstraktionsschichten im Hintergrund Dinge wie Wiederholungen, Reihenfolgegarantie, Duplikatentfernung und Sicherheit übernehmen
- Jede Schicht stellt eine bestimmte Funktion bereit, und unterschiedliche Protokolle können diese Funktion implementieren
- Durch diese Modularisierung kann ein Protokoll in einer Schicht ausgetauscht werden, ohne dass Protokolle in anderen Schichten beeinflusst werden müssen
Aufgaben der einzelnen Netzwerkschichten
- Die Application layer verarbeitet anwendungsspezifische Logik. Die Kommunikationseinheit ist die Nachricht, und HTTP ist ein typisches Beispiel
- Die Security layer stellt Verschlüsselung und Authentifizierung bereit. Die Kommunikationseinheit ist der Record, TLS ist ein Beispiel
- Die Transport layer ist für zuverlässige Datenübertragung zuständig, verwendet TCP-Segmente oder UDP-Datagramme und identifiziert über Portnummern
- Die Network layer routet Pakete über das Internet hinweg und verwendet IP-Adressen als Kennung
- Die Link layer verwaltet die Kommunikation nahe am physischen Medium, verwendet Frames und identifiziert über MAC-Adressen
- Die Physical layer überträgt Bits physisch zwischen Geräten; Beispiele sind Glasfaser oder Ethernet-Kabel
Ablauf einer HTTP-Anfrage
Wie Pakete den Server erreichen
- Wenn der Client eine Anfrage sendet, wandern die Datenpakete nicht direkt zum Server, sondern suchen über verschiedene Netzwerkgeräte und Router einen Pfad zum Gateway des Servernetzwerks
- Anschließend übernimmt die Link layer die Übertragung im lokalen Abschnitt
-
Schritte, wie Text das Internet überquert
- Das Client-Gerät kapselt die HTTP-Anfragedaten zunächst in ein TCP-Segment und verpackt dieses dann in ein IP-Paket
- Bei einer kabelgebundenen Verbindung wird dieses wiederum in einen Link-layer-Frame wie einen Ethernet-Frame gekapselt
- Der Frame wird über das lokale Netzwerk an den Router des Clients übertragen
- Der lokale Router empfängt den Frame, entfernt den Link-layer-Header und verarbeitet das IP-Paket
- Anhand der Ziel-IP-Adresse entscheidet der Router über den nächsten Hop
- Das Paket wird über einen oder mehrere Zwischenrouter an das nächste Netzwerk weitergeleitet, wobei jeder Router erneut den nächsten Hop bestimmt
- Schließlich erreicht das Paket einen Router im selben Netzwerk wie der Zielserver
- Dieser Router trifft die finale Routing-Entscheidung und sendet das Paket an das lokale Gerät, das dem Server entspricht
- Der Router des Servers überträgt das Paket über das lokale Netzwerksegment an den Server
- Die Link layer sorgt dafür, dass der Frame korrekt an die Netzwerkschnittstelle des Servers zugestellt wird
- Der Server empfängt den Frame, extrahiert das IP-Paket und verarbeitet das eingekapselte TCP-Segment, um die ursprüngliche HTTP-Anfrage wiederherzustellen
- Dieser Network layer-Prozess zum Versand von Paketen über das Internet wird auch in früheren Schritten wie Domainnamenauflösung oder TCP-Handshake verwendet
Serverantwort und Browser-Rendering
- Nachdem der Server die HTTP-Anfrage verarbeitet hat, sendet er eine HTTP-Antwort an den Client zurück
- Die Antwort enthält die verwendete HTTP-Version, einen Statuscode wie
200 oder 404, Response-Header und einen Body wie HTML oder JSON-Daten der angeforderten Seite
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456
Example Page
Hello, world!
- Der Client empfängt und verarbeitet die HTTP-Antwort
- Der Browser interpretiert das HTML und rendert den Inhalt auf dem Bildschirm
- Wenn die Antwort zusätzliche Ressourcen wie Bilder, CSS oder JavaScript enthält, sendet der Browser nach demselben Ablauf weitere HTTP-Anfragen
Sicherheitsprobleme von HTTP und HTTPS
- Standard-HTTP bietet überhaupt keine Sicherheit
- Wer die Verbindung abhört, kann 100 % der ausgetauschten Daten sehen
- Wenn sich jemand als Server ausgibt, kann der Client wichtige Informationen an das falsche Ziel senden
- HTTPS ist HTTP mit zusätzlicher Verschlüsselung und Verifikation
- Es gibt mehrere Möglichkeiten, HTTP-Kommunikation sicher zu machen, aber die heute allgemein verwendete Implementierung ist TLS
- TLS ermöglicht es Client und Server, ihre Identität gegenseitig zu überprüfen und den Payload so zu verschlüsseln, dass beide Seiten ihn entschlüsseln können
- Der Ablauf einer HTTPS-Anfrage entspricht dem zuvor beschriebenen Ablauf einer HTTP-Anfrage, aber zwischen Application layer und Transport layer kommt eine Security layer hinzu
- Für den TLS-Handshake wird in der Regel TCP verwendet
Worauf sich der TLS-Handshake einigt
- Der TLS-Handshake ist der Prozess, in dem Client und Server mehrere Elemente für die spätere Kommunikation abstimmen
- Zu diesen Abstimmungen gehören Gruppen von Algorithmen für Nachrichtenverifikation, Kompression und Verschlüsselung
- Diese Gruppe von Algorithmen wird als cipher suite bezeichnet
- Streng genommen gehört der compression algorithm nicht zur cipher suite, im Text wird aber die gesamte Gruppe so genannt
- Beispielhafte Bestandteile sind:
- Compression algorithm: Verfahren zur Komprimierung von Daten auf dem Wire; Beispiele sind Gzip und Brotli, heute wird meist Brotli verwendet
- Key exchange algorithm: Verfahren zum sicheren Austausch kryptografischer Schlüssel über einen öffentlichen Kanal; Beispiele sind ECDHE-RSA und ECDHE-ECDSA, heute wird vor allem ECDHE verwendet
- Authentication algorithm: Verfahren zur Authentifizierung der Kommunikationspartner während des Handshakes; Beispiele sind RSA und ECDSA, wobei RSA weit verbreitet ist und ECDSA an Popularität gewinnt
- Symmetric encryption algorithm: Verfahren zur Verschlüsselung der Daten zwischen Client und Server; Beispiele sind AES-128-GCM und AES-256-GCM, wobei AES-GCM starke Sicherheit und Effizienz bietet
- MAC algorithm: Verfahren zur Sicherung von Integrität und Echtheit einer Nachricht; Beispiele sind HMAC-SHA256 und HMAC-SHA384, verwendet werden HMAC-SHA256 sowie der GCM-Modus moderner cipher suites
- Client und Server können sich auf eine cipher suite einigen und Random-Seed- sowie SSL-certificate-Informationen austauschen, um einen symmetrischen Schlüssel für Nachrichtenverschlüsselung und -verifikation zu erzeugen
- Quelle für das Material zum TLS-Handshake ist Cloudflare
Schritte des bisherigen TLS-Handshakes
-
Client Hello
- Der Client sendet eine TCP-Nachricht an den Server, die die unterstützten cipher suites, die unterstützte TLS version und eine Zufallszahl namens Client Random enthält
-
Server Hello
- Der Server antwortet mit einer TCP-Nachricht, die die gewählte TLS version, den ausgewählten cipher-suite-Algorithmus und den Server Random enthält
-
Certificate Verification
- Der Client verifiziert über eine Certificate Authority das SSL certificate des Servers und erhält den public key des Servers
-
Premaster Secret Generation
- Der Client erzeugt ein premaster secret, verschlüsselt es mit dem public key des Servers und sendet es an den Server
-
Decryption
- Der Server entschlüsselt das premaster secret mit seinem private key
-
Session Key Creation
- Client und Server erzeugen aus Client Random, Server Random und premaster secret den session key
-
Client Ready
- Der Client sendet eine mit dem session key verschlüsselte
finished-Nachricht
-
Server Ready
- Der Server sendet eine mit dem session key verschlüsselte
finished-Nachricht
-
Secure HTTP Communication
- Danach kommunizieren beide Seiten mit sicherer symmetrischer Verschlüsselung unter Verwendung des session key
Was sich in TLS 1.3 geändert hat
- Der zuvor beschriebene TLS-Handshake bezieht sich auf ältere TLS-Versionen und ist nach aktuellem Stand von TLS 1.3 ein veralteter Ablauf
- TLS 1.3 und höher unterstützen RSA und viele cipher suites aus Sicherheitsgründen nicht mehr
- Moderne Versionen reduzieren die Auswahl stark und sind dadurch einfacher, sicherer und schneller
- Auch in TLS 1.3 bleiben die Grundkonzepte erhalten
- Über den Handshake werden Kompressionsverfahren, Serverauthentifizierung und Schlüsselaustausch abgestimmt
- Es wird ein symmetrischer Verschlüsselungsschlüssel erzeugt, um die über TCP ausgetauschten Paketdaten zu schützen
- TLS 1.3 unterstützt keine cipher suites und Parameter mehr, die anfällig für Angriffe sind, und verkürzt den Handshake zu einem schnelleren und sichereren Ablauf
-
Grundlegende Schritte des TLS-1.3-Handshakes
- Client hello: Der Client sendet Protokollversion, Client Random und eine Liste von cipher suites
- In TLS 1.3 wurde die Unterstützung unsicherer cipher suites entfernt, wodurch die Zahl möglicher cipher suites stark gesunken ist
- Client hello enthält außerdem die Parameter zur Berechnung des premaster secret
- Es wird angenommen, dass der Client die vom Server bevorzugte key exchange method kennt, was durch die verkleinerte Liste möglicher cipher suites wahrscheinlicher ist
- Diese Struktur verkürzt die Gesamtlänge gegenüber TLS-1.0-, 1.1- und 1.2-Handshakes
- Server generates master secret: Der Server hat Client Random, Client-Parameter und cipher suite bereits erhalten und kann, da er Server Random selbst erzeugt, den master secret bilden
- Server hello and
Finished: Server hello enthält das Server-certificate, die digital signature, Server Random und die ausgewählte cipher suite
- Da der Server den master secret bereits besitzt, sendet er auch direkt die
Finished-Nachricht mit
- Final steps and client
Finished: Der Client verifiziert Signatur und certificate, erzeugt den master secret und sendet anschließend die Finished-Nachricht
- Secure symmetric encryption achieved: Danach ist sichere symmetrische Verschlüsselung hergestellt
1 Kommentare
Meinungen auf Hacker News
Als Nichtfachmann frage ich mich, warum es so schwer ist herauszufinden, an welcher Stelle die Störung liegt, wenn eine bestimmte Website oder das Internet insgesamt nicht erreichbar ist.
Oft ist unklar, ob es ein Fehler in den Netzwerkeinstellungen meines lokalen Rechners ist, ein Problem mit der Wi‑Fi-Verbindung bis zum Router, ein Kabelproblem zwischen Router und ISP, eine großflächige Störung beim ISP oder eine Störung der Website, die ich aufrufen möchte.
Ich habe die vage Erklärung gehört, dass Requests über nichtdeterministische Pfade geroutet werden, aber besonders überzeugend ist das nicht. Wenn ein Link auf dem Weg ausfällt, warum kann dann nicht der letzte noch funktionierende Link zurückmelden: „Deine Nachricht ist bis hierher gekommen, aber beim Weiterleiten zum nächsten Schritt ist es fehlgeschlagen“?
Konfigurationen unterscheiden sich stark, man kann nicht wissen, welche Konfiguration beabsichtigt ist, und es ist riskant, auf Basis häufiger Ursachen Annahmen zu treffen und dann eine völlig falsche Antwort zu präsentieren.
Wenn zum Beispiel weder der DNS-Server noch der Zielhost antwortet, könnte man sagen, es handle sich um eine Fehlkonfiguration des Routers oder eine ISP-Störung. Die tatsächliche Ursache könnte aber sein, dass ein VPN-Client die lokale Routingtabelle und die DNS-Server geändert hat und sie beim Beenden nicht wieder zurückgesetzt hat. Das Problem ist: Woher soll ein Diagnoseprogramm wissen, ob es sich um eine temporäre Änderung oder eine dauerhafte Einstellung handelt?
Anwendungen sehen ICMP-Nachrichten nicht, wenn sie den Socket nicht entsprechend konfigurieren. Solche Dinge werden als „temporäre“ Fehler behandelt; unter Linux stellt man das mit der Socket-Option
IP_RECVERRein.Wenn man auf Layer 7 arbeitet, bringt es nicht viel, Fehler dieser Schicht zu sammeln. Destination-Unreachable-Fehler, die nach oben durchgereicht werden, passen ohnehin in die Fehlerbehandlungslogik, die man bereits haben wird; in diesem Fall versuchen andere Schichten bei unerreichbaren Zielen erneut zu senden, sodass es vermutlich wie ein Timeout aussieht.
Diese RFCs helfen dabei zu verstehen, wie die TCP-Schicht ICMP-Fehler behandelt: https://www.rfc-editor.org/rfc/rfc1122#page-103
In 4.2.3.9 steht, dass Unreachable-Nachrichten eine Soft-Error-Bedingung sind, TCP die Verbindung daher nicht abbrechen darf und die Information der Anwendung bereitstellen soll. TCP kann sie über die ERROR_REPORT-Routine an die Anwendungsschicht weiterreichen oder die Nachricht protokollieren und sie der Anwendung erst melden, wenn die TCP-Verbindung per Timeout ausläuft.
Es gibt auch ein Dokument, das ausführlicher behandelt, wie Stacks miteinander interagieren, um ICMP als TCP-Angriffsvektor zu untersuchen: https://www.rfc-editor.org/rfc/rfc5927
Wenn der DNS-Server selbst nicht erreichbar ist, liegt irgendwo zwischen dem Nutzer und diesem Server ein Netzwerkfehler vor. Üblicherweise diagnostiziert man das, indem man die Schritte selbst durchgeht: Kann man die DNS-Server-Adresse anpingen, kann man über diesen DNS-Server den betreffenden Host auflösen, und wie sieht es bei anderen DNS-Servern aus? Wegen Unternehmensrichtlinien können bestimmte Namen auch ausgeschlossen sein.
Wenn man tiefer einsteigen möchte, sind Kommandozeilen-Tools wie
ping,tracerouteunddignützlich.MTR ist wie ein kontinuierlich in Echtzeit laufendes ping + traceroute, bei dem jeder Hop separat angezeigt wird.
Als ich zum ersten Mal bemerkte, dass ein Knoten im Xfinity-Netz ausgefallen war, war es ebenfalls konsistent: In demselben MTR konnte ich sehen, dass zumindest von meinem Netzwerk bis zum Modem alles in Ordnung war. Ich habe nicht viele Tools gesehen, die so gut wie MTR zeigen, wenn bei irgendeinem Hop jenseits des ISP die Latenz um Hunderte Millisekunden ansteigt.
Es löst nicht alle Probleme, aber weil es die Latenz nach Hop aufschlüsselt, ist es einen Blick wert.
Um zu sagen „hier liegt das Problem“, braucht man Annahmen darüber, wie Betriebssystem, Hardware und Netzwerk konfiguriert sind.
Wenn man eine Website aufruft, muss man zuerst per DNS die IP-Adresse des Webservers bekommen, aber schon die Frage, woher der Browser die DNS-IP bezieht, ist komplex. Sie kann im Browser, im Betriebssystem, im Router oder im Modem konfiguriert sein; wenn sie nicht konfiguriert ist, bekommt der Router sie von dem DHCP-Server, mit dem er verbunden ist. Das kann der DHCP-Server des ISP sein oder ein anderer Router innerhalb einer Organisation.
Wenn DNS merkwürdig aussieht, ist leicht zu erkennen, dass die IP falsch ist, aber schwer zu sagen, woher diese IP kam. Bei SSL kann das Serverzertifikat falsch sein, oder das Zertifikat auf meinem Computer kann falsch sein.
Möglicherweise relevant: Es gibt auch interaktive Beispiele, die TLSv1.2 und TLSv1.3 Byte für Byte detailliert durchgehen.
Wenn man mehr über TLS lernen möchte, empfehle ich diese Materialien sehr; sie gehören zu meinen Favoriten.
[0]: https://tls12.xargs.org/
[1]: https://tls13.xargs.org/
Ich frage mich, ob es weitere Beispiele für Texte gibt, die aus dieser Perspektive geschrieben sind. Unabhängig vom Erfahrungsniveau mag ich Texte, die etwas „so erklären, als würde man es einem mittelmäßigen Engineer erklären“.
Meistens sind sie sehr nützlich, weil man dabei Teile neu lernt, die einem noch nicht völlig klar waren, oder mehr Beispiele bekommt, die man nutzen kann, wenn man es anderen erklärt.
Beispiele:
https://www.cloudflare.com/learning/dns/what-is-dns/
https://www.cloudflare.com/learning/ssl/transport-layer-secu...
https://www.cloudflare.com/learning/performance/what-is-http...
Die Erklärung „Der Client erzeugt ein Premaster Secret, verschlüsselt es mit dem öffentlichen Schlüssel des Servers und sendet es an den Server“ ist schon seit Langem nicht mehr korrekt.
Es wird ergänzt, dass der gerade beschriebene Ablauf im Vergleich zu modernem TLS 1.3 der Ablauf früher TLS-Versionen ist.
Die Aussage „Aktuelle TLS-Versionen (>1.3) unterstützen aus Sicherheitsgründen RSA und mehrere Cipher Suites nicht“ stimmt im Bereich des Schlüsselaustauschs. RSA bietet nämlich keine Forward Secrecy.
Für Signaturen wird RSA weiterhin verwendet und ist vermutlich die am weitesten verbreitete Art in x509-Zertifikaten.
Soweit ich weiß, hat Safari vor Kurzem auch die Anforderung an 2048-Bit-Schlüssel für RSA-Signaturen angehoben.
Dieser Text liest sich, als hätte eine KI einen eigentlichen HTTPS-Erklärungstext zusammengefasst. Begriffe tauchen ohne Kontext auf.
Es wird nicht erklärt, was ein Zertifikat ist oder wie die Vertrauenskette funktioniert, und es wird angenommen, dass die Leser Public-Key-Kryptografie kennen. Von den 7 OSI-Schichten werden 6 erklärt, ohne den Begriff selbst zu nennen, und die Darstellungsschicht fehlt.
Natürlich steht schon im Titel „mediocre“.
Schreiben ist nicht meine Stärke, daher nehme ich Kritik dankbar an. Dass mein Text von „schlecht“ zu „ist das KI?“ gekommen ist, ist ein Fortschritt.
Ich habe überlegt, wo ich die Erklärung abschneiden soll, und Public-Key-Kryptografie erschien mir als gute Grenze, weil sie anderswo besser erklärt werden kann. Bei den OSI-Schichten war es ähnlich.
Ich gebe zu, dass ich Zertifikate und vielleicht die gesamte Vertrauenskette hätte behandeln sollen.
Ich finde keinen Code, der die Signaturprüfung von
SHA256(client_hello_random + server_hello_random + curve_info + public_key)zeigt.Die Theorie kenne ich, aber bei der Umsetzung läuft irgendetwas schief. Ein Link zu einem Toy-Programm, das zeigt, wie man das tatsächlich macht, wäre hilfreich.
Bitte nicht solche Formulierungen wie „Im SSL-Zertifikat des Servers steckt der private Schlüssel“. Gut, der Titel lautet immerhin „Mediocre Engineer“.
TLS <1.3 funktioniert auch nicht so, wie es im Text beschrieben wird, und gleichzeitig versucht der Text, neuere Elemente aus 1.3 hineinzumischen. Der DNS-Teil erklärt rekursive Resolver, aber der Client macht das nicht so, sondern kommuniziert vermutlich mit einem Stub-Resolver.
Es tauchen ständig Fehler auf wie „Internet Layer“, die Andeutung, brotli sei ein verbreiteter Algorithmus für TLS-Kompression oder Cipher Suites, oder „Aktuelle TLS-Versionen (>1.3) unterstützen RSA nicht“.
Wegen solchem Blogspam wünsche ich mir manchmal einen Downvote-Button. Die Werbung ist nicht störend genug, um sie zu flaggen, aber das Niveau ist niedrig. Vielleicht sollte ich lieber selbst einen weniger mittelmäßigen Text schreiben und ihn auf die HN-Startseite bringen. Wenn ich $300K Gehalt bekäme, hätte ich mehr Zeit dafür.
Der Inhalt des Textes ist insgesamt etwas veraltet. Heutzutage laufen 30% der Web-Requests über HTTP/3, und CORS gibt es auch; ein Veröffentlichungsdatum fehlt.
Ich entwickle normalerweise SaaS-Systeme, die innerhalb von Unternehmensnetzwerken bereitgestellt werden, und CORS-Requests liegen dabei nahezu bei 0%. HTTP/3 genauso.