SSTP og SSL 3.0: etiketten mot den forhandlede versjonen

To personer kan se på samme SSTP-utrulling og komme til motsatte konklusjoner. Den ene leser produktdokumentasjonen, ser bokstavene SSL og antar at tunnelen kjører en protokoll som ble avviklet for år siden. Den andre peker på et moderne håndtrykk og konkluderer med at spørsmålet er lukket. Begge argumenterer ut fra etiketter og ikke ut fra den forhandlede versjonen, og bare én av dem er bevis. Sammenligningen som er verdt å gjøre, er mellom det navnet lover og det tjenesten faktisk velger.

To svar på samme spørsmål

Etikettargumentet er lett å formulere: SSTP beskrives som en sikker socket-tunnelprotokoll, det historiske navnet sier SSL, altså må forbindelsen være SSL 3.0. Det overlever fordi navnet virkelig stammer fra den linjen, og fordi de fleste som gjentar det aldri har sett på et håndtrykk. Det overlever også fordi konklusjonen høres forsiktig ut, som om det å anta det verste var det trygge valget. Å anta det verste og å måle den faktiske versjonen er to forskjellige aktiviteter, og bare én av dem endrer noe.

Bevisargumentet stiller et snevrere spørsmål. Hvilken protokollversjon ble denne klienten og denne serveren enige om, på dette endepunktet, på dette tidspunktet? Svaret kommer fra tjenesten som avslutter TLS, ikke fra en markedsføringsside eller en nettleser som nådde et nettsted med lignende navn.

De to argumentene skiller seg i hva de kan bevise. Etiketten kan ikke skille en gammel utrulling fra en patchet, og håndtrykket kan ikke fortelle hva en urelatert tjeneste på samme vert gjør. Bruk det andre og slutt å bruke det første.

Les versjonen tjenesten faktisk velger

Begynn med å navngi komponentene: klientimplementasjonen, serverimplementasjonen, TLS-endepunktet og alt imellom som avslutter og gjenoppretter TLS. En lastbalanserer som avslutter TLS og snakker vanlig HTTP med backend, endrer hvilken enhets policy du må lese.

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

Noter endepunktet og tidspunktet ved siden av resultatet, fordi en senere policyendring gjør en udatert observasjon verdiløs. Gjenta undersøkelsen fra en klient på samme nettverksvei som brukerne du bryr deg om, siden en avlyttingsenhet kan avslutte TLS med egne innstillinger. Hvis de to posisjonene ikke stemmer, har du funnet komponenten som betyr noe. Hvis de stemmer, har du bevis i stedet for et slagord.

Skille postfeltet fra forhandlingen

Et gammeldags versjonsnummer i ett felt er ikke samme faktum som en SSL 3.0-økt. RFC 7568 behandler postlagets versjon og den forhandlede protokollen som atskilte spørsmål, og det er nettopp av den forskjellen selvsikre feil svar oppstår. Les den forhandlede protokollen, deretter chifferet, og først da trekk en konklusjon om økten.

Samme dokument er entydig om selve protokollen: SSL 3.0 må ikke brukes, og forhandling eller tilbakefall til den er forbudt. Årsaken er den ødelagte CBC-konstruksjonen som POODLE-angrepet utnyttet, og det er en egenskap ved protokollen, ikke ved én applikasjons konfigurasjon.

Derfor er „denne arbeidsbelastningen er trolig vanskelig å utnytte” ikke et argument for å la SSL 3.0 være aktivert. Kravet er å fjerne protokollen, ikke å vinne en debatt om én demonstrasjon.

Avvikle SSL 3.0 med en policy du kan stå for

I Windows ligger Schannels protokollinnstillinger under nøkkelen Protocols og leses separat for klient- og serverrolle, og derfor kan en endring som reparerer én retning la den andre være urørt. De gjeldende innstillingene og deres omstartskrav er dokumentert av Microsoft, og et tredjeparts TLS-bibliotek på samme vert ignorerer dem fullstendig.

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

Endre policyen via den støttede administrasjonsveien, bekreft at den eide tjenesten henter konfigurasjonen sin på nytt, og behold en godkjent vei tilbake. Å lime inn et bredt register skript fra et annet miljø er måten en rettelse av én tjeneste blir et avbrudd for hver TLS-klient på maskinen. Omfanget av omstarten betyr noe her: en innstilling som ser anvendt ut, kan fortsatt holdes i minnet av en tjeneste som ikke har lastet den inn på nytt.

En motpart som fortsatt krever en utdatert versjon, trenger en oppdatering eller en migreringsplan. Et udokumentert unntak som stille gjenoppretter den gamle protokollen, er ikke en kompatibilitetsstrategi og overlever ikke neste revisjon.

Godta endringen med nye tilkoblinger

Test med nye økter etter policyendringen, fordi en tilkobling som ble opprettet før endringen, ikke beviser noe om konfigurasjonen som nå gjelder. Bekreft at den tillatte protokollen lykkes og at den forbudte feiler gjennom den autoriserte valideringsprosessen, og la deretter sertifikatidentitet og tillitskontroller være nøyaktig som de var.

Husk hva håndtrykket ikke dekker. SSTP bærer PPP-autentisering etter TLS-laget, så en moderne protokollversjon sier ingenting om hvilken bruker som ble autorisert, eller hvilke ressurser økten kan nå. Det er separate kontroller med separate bevis.

Skriv ned resultatet som tjeneste, backend, tillatt policy og observert versjon. En slik registrering svarer presist på sikkerhetsspørsmålet, noe verken etikettargumentet eller et argument om bryderi noen gang gjør.