SSTP och SSL 3.0: etiketten mot den förhandlade versionen

Två personer kan titta på samma SSTP-driftsättning och dra motsatta slutsatser. Den ena läser produktdokumentationen, ser bokstäverna SSL och antar att tunneln kör ett protokoll som avvecklades för år sedan. Den andra pekar på en modern handskakning och slår fast att frågan är stängd. Båda argumenterar utifrån etiketter och inte utifrån den förhandlade versionen, och bara en av dem är bevis. Jämförelsen som är värd att göra är mellan vad namnet lovar och vad tjänsten faktiskt väljer.

Två svar på samma fråga

Etikettargumentet är lätt att formulera: SSTP beskrivs som ett säkert socket-tunnelprotokoll, det historiska namnet säger SSL, alltså måste anslutningen vara SSL 3.0. Det överlever eftersom namnet verkligen kommer från den linjen och eftersom de flesta som upprepar det aldrig har tittat på en handskakning. Det överlever också eftersom slutsatsen låter försiktig, som om att anta det värsta vore det säkra valet. Att anta det värsta och att mäta den faktiska versionen är två olika aktiviteter, och bara en av dem ändrar något.

Bevisargumentet ställer en snävare fråga. Vilken protokollversion kom den här klienten och den här servern överens om, vid den här ändpunkten, vid den här tidpunkten? Svaret kommer från tjänsten som avslutar TLS, inte från en marknadsföringssida eller en webbläsare som nådde en webbplats med liknande namn.

De två argumenten skiljer sig i vad de kan bevisa. Etiketten kan inte skilja en gammal driftsättning från en patchad, och handskakningen kan inte berätta vad en orelaterad tjänst på samma värd gör. Använd det andra och sluta använda det första.

Läs den version som tjänsten faktiskt väljer

Börja med att namnge komponenterna: klientimplementeringen, serverimplementeringen, TLS-ändpunkten och allt däremellan som avslutar och återupprättar TLS. En lastbalanserare som avslutar TLS och talar vanlig HTTP med backend ändrar vilken enhets policy du behöver läsa.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Anteckna ändpunkten och tiden bredvid resultatet, eftersom en senare policyändring gör en odaterad observation värdelös. Upprepa provet från en klient på samma nätverksväg som de användare du bryr dig om, eftersom en avlyssningsenhet kan avsluta TLS med sina egna inställningar. Om de två positionerna inte stämmer överens har du hittat komponenten som spelar roll. Om de stämmer överens har du bevis i stället för en slogan.

Skilj postfältet från förhandlingen

Ett ålderdomligt versionsnummer i ett fält är inte samma faktum som en SSL 3.0-session. RFC 7568 behandlar postlagrets version och det förhandlade protokollet som skilda frågor, och det är just ur den distinktionen självsäkra felaktiga svar kommer. Läs det förhandlade protokollet, sedan chiffret och först därefter dra en slutsats om sessionen.

Samma dokument är entydigt om själva protokollet: SSL 3.0 får inte användas, och förhandling eller återgång till det är förbjuden. Skälet är den trasiga CBC-konstruktion som POODLE-attacken utnyttjade, och det är en egenskap hos protokollet och inte hos en enskild applikations konfiguration.

Därför är „den här arbetsbelastningen är förmodligen svår att utnyttja” inte ett argument för att låta SSL 3.0 vara aktiverat. Kravet är att ta bort protokollet, inte att vinna en debatt om en enda demonstration.

Avveckla SSL 3.0 med en policy du kan stå för

I Windows ligger Schannels protokollinställningar under nyckeln Protocols och läses separat för klient- och serverroll, vilket är varför en ändring som lagar en riktning kan lämna den andra orörd. De nuvarande inställningarna och deras omstartsbehov dokumenteras av Microsoft, och ett tredjeparts TLS-bibliotek på samma värd ignorerar dem helt.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Ändra policyn via den stödda administrationsvägen, bekräfta att den ägande tjänsten hämtar sin konfiguration igen och behåll en godkänd väg tillbaka. Att klistra in ett brett register skript från en annan miljö är hur en åtgärd för en tjänst blir ett avbrott för varje TLS-klient på maskinen. Omstartens omfattning spelar roll här: en inställning som ser tillämpad ut kan fortfarande hållas i minnet av en tjänst som inte har laddat om den.

En motpart som fortfarande kräver en föråldrad version behöver en uppdatering eller en migreringsplan. Ett odokumenterat undantag som tyst återställer det gamla protokollet är inte en kompatibilitetsstrategi och överlever inte nästa revision.

Acceptera ändringen med nya anslutningar

Testa med nya sessioner efter policyändringen, eftersom en anslutning som upprättades före ändringen inte bevisar något om den konfiguration som nu gäller. Bekräfta att det tillåtna protokollet lyckas och att det förbjudna misslyckas i den auktoriserade valideringsprocessen, och lämna sedan certifikatidentitet och förtroendekontroller exakt som de var.

Kom ihåg vad handskakningen inte täcker. SSTP bär PPP-autentisering efter TLS-lagret, så en modern protokollversion säger inget om vilken användare som auktoriserades eller vilka resurser sessionen kan nå. Det är separata kontroller med separata bevis.

Skriv ned resultatet som tjänst, backend, tillåten policy och observerad version. Ett sådant protokoll svarar exakt på säkerhetsfrågan, vilket varken etikettargumentet eller ett argument om besvär någonsin gör.