TLS en QUIC analyseren dataverkeer

Het is goed voor de privésfeer, maar slecht voor het verkeerbeheer: steeds meer internettoepassingen gebruiken versleutelde protocollen.

Het aandeel aan versleutelde internetverbindingen wordt nog altijd groter, want het is nou eenmaal niet wenselijk dat buitenstaanders mee kunnen lezen.

Wat goed is voor het behoud van de privésfeer, is echter hinderlijk voor de verkeersleiding: netwerkbeheerders klagen erover dat ze niet weten hoe ze met versleuteld dataverkeer de gewenste dienstkwaliteit kunnen garanderen.

Bij niet-versleutelde pakketten gaat dat als volgt: de router van een provider kan bijvoorbeeld browsercommando’s als ‘HTTP GET’ gebruiken om op het bijbehorende antwoord van een webserver te wachten.

Als daar een MIME-type-optie in zit met de toevoeging ‘application/octet-stream’, dan gaat het waarschijnlijk om een download.

Downloads zijn niet tijdskritiek, zodat de router die bij druk netwerkverkeer wat kan vertragen om de rest voorrang te geven.

Staat in het MIME-type daarentegen ‘video/mp4’, dan gaat het om een videostream. Daar geeft de router bij grote drukte prioriteit aan om haperingen bij het afspelen te voorkomen.

Ook exploitanten van grote webservers profiteren van niet-versleutelde protocollen. Daarmee kunnen ze bijvoorbeeld op een enkel ip-adres veel domeinen en websites aanbieden (virtuele hosting).

Voorgeschakelde load-balancers analyseren de leesbare tekst-requests van de browsers en sturen die meteen door naar de aangevraagde website. Daarvoor geeft de client aan de server bij het maken van de verbinding de HTTP-host mee.

Op basis van die waarde weet de load-balancer welke server bedoeld wordt en de server weet welke website geleverd moet worden.

En omdat browsers niet kunnen weten of een server meer dan één website beschikbaar stelt, sturen ze de HTTP-host-informatie altijd mee.

Dat schrijft de HTTP 1.1-specificatie ook voor.

Daar kun je bij het analyseren van TLS-verbindingen gebruik van maken. Dat komt doordat websites individuele certificaten gebruiken en de server moet weten welk certificaat hij naar de browser moet sturen.

Daarvoor gebruikt TLS in het eerste clientpakket (client_hello, CHLO) de Server Name Indication (SNI). Daarin staat de HTTP-host als leesbare tekst.

Op die manier kun je ook de SNI benutten om meerdere servers, die met TLS versleutelde websites moeten leveren, achter en load-balancer te zetten.

Netwerkbeheerders kunnen de HTTP-host in ieder geval gebruiken om sommige TCP-streams te onderscheiden.

Als een browser bijvoorbeeld een YouTube-domein opvraagt, zal de server vermoedelijk een video terug leveren, zodat de beheerder de bijbehorende stream een hogere prioriteit kan geven.

Ook bij het nieuwe, door Google in gang gezette transportprotocol QUIC bestaat die mogelijkheid. QUIC-clients communiceren met de server via UDP. De overdracht is gedefinieerd door het doel-ip-adres en het poortnummer.

Daar kan QUIC meerdere logische verbindingen naartoe opbouwen. Die komen overeen met afzonderlijke TCP-verbindingen met flow-controle en foutcorrectie.

Bij de onderhandeling krijgt elke verbinding een individuele, meestal 16-bit lange connection-ID.

Via die logische verbindingen kunnen client en server meerdere HTTP-requests tegelijkertijd verzenden en beantwoorden – op die manier worden websites merkbaar sneller geladen. Waarom dat zo is, staat in het kader hieronder.

Googles uitgangspunten voor QUIC

Websites bestaan uit veel kleine elementen (zoals afbeeldingen, CSS-bestanden, scripts), die allemaal apart en vaak van verschillende servers geladen moeten worden.

Omdat elke afzonderlijke toegang tijd kost (het opbouwen van een TCP-verbinding, het versturen van het HTTP-request, het wachten op het antwoord), wil je eigenlijk alle HTTP-requests tegelijkertijd kunnen versturen.

Dat idee zit bijvoorbeeld in HTTP 2.0. Maar HTTP 2.0 is bij het opbouwen van TLS-verbindingen net zo langzaam als HTTP 1.1 en net zo gevoelig voor overdrachtsfouten.

Als je namelijk meerdere logische HTTP-verbindingen via één TCP-verbinding afhandelt, is dat vanuit het oogpunt van TCP dan een enkele datastroom.

Problemen en oplossingen

Als er dan een overdrachtsfout optreedt, vraagt de TCP-stack van de client het gemiste pakket opnieuw bij de server op. Het duurt dan even voor die aangekomen is. In de tussentijd komen er wel andere pakketten binnen.

Die kan de TCP-stack van de client echter pas aan de browser doorgeven als ook het opnieuw opgevraagde pakket aangekomen is. Dat remt alle logische HTTP-verbindingen af (head-of-line blocking).

Een oplossing is dan om voor elke HTTP-verbinding een eigen TCP-verbinding op te bouwen. Maar dat kost resources bij de server.

Daarom wil Google alle problemen met een nieuw protocol oplossen: het opbouwen van alle overdrachtslagen moet in één keer gebeuren (verbinding, versleuteling, HTTP), plus end-to-end-versleuteling en meerdere van elkaar onafhankelijke logische HTTP-verbindingen.

QUIC combineert in essentie eigenschappen van TCP, TLS en HTTP tot één transportlaag voor HTTP. Voor HTTP-requests en -responses gebruikt QUIC dan afzonderlijke streams.

Ook QUIC stuurt aan het begin van een overdracht een Client-Hello-datablok (CHLO). Dat bevat wederom de Server Name Indication (SNI). Daarmee kan de server het juiste certificaat leveren.

Bovendien heeft hij de SNI nodig voor ‘server pushes’. Daarmee worden data bedoeld die de server ongevraagd stuurt (onderdeel van de HTTP 2.0-specificatie).

Zonder de SNI zou een server bij een virtual-host-configuratie niet weten welke push-data hij moet gaan leveren.

De eerste byte van een CHLO bevat flags met informatie over de lengte van de connection-ID en het ‘packet number’. Boven­dien laat een flag weten of het veld van de QUIC-protocolversie aanwezig is.

Omdat QUIC veel opties eerst afstemt als het versienummer van de andere kant bekend is, kun je er vanuit gaan dat dit in het eerste blok altijd meegestuurd wordt. Of anders gezegd: zonder versieveld moet je het blok niet als QUIC beschouwen.

Het door Google ontwikkelde QUIC-protocol laat nog minder zien dan TLS. Met wat knowhow kun je in de data echter de Server Name Indication vinden.

Daarna volgen 12 hash-bytes en 1 frame-type-byte. Bits 0 tot en met 4 geven de lengte van de stream-ID en de stream-offset aan. Daarna volgt de vier bytes lange CHLO. Als je die tegenkomt, kun je het data­blok met hoge waarschijnlijkheid als QUIC beschouwen.

Vier bytes later volgt een lijst van optionele, telkens vier bytes lange extra informatie. Die geven aan om wat voor type het gaat en op welke offset in het client-hello-blok die informatie staat. Zoek daar naar S, N, I en 0 – daarmee wordt de Server Name Indication bedoeld.

Google gebruikt QUIC al een tijdje, ook al is de specificatie nog niet klaar. Ook de ontwikkelaars is het duidelijk dat in de SNI meta­data zitten die door derden voor stiekeme analyses gebruikt kunnen worden.

Daarom discussiëren ze er op dit moment over of de SNI afgeschaft moet worden of niet. Een tegenargument is echter dat de IPv4-adresruimte wel erg krap wordt, maar het alternatieve IPv6 aan de andere kant nog niet wijd verspreid genoeg is.

Daarom zou het weglaten van de SNI beheerders van virtuele servers duur komen te staan – als ze dan überhaupt nog genoeg IPv4-adressen voor hun infrastructuur zouden kunnen krijgen.

(Martin Winkler, Noud van Kruysbergen)