SSTP og SSL 3.0: etiketten mot den forhandla versjonen
Ein SSL-etikett beviser ikkje ein SSL 3.0-økt. Samanlikn den påståtte protokollen med den tenesta faktisk forhandlar seg fram til, og avvikla deretter den gamle versjonen.
To personar kan sjå på same SSTP-utrullinga og kome til motsette konklusjonar. Den eine les produktdokumentasjonen, ser bokstavane SSL og reknar med at tunnelen køyrer ein protokoll som vart avvikla for år sidan. Den andre peikar på eit moderne handtrykk og slår fast at spørsmålet er lukka. Begge argumenterer ut frå etikettar og ikkje ut frå den forhandla versjonen, og berre éin av dei er bevis. Samanlikninga som er verdt å gjere, er mellom det namnet lovar og det tenesta faktisk vel.
To svar på same spørsmålet
Etikettargumentet er lett å formulere: SSTP vert skildra som ein trygg socket-tunnelprotokoll, det historiske namnet seier SSL, altså må sambandet vere SSL 3.0. Det overlever fordi namnet verkeleg kjem frå den lina, og fordi dei fleste som gientek det aldri har sett på eit handtrykk. Det overlever òg fordi konklusjonen høyrest forsiktig ut, som om det å rekne med det verste var det trygge valet. Å rekne med det verste og å måle den faktiske versjonen er to ulike aktivitetar, og berre éin av dei endrar noko.
Bevisargumentet stiller eit snevrare spørsmål. Kva protokollversjon vart denne klienten og denne tenaren samde om, på dette endepunktet, på dette tidspunktet? Svaret kjem frå tenesta som avsluttar TLS, ikkje frå ei marknadsføringsside eller ein nettlesar som nådde eit nettstad med liknande namn.
Dei to argumenta skil seg i kva dei kan bevisa. Etiketten kan ikkje skilje ei gammal utrulling frå ei patcha, og handtrykket kan ikkje fortelje kva ei urelatert teneste på same vert gjer. Bruk det andre og slutt å bruke det første.
Les versjonen tenesta faktisk vel
Byrja med å namngje komponentane: klientimplementasjonen, tenarimplementasjonen, TLS-endepunktet og alt imellom som avsluttar og gjenopprettar TLS. Ein lastbalansar som avsluttar TLS og snakkar vanleg HTTP med backend, endrar kva eininga si 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 sida av resultatet, fordi ei seinare policyendring gjer ein udatert observasjon verdilaus. Gjenta undersøkinga frå ein klient på same nettverksvei som brukarane du bryr deg om, sidan eit avlyttingsutstyr kan avslutte TLS med eigne innstillingar. Viss dei to posisjonane ikkje stemmer, har du funne komponenten som betyr noko. Viss dei stemmer, har du bevis i staden for eit slagord.
Skil postfeltet frå forhandlinga
Eit gammaldags versjonsnummer i eitt felt er ikkje same faktum som ein SSL 3.0-økt. RFC 7568 handsamar postlaget sin versjon og den forhandla protokollen som skilde spørsmål, og det er nettopp av den forskjellen sjølvsikre feil svar oppstår. Les den forhandla protokollen, deretter sifferet, og først då trekk ein konklusjon om økta.
Same dokumentet er eintydig om sjølve protokollen: SSL 3.0 må ikkje brukast, og forhandling eller tilbakefall til han er forbode. Årsaka er den øydelagde CBC-konstruksjonen som POODLE-åtaket utnytta, og det er ein eigenskap ved protokollen, ikkje ved konfigurasjonen til éin applikasjon.
Difor er „denne arbeidslasta er truleg vanskeleg å utnytte” ikkje eit argument for å la SSL 3.0 vere aktivert. Kravet er å fjerne protokollen, ikkje å vinne ein debatt om éin demonstrasjon.
Avvikla SSL 3.0 med ein policy du kan stå for
I Windows ligg Schannel sine protokollinnstillingar under nøkkelen Protocols og vert lesne separat for klient- og tenarrolla, og difor kan ei endring som reparerer éin retning la den andre vere urørd. Dei gjeldande innstillingane og omstartskrava deira er dokumenterte av Microsoft, og eit tredjeparts TLS-bibliotek på same vert ignorerer dei 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øtta administrasjonsvegen, stadfest at den eigde tenesta hentar konfigurasjonen sin på nytt, og hald ein godkjend veg tilbake. Å lime inn eit breitt register skript frå eit anna miljø er måten ei retting av éi teneste vert eit avbrot for kvar TLS-klient på maskina. Omfanget av omstarten betyr noko her: ei innstilling som ser brukt ut, kan framleis haldast i minnet av ei teneste som ikkje har lasta ho inn på nytt.
Ein motpart som framleis krev ein utdatert versjon, treng ei oppdatering eller ein migrasjonsplan. Eit udokumentert unntak som stille gjenopprettar den gamle protokollen, er ikkje ein kompatibilitetsstrategi og overlever ikkje neste revisjon.
Godta endringa med nye tilkoplingar
Test med nye økter etter policyendringa, fordi ei tilkopling som vart oppretta før endringa, ikkje beviser noko om konfigurasjonen som no gjeld. Stadfest at den tillatne protokollen lukkast og at den forbodne feilar gjennom den autoriserte valideringsprosessen, og la deretter sertifikatidentitet og tillitskontrollar vere nøyaktig som dei var.
Hugs kva handtrykket ikkje dekkjer. SSTP ber PPP-autentisering etter TLS-laget, så ein moderne protokollversjon seier ingenting om kva brukar som vart autorisert, eller kva ressursar økta kan nå. Det er skilde kontrollar med skilde bevis.
Skriv ned resultatet som teneste, backend, tillaten policy og observert versjon. Ei slik registrering svarar presist på tryggleiksspørsmålet, noko korkje etikettargumentet eller eit argument om bryderi nokon gong gjer.