TLS 1.3 stuurt de servernaam nog steeds onversleuteld mee

Een listener naar TLS 1.3 bijwerken verandert wat een waarnemer kan lezen, maar niet zo veel als het versienummer suggereert. De ClientHello reist nog steeds voordat er versleuteling is onderhandeld, en in een gewone verbinding staat de gevraagde servernaam daar in platte tekst. Encrypted Client Hello is het mechanisme dat die naam verbergt, en het is een aparte uitrol met eigen voorwaarden. Voer deze vier stappen uit voordat u een beleid schrijft dat een van beide gedragingen aanneemt.

Wat de handshake werkelijk prijsgeeft

TLS 1.3 versleutelt het certificaat van de server en het grootste deel van de handshake na de ServerHello. Alles wat de client als eerste stuurt, valt buiten die bescherming, omdat de sleutels nog niet bestaan. De server name indication maakt deel uit van die eerste vlucht, en daarom kan een passieve waarnemer die nog steeds lezen zonder iets te breken.

De ECH-specificatie, RFC 9849, verandert dit door een binnenste ClientHello te versleutelen voor een samenwerkende server. De buitenste handshake blijft bestaan en draagt een openbare naam die het netwerk kan zien, dus de uitrol heeft nog steeds een buitenste identiteit nodig die voor tussenliggende partijen logisch is. Die buitenste naam is het deel dat mensen missen wanneer ze verwachten dat de verbinding anoniem wordt. Het is een dekmantel, geen verborgen naam, en hij moet zich net als elke andere oplossen en authenticeren.

Niets hiervan verbergt het afleverpad. Bron- en doeladressen, poorten, pakketgroottes en timing blijven waarneembaar, en die zeggen vaak meer over wie er praat dan de naam. Naamresolutie en relaties op applicatieniveau zijn weer een andere laag, elk met een eigen zichtbaarheid.

Lees een ClientHello in plaats van iets aan te nemen

De versie in de ServerHello vertelt u niet wat de client heeft gestuurd. Bekijk de eerste vlucht rechtstreeks, vanaf een positie die de waarnemer vertegenwoordigt die u belangrijk vindt.

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

Het eerste commando voert een handshake uit en toont de onderhandelde parameters, inclusief de protocolversie en de naam die u hebt opgevraagd. Het tweede legt de eerste pakketten van een echte verbinding vast, en het derde haalt het SNI-veld uit die opname. Als het veld gevuld is, kan de waarnemer die u nabootste het lezen.

Leg apart vast aan de clientkant en op het pad wanneer de twee het oneens zijn, want een lokale opname kan een naam tonen die een middlebox later herschrijft of laat vallen. Leg ook vast vanaf een host die TLS niet zelf beëindigt, omdat een beëindigende proxy platte tekst ziet door zijn ontwerp en niets bewijst over wat het netwerk ziet.

Behandel een ECH-extensie als een bewering, niet als bewijs

Een ECH-extensie in een ClientHello zien betekent niet dat de verbinding ECH gebruikte. Clients sturen GREASE ECH wanneer ze geen bruikbare configuratie hebben, juist zodat hun handshakes er hetzelfde uitzien. De extensie is aanwezig, de binnenste hello is een lokmiddel, en de werkelijke naam is nog steeds leesbaar.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

Het eerste commando toont of de oorsprong een HTTPS-resource-record publiceert met een ECH-configuratieparameter, want zo leren clients de sleutel. Het tweede zoekt naar statusinformatie van de handshake, hoewel het succesbericht van een client het sterkere bewijs is. Acceptatie is wat telt: een server die niet de bijpassende sleutel heeft, kan de binnenste hello niet ontsleutelen, en de verbinding valt terug.

Controleer ook de client, want browserondersteuning en configuratie verschillen per versie en platform. Een beleid dat op „moderne browsers gebruiken ECH“ is gebouwd, is een gok over een vloot, geen feit over uw vloot. Inventariseer de versies die daadwerkelijk verbinden, en test er dan één van elk. Dezelfde pagina die werkt vanuit een actuele desktopbrowser verbergt misschien niets meer voor een oudere client op hetzelfde netwerk.

Schrijf het bereik van de waarnemer in het beleid

Bepaal waar de waarnemer zit en wat daar zichtbaar is voordat u besluit waarop een maatregel kan bouwen. De verbinding van een browser met een website, een buitenste VPN-transport en een TLS-beëindigende proxy leggen elk een andere set feiten bloot, en een regel die voor de ene positie is geschreven, is zelden schoon naar een andere over te dragen.

Als een maatregel afhangt van het lezen van SNI, test dan hoe de uitgerolde clients zich gedragen wanneer ECH beschikbaar is en wanneer niet. Leg daarna het compatibiliteitsgevolg vast, want een filter dat stilzwijgend stopt met matchen is erger dan een dat nooit is uitgerold.

Houd ten slotte de onzekerheid in het verslag. Een oude universele bewering door een nieuwere vervangen laat dezelfde leemte achter onder een andere protocolnaam, en de volgende beoordelaar zal er net zo stellig in geloven.