TLS en QUIC voor traffic rerouting
TLS en QUIC analyseren het dataverkeer
Het is goed voor de privésfeer, maar slecht voor het verkeerbeheer: steeds meer internettoepassingen gebruiken versleutelde protocollen. Met enige moeite kun je sommige daarvan nog aan bepaalde diensten koppelen – maar wellicht kan dat binnenkort ook niet meer. Dat heeft gevolgen voor server- en netwerkbeheerders.
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 inzit 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 HTTPhost 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 TLSverbindingen 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 een load-balancer te zetten.
Netwerkbeheerders kunnen de HTTPhost 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.
Gerichtere verbindingen
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 TCPverbindingen 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 hierboven.
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'. Bovendien 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.
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 streamoffset aan. Daarna volgt de vier bytes lange CHLO. Als je die tegenkomt, kun je het datablok 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-helloblok die informatie staat. Zoek daar naar S, N, I en 0 – daarmee wordt de Server Name Indication bedoeld.
Pottenkijkers
Google gebruikt QUIC al een tijdje, ook al is de specificatie nog niet klaar. Ook de ontwikkelaars is het duidelijk dat in de SNI metadata 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 IPv4adressen voor hun infrastructuur zouden kunnen krijgen. (nkr)