SSTP og SSL 3.0: etiketten over for den forhandlede version

To personer kan se på samme SSTP-udrulning og nå modsatte konklusioner. Den ene læser produktdokumentationen, ser bogstaverne SSL og antager, at tunnelen kører en protokol, der blev udfaset for år siden. Den anden peger på et moderne håndtryk og konkluderer, at spørgsmålet er lukket. Begge argumenterer ud fra etiketter og ikke ud fra den forhandlede version, og kun én af dem er bevis. Sammenligningen, der er værd at lave, er mellem det, navnet lover, og det, tjenesten faktisk vælger.

To svar på det samme spørgsmål

Etiketargumentet er let at formulere: SSTP beskrives som en sikker socket-tunnelprotokol, det historiske navn siger SSL, altså skal forbindelsen være SSL 3.0. Det overlever, fordi navnet virkelig stammer fra den linje, og fordi de fleste, der gentager det, aldrig har kigget på et håndtryk. Det overlever også, fordi konklusionen lyder forsigtig, som om det at antage det værste var det sikre valg. At antage det værste og at måle den faktiske version er to forskellige aktiviteter, og kun én af dem ændrer noget.

Bevisargumentet stiller et snævrere spørgsmål. Hvilken protokolversion blev denne klient og denne server enige om, på dette endepunkt, på dette tidspunkt? Svaret kommer fra den tjeneste, der afslutter TLS, ikke fra en marketingside eller en browser, der nåede et websted med et lignende navn.

De to argumenter adskiller sig i, hvad de kan bevise. Etiketten kan ikke skelne en gammel udrulning fra en patchet, og håndtrykket kan ikke fortælle, hvad en urelateret tjeneste på samme vært laver. Brug det andet, og hold op med at bruge det første.

Læs den version, tjenesten faktisk vælger

Begynd med at navngive komponenterne: klientimplementeringen, serverimplementeringen, TLS-endepunktet og alt imellem, der afslutter og genopretter TLS. En lastbalancer, der afslutter TLS og taler almindelig HTTP med backenden, ændrer, hvilken enheds politik du skal læse.

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

Notér endepunktet og tidspunktet ved siden af resultatet, fordi en senere politikændring gør en udateret observation værdiløs. Gentag undersøgelsen fra en klient på samme netværksvej som de brugere, du bekymrer dig om, da en aflytningsenhed kan afslutte TLS med sine egne indstillinger. Hvis de to positioner ikke stemmer overens, har du fundet den komponent, der betyder noget. Hvis de stemmer overens, har du bevis i stedet for et slogan.

Adskil postfeltet fra forhandlingen

Et gammeldags versionsnummer i ét felt er ikke samme kendsgerning som en SSL 3.0-session. RFC 7568 behandler postlagets version og den forhandlede protokol som adskilte emner, og det er præcis ud af den forskel, selvsikre forkerte svar opstår. Læs den forhandlede protokol, derefter cifferet, og først derefter drag en konklusion om sessionen.

Samme dokument er entydigt om selve protokollen: SSL 3.0 må ikke bruges, og forhandling eller tilbagefald til den er forbudt. Årsagen er den brudte CBC-konstruktion, som POODLE-angrebet udnyttede, og det er en egenskab ved protokollen, ikke ved én applikations konfiguration.

Derfor er „denne arbejdsbyrde er sandsynligvis svær at udnytte” ikke et argument for at lade SSL 3.0 være aktiveret. Kravet er at fjerne protokollen, ikke at vinde en debat om én demonstration.

Udfas SSL 3.0 med en politik, du kan stå inde for

I Windows ligger Schannels protokolindstillinger under nøglen Protocols og læses separat for klient- og serverrolle, hvorfor en ændring, der retter den ene retning, kan lade den anden være urørt. De nuværende indstillinger og deres genstartsbehov er dokumenteret af Microsoft, og et tredjeparts TLS-bibliotek på samme vært ignorerer dem fuldstændigt.

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

Ændr politikken via den understøttede administrationsvej, bekræft, at den ejende tjeneste henter sin konfiguration igen, og behold en godkendt vej tilbage. At indsætte et bredt registreringsscript fra et andet miljø er måden, hvorpå en rettelse af én tjeneste bliver et afbrud for hver TLS-klient på maskinen. Genstartens omfang betyder noget her: en indstilling, der ser anvendt ud, kan stadig holdes i hukommelsen af en tjeneste, der ikke har genindlæst den.

En modpart, der stadig kræver en forældet version, har brug for en opdatering eller en migreringsplan. En udokumenteret undtagelse, der stille genskaber den gamle protokol, er ikke en kompatibilitetsstrategi og overlever ikke næste revision.

Accepter ændringen med nye forbindelser

Test med nye sessioner efter politikændringen, fordi en forbindelse, der blev oprettet før ændringen, intet beviser om den konfiguration, der nu gælder. Bekræft, at den tilladte protokol lykkes, og at den forbudte fejler gennem den autoriserede valideringsproces, og lad derefter certifikatidentitet og tillidskontroller være præcis, som de var.

Husk, hvad håndtrykket ikke dækker. SSTP bærer PPP-godkendelse efter TLS-laget, så en moderne protokolversion siger intet om, hvilken bruger der blev autoriseret, eller hvilke ressourcer sessionen kan nå. Det er separate kontroller med separate beviser.

Skriv resultatet ned som tjeneste, backend, tilladt politik og observeret version. En sådan registrering besvarer sikkerhedsspørgsmålet præcist, hvilket hverken etiketargumentet eller et argument om besvær nogensinde gør.