HTTP/TLS-Issues aus PCAP: L4 vs. L6 vs. L7 unterscheiden

HTTP/TLS-Issues aus PCAP sauber zu diagnostizieren ist im NOC eine der schnellsten Möglichkeiten, „alles ist langsam“ oder „nur manche Requests gehen“ in konkrete Ursachen zu übersetzen. Der entscheidende Schritt dabei ist, Probleme konsequent nach Schichten zu trennen: Layer 4 (Transport/TCP), Layer 6 (TLS als Sicherheits-/Session-Schicht) und Layer 7 (HTTP als Anwendungsprotokoll). In der Praxis werden diese Ebenen oft vermischt, weil sich die Symptome ähneln: Timeouts, sporadische Abbrüche, „Connection reset“, lange Ladezeiten oder unerwartete Fehlercodes. Eine PCAP liefert jedoch harte Fakten, wenn Sie strukturiert vorgehen: Ist der TCP-Handshake stabil? Gibt es Retransmissions, Dup ACKs oder Window-Probleme (L4)? Bricht der TLS-Handshake ab, scheitert die Zertifikatsprüfung, oder ist ALPN/SNI nicht passend (L6)? Oder kommt HTTP korrekt zustande, aber die Anwendung antwortet langsam oder mit 4xx/5xx (L7)? Dieser Artikel zeigt, wie Sie in Wireshark (oder ähnlichen Tools) typische HTTP/TLS-Issues aus PCAP schnell einsortieren, welche Indikatoren pro Schicht wirklich aussagekräftig sind und wie Sie daraus einen belastbaren Befund ableiten, der für Netz-, Plattform- und Applikationsteams gleichermaßen verwertbar ist.

Warum die Schichtentrennung in PCAPs so wichtig ist

Viele Incident-Diskussionen drehen sich im Kreis, weil unklar bleibt, ob das Problem „im Netz“ oder „in der App“ liegt. Ein PCAP kann diese Debatte abkürzen, wenn Sie die Ebenen nacheinander abprüfen und dabei nur Beweise akzeptieren, die zur Ebene passen:

• L4 (TCP): Beweise sind Paketverlust, Retransmissions, Handshake-Fehler, RST/FIN-Muster, Window- und RTT-Anomalien.
• L6 (TLS): Beweise sind TLS Alert Codes, Handshake-Failure, Zertifikatskette, SNI/ALPN-Mismatch, Version/Cipher-Inkompatibilität, Abbruch an klaren TLS-Handshake-Stellen.
• L7 (HTTP): Beweise sind HTTP-Statuscodes, Header, Response-Timings, Chunking/Transfer-Encoding, Redirect-Ketten, serverseitige Fehler (5xx), clientseitige Fehler (4xx) oder Applikationslatenz bei stabilem Transport.

Wenn Sie diese Reihenfolge einhalten, vermeiden Sie zwei klassische Fehlschlüsse: „HTTP ist langsam“ (obwohl TCP gerade Retransmissions produziert) und „das Netz droppt“ (obwohl der TLS-Handshake wegen Zertifikatsproblemen abbricht).

Vorbereitung: Capture-Qualität und typische PCAP-Fallen

Bevor Sie Ebenen interpretieren, stellen Sie sicher, dass der Trace überhaupt repräsentativ ist. Viele „seltsame“ TLS-/HTTP-Probleme sind in Wahrheit Capture-Artefakte.

• Bidirektionale Sicht: Für sichere Interpretation sollten Sie beide Richtungen sehen. Einseitige Captures lassen ACK-/Retransmission-Logik und TLS-Handshake schwer bewerten.
• SPAN/ERSPAN-Drops: Oversubscription kann genau die „interessanten“ Pakete verlieren. Ein fehlender TLS Alert oder ein fehlendes HTTP Response-Paket ist dann kein Beweis.
• Offloading-Effekte: GRO/LRO/TSO können TCP-Segmente zusammenfassen und Timing/Segmentierung verfälschen.
• Time Sync: Wenn Sie Captures aus verschiedenen Punkten vergleichen (Client vs. Server), braucht es konsistente Zeitstempel oder zumindest klare Bezugspunkte.

Für das Verständnis von TCP als Transportgrundlage ist RFC 9293 (TCP) eine solide Referenz. Für TLS ist RFC 8446 (TLS 1.3) relevant, während HTTP/1.1 in RFC 9112 (HTTP/1.1) beschrieben ist.

Der NOC-Workflow: Erst L4, dann L6, dann L7

Ein effizienter Ablauf für Incidents ist eine Checkliste, die Sie bei jeder PCAP wiederholen. Das spart Zeit und liefert reproduzierbare Ergebnisse.

• 1) Flow auswählen: Ein konkreter Client↔Server-Flow, der fehlschlägt oder langsam ist.
• 2) L4 prüfen: TCP-Handshake, Retransmissions, RTT-/Window-Indikatoren.
• 3) L6 prüfen: TLS-Handshake bis „Handshake completed“, Alerts, Version/Cipher, SNI/ALPN.
• 4) L7 prüfen: HTTP Request/Response, Statuscodes, Server-TTFB, Payload-Übertragung.
• 5) Befund formulieren: „Auf Ebene X sehen wir Y; Ebene Z wirkt unauffällig.“

L4: Transportprobleme erkennen und von „höheren“ Fehlern trennen

Layer 4 ist der häufigste Grund für „wackelige“ HTTP/TLS-Symptome, weil TCP Fehler kaschiert: Retransmissions können eine Zeit lang „alles wieder gut machen“, bis die Anwendung Timeouts bekommt. In PCAPs sind L4-Probleme meist an wenigen Signalen erkennbar.

TCP-Handshake: Kommt die Verbindung sauber hoch?

• SYN ohne SYN/ACK: Timeout, Drop, falscher Pfad, Policy/Firewall oder Server nicht erreichbar.
• SYN → RST: Port geschlossen oder Middlebox resettiert (z. B. L4-ACL, WAF/LB, Firewall-Policy).
• SYN/SYN-ACK ohne abschließendes ACK: Rückwegproblem oder Client blockiert, oft bei Asymmetrie/Stateful Firewall.

Wenn der Handshake nicht stabil ist, sind spätere TLS-/HTTP-Anomalien meist Folgeeffekte. Dann ist es methodisch falsch, auf L6/L7 zu springen, bevor L4 geklärt ist.

Retransmissions und Dup ACKs: Der klassische „Netz ist nicht sauber“-Beweis

Typische Wireshark-Indikatoren sind tcp.analysis.retransmission, tcp.analysis.fast_retransmission und tcp.analysis.duplicate_ack. In PCAPs bedeutet das nicht automatisch „Link kaputt“, aber es zeigt, dass TCP Pakete erneut senden muss oder ACK-Muster auf fehlende Segmente hindeuten.

• Fast Retransmit + viele Dup ACKs: häufig echter Paketverlust oder starker Reorder.
• Retransmit nach langen Pausen: häufig RTO (Timeout), möglich bei Loss, Congestion oder CPU-/Queueing-Events.
• Out-of-Order ohne weitere Symptome: kann ECMP-Reorder sein, ist nicht immer kritisch.

Window-Probleme: Sender schnell, Empfänger langsam

Wenn der Empfänger nicht schnell genug liest oder die Anwendung blockiert, kann TCP mit Window-Mechanismen drosseln. In PCAPs sind typische Hinweise:

• Zero Window oder Window Full: Empfänger signalisiert, dass sein Buffer voll ist.
• Window Update: Empfänger öffnet das Fenster wieder; Traffic läuft in Bursts weiter.

Dieses Muster ist oft kein Netzwerkproblem, sondern ein Server-/Applikations- oder Ressourcenproblem, das sich als L4-Symptom zeigt. Der Befund lautet dann: Transport ist intakt, aber der Empfänger bremst.

L4-Zeitmessung: RTT und „Stall“-Phasen quantifizieren

Für eine einfache Zeitquantifizierung können Sie die Dauer zwischen dem ersten SYN und dem Zeitpunkt, an dem die erste Anwendungsdatenübertragung startet, betrachten. Wenn t_syn der Zeitstempel des SYN und t_data der Zeitstempel des ersten TLS ClientHello (oder ersten Payload bei Klartext-HTTP) ist, ist die Verbindungsstartzeit T:

$T=t_{\mathrm{data}}-t_{\mathrm{syn}}$

Ein ungewöhnlich großes T deutet auf Verzögerungen beim Handshake oder frühzeitige Retries hin. Für NOC-Kommunikation reicht oft: „Handshake benötigt X ms; bei Normalbetrieb sind es Y ms.“

L6: TLS-Probleme aus PCAPs lesen, ohne „Krypto“ zu studieren

TLS ist in vielen Umgebungen die Standardtransportabsicherung. Die gute Nachricht: Für NOC-Diagnosen müssen Sie keine Kryptografie implementieren. Sie müssen nur verstehen, an welcher Stelle der Handshake abbricht und welche Parameter nicht zusammenpassen.

TLS-Handshake grob einordnen: Was muss passieren?

• ClientHello: Client schlägt Versionen, Cipher Suites, Extensions vor (SNI, ALPN, Supported Groups).
• ServerHello: Server wählt Parameter aus; danach folgen Zertifikatskette und Handshake-Details (je nach TLS-Version).
• Handshake abgeschlossen: Ab dann ist Anwendungsdatenverkehr (HTTP) in TLS verschlüsselt.

Wenn Sie in der PCAP nur ClientHello sehen und danach Retransmissions oder einen Abbruch, ist das häufig ein Netz-/Pfadproblem oder ein Server/Load-Balancer, der nicht antwortet. Wenn Sie einen TLS Alert sehen, ist es oft ein L6-Thema.

TLS Alerts: Der schnellste Weg zur Ursache

Wireshark zeigt TLS Alerts häufig explizit an (z. B. „Handshake Failure“, „Bad Certificate“, „Unknown CA“). Das sind klare L6-Beweise. Typische Ursachen:

• Handshake Failure: Version/Cipher/Extensions nicht kompatibel, Policy blockt, alte Clients vs. strenge Server.
• Bad Certificate / Unknown CA: Zertifikatskette nicht vertrauenswürdig, Zwischenzertifikat fehlt, falsche CA-Policy am Client.
• Certificate Expired: abgelaufenes Zertifikat, oft plötzlich nach einem Datum.
• Access Denied: Policy-Entscheidung durch Middlebox (z. B. TLS-Inspection/WAF), abhängig von SNI oder Client-Profil.

Der entscheidende NOC-Satz lautet hier: „TCP ist stabil, TLS bricht mit Alert X ab.“ Das ist für Applikations- und Security-Teams sofort verwertbar.

SNI und Zertifikat: Passt der Name zur Verbindung?

SNI (Server Name Indication) ist eine TLS-Extension, mit der der Client dem Server mitteilt, welchen Hostnamen er erwartet. In Multi-Tenant- oder CDN-Setups entscheidet SNI darüber, welches Zertifikat und welches Backend gewählt wird. Typische L6/L7-Fehler entstehen, wenn SNI fehlt oder falsch ist:

• Falsches Zertifikat: Der Server liefert ein Default-Zertifikat, das nicht zum Host passt.
• Handshake-Abbruch: Client lehnt Zertifikat wegen Hostname-Mismatch ab.
• Unerwartetes Backend: Load Balancer routet auf falschen Service.

Die grundlegenden Konzepte von TLS (inkl. Extensions) sind in RFC 8446 (TLS 1.3) beschrieben.

ALPN: Warum HTTP/2 „plötzlich“ nicht mehr geht

ALPN (Application-Layer Protocol Negotiation) legt fest, ob HTTP/1.1 oder HTTP/2 genutzt wird. Wenn ALPN-Parameter nicht passen, kann sich Verhalten ändern: Clients fallen auf HTTP/1.1 zurück oder brechen ab, wenn nur HTTP/2 erwartet wird. Hinweise in PCAP:

• ClientHello enthält ALPN (z. B. h2, http/1.1), Server bestätigt eine Auswahl.
• Keine ALPN-Übereinkunft: In manchen Setups führt das zu Fallback, in strengen Umgebungen zu Fehlern.

Für HTTP/2-Überblick ist RFC 9113 (HTTP/2) eine hilfreiche Referenz.

TLS vs. MTU: Wenn der Handshake an „großen“ Paketen scheitert

Manche TLS-Handshake-Nachrichten (Zertifikatsketten, Extensions) sind groß. Wenn MTU/PMTUD fehlerhaft ist oder Fragmente gefiltert werden, kann TLS „zufällig“ scheitern. Typische Muster:

• ClientHello geht raus, ServerHello kommt, dann bricht es beim Zertifikatstransfer ab.
• Wiederholte Retransmissions derselben großen Segmente.
• Gleichzeitige ICMP-Meldungen („Fragmentation Needed“) fehlen oder sind gefiltert.

Das ist ein Grenzfall: Die Ursache liegt auf L4/L3 (MTU/Fragmentierung), das Symptom zeigt sich als L6-Handshake-Fail. Genau hier hilft die Ebenentrennung: L6 bricht ab, aber der Beweis für die Ursache liegt in den L4-Symptomen (Retransmits großer Segmente) plus ggf. ICMP-Indikatoren.

L7: HTTP-Probleme in PCAPs identifizieren, auch wenn TLS verschlüsselt

HTTP ist die Ebene, auf der viele Incidents „sichtbar“ werden: Fehlercodes, Redirects, leere Responses, Timeouts oder sehr langsame Antwortzeiten. Bei HTTPS ist HTTP-Inhalt ohne Entschlüsselung nicht im Klartext sichtbar, aber Sie können trotzdem viel diagnostizieren: Timing, Größen, Serververhalten und TLS-Session-Parameter. Wenn Sie entschlüsseln können (z. B. Testumgebung oder kontrollierte Schlüssel), wird HTTP-Analyse noch präziser.

HTTP-Statuscodes: Harte L7-Beweise

Wenn Sie Klartext-HTTP oder entschlüsseltes HTTPS sehen, sind Statuscodes der direkteste Befund:

• 4xx: Client-/Request-Themen (Auth, Rate Limit, falscher Pfad, Header). Netz ist oft unauffällig.
• 5xx: Serverseitige Fehler (App/Upstream, LB-Backend, Überlast). Netz kann ok sein.
• 301/302: Redirect-Ketten können Latenz verursachen oder bei Mixed Content/Policy scheitern.

Die HTTP-Semantik ist in RFC 9110 (HTTP Semantics) beschrieben. Für HTTP/1.1-Message-Format ist RFC 9112 (HTTP/1.1) relevant.

TTFB und Response-Latenz: Netzwerk vs. Server trennen

Ein extrem nützliches L7-Pattern ist „Time To First Byte“ (TTFB): Wie lange dauert es vom Request bis zum ersten Response-Byte? In PCAPs können Sie das über Zeitstempel zwischen Request-Ende und erstem Response-Segment abschätzen (bei Klartext) oder über TLS Application Data-Events (bei verschlüsselt, eingeschränkt).

Wenn t_req der Zeitpunkt ist, an dem der Client das Request-Ende gesendet hat, und t_resp der Zeitpunkt des ersten Response-Bytes, dann ist:

$\mathrm{TTFB}=t_{\mathrm{resp}}-t_{\mathrm{req}}$

Interpretation im NOC:

• Hohe TTFB bei stabilem TCP/TLS: häufig Server-/Backend-/App-Latenz (L7/L5) statt Netz.
• Hohe TTFB plus Retransmissions/RTT-Spikes: Transport/Netz beeinflusst Antwortzeit (L4).

HTTP über HTTP/2: „Alles sieht anders aus“

Bei HTTP/2 gibt es Multiplexing: mehrere Requests teilen sich eine TCP-Verbindung. Dadurch wirken klassische „ein Request = ein Flow“-Denkmuster weniger gut. In PCAPs ist das wichtig, weil ein einzelner problematischer Stream (z. B. Head-of-Line-ähnliche Effekte in der Anwendung oder Flow-Control) andere Requests beeinflussen kann. Hinweise:

• Viele parallele Streams, Frames statt klassischer Requests im Klartext.
• Flow-Control-Frames und Window-Updates können Performance begrenzen.

Wenn HTTP/2-Probleme vermutet werden, ist die ALPN-Aushandlung (L6) der erste Check: Wird wirklich h2 verwendet?

Typische Incident-Muster: So ordnen Sie PCAP-Symptome korrekt ein

Die folgenden Muster treten im NOC besonders häufig auf. Entscheidend ist jeweils, auf welcher Ebene der erste „harte“ Bruch sichtbar wird.

„Timeout“ in der Anwendung

• L4-Variante: SYN-Retries, Retransmissions, RTOs, hohe RTT/Jitter; HTTP/TLS kommen nicht stabil hoch.
• L6-Variante: TCP ok, ClientHello/ServerHello sichtbar, dann TLS Alert oder Abbruch während Zertifikat/Handshake.
• L7-Variante: TCP/TLS ok, HTTP-Requests gehen raus, aber Server antwortet spät oder gar nicht (TTFB hoch), ggf. 504/503.

„Connection reset by peer“

• L4: RST kommt vom Server oder einer Middlebox. Prüfen Sie Quell-IP des RST, Timing und ob es bei Lastspitzen gehäuft auftritt.
• L6: Manchmal wird ein TLS-Problem als RST sichtbar, wenn Appliances hart abbrechen, statt Alerts zu senden.
• L7: Selten direkt, außer Anwendung oder Proxy resettiert nach HTTP-Policy-Entscheidungen.

„Nur manche Requests sind kaputt“

• L4: ECMP/LAG-Teilpfad mit Loss; Retransmissions nur für Teilmenge der Verbindungen.
• L6: SNI/ALPN abhängig von Hostname; manche Hostnames funktionieren, andere liefern falsches Zertifikat oder falsches Backend.
• L7: Backend-spezifisch (ein Pod/Node liefert 500), sichtbar als 5xx nur für bestimmte Ziel-IP oder Zeitfenster.

„Langsam, aber kein Loss“

• L4: Kein Loss, aber hohe RTT/Jitter oder Congestion ohne Drops (Queueing); Window-Limits können sichtbar sein.
• L6: TLS-Handshake-Dauer erhöht (z. B. OCSP/Stapling-Interaktionen, Policy-Checks), ohne dass es scheitert.
• L7: TTFB hoch, Server verarbeitet langsam; HTTP-Status ggf. 200, aber Antwort spät.

Praktische Wireshark-Filter: Schnell zur relevanten Stelle im Trace

Für die Ebenentrennung helfen Display-Filter, die Sie kombinieren. Beispiele (anzupassen an IPs/Ports):

• Auf einen Flow begrenzen: ip.addr == 10.0.0.10 and ip.addr == 10.0.0.20 and tcp.port == 443
• Handshake-Fokus: tcp.flags.syn == 1 or tcp.flags.reset == 1
• Retransmissions: tcp.analysis.retransmission or tcp.analysis.fast_retransmission or tcp.analysis.duplicate_ack
• TLS allgemein: tls (oder ssl je nach Wireshark-Version/Dissektor)
• TLS Alerts: tls.alert_message (Feldverfügbarkeit abhängig von Version/Dissektor)
• HTTP Klartext: http
• HTTP Statuscodes: http.response.code >= 400

Für HTTP/2 ist http2 als Filter hilfreich, sofern der Traffic entschlüsselbar ist oder Wireshark genügend Kontext hat. Grundsätzlich gilt: Erst Flow-Scope, dann Ereignisfilter. So vermeiden Sie, dass Sie „Retransmissions irgendwo im Netz“ mit dem betroffenen Flow verwechseln.

Entscheidungslogik: Ein kurzer Response-Plan für Incident-Kommunikation

Wenn Sie aus PCAPs einen Befund ableiten, sollte er so formuliert sein, dass er nicht nur „technisch korrekt“, sondern auch handlungsorientiert ist. Ein bewährtes Schema ist:

• Beobachtung: „Im Trace sehen wir …“ (konkrete Pakete/Ereignisse, z. B. Retransmissions, TLS Alert, HTTP 503).
• Einordnung: „Das ist typisch für Ebene …“ (L4/L6/L7).
• Ausschluss: „Ebene X wirkt unauffällig, weil …“ (z. B. stabiler Handshake, keine Retransmits).
• Nächster Schritt: „Empfohlen: …“ (z. B. Interface-Counter/Queue-Drops prüfen, Zertifikatskette prüfen, Backend-Logs prüfen).

Dieses Vorgehen reduziert Schuldzuweisungen und beschleunigt die Eskalation an das richtige Team.

Outbound-Quellen für vertiefendes Verständnis

Für TCP-Grundlagen, Zustände und das Verhalten bei Retransmissions ist RFC 9293 (TCP) die zentrale Referenz. Für TLS 1.3 und moderne Handshake-Mechanik ist RFC 8446 (TLS 1.3) maßgeblich. Für HTTP-Semantik und Statuscodes ist RFC 9110 (HTTP Semantics) hilfreich, während das HTTP/1.1-Nachrichtenformat in RFC 9112 (HTTP/1.1) beschrieben ist. Für HTTP/2-Mechanik (Streams, Multiplexing) bietet RFC 9113 (HTTP/2) eine belastbare Grundlage. Für praktische Analyse-Workflows, Display-Filter und dissektorbezogene Details ist Wireshark die primäre Anlaufstelle.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.