SSTP ir SSL 3.0: etiketė prieš suderintą versiją

Du žmonės gali pažvelgti į tą patį SSTP diegimą ir padaryti priešingas išvadas. Vienas skaito produkto dokumentaciją, pamato raides SSL ir mano, kad tunelis naudoja prieš metus atsisakytą protokolą. Kitas nurodo šiuolaikinį rankos paspaudimą ir sako, kad klausimas uždarytas. Abu ginčijasi dėl etikečių, o ne dėl suderintos versijos, ir tik vienas iš jų yra įrodymas. Palyginimas, kurį verta atlikti, yra tarp to, ką žada pavadinimas, ir to, ką paslauga iš tikrųjų pasirenka.

Du atsakymai į tą patį klausimą

Etiketės argumentą lengva suformuluoti: SSTP apibūdinamas kaip saugus lizdų tunelio protokolas, istorinis pavadinimas sako SSL, todėl ryšys turi būti SSL 3.0. Jis laikosi todėl, kad pavadinimas tikrai kilo iš tos linijos, ir todėl, kad dauguma jį kartojančių žmonių niekada nežiūrėjo į rankos paspaudimą. Jis laikosi ir todėl, kad išvada skamba atsargiai, tarsi blogiausio prielaida būtų saugus pasirinkimas. Blogiausio prielaida ir faktinės versijos matavimas yra dvi skirtingos veiklos, ir tik viena jų ką nors keičia.

Įrodymo argumentas užduoda siauresnį klausimą. Dėl kokios protokolo versijos šis klientas ir šis serveris susitarė šiame galiniame taške, šiuo metu? Atsakymas ateina iš paslaugos, kuri užbaigia TLS, o ne iš rinkodaros puslapio ar naršyklės, pasiekusios panašiai pavadintą svetainę.

Šie du argumentai skiriasi tuo, ką gali įrodyti. Etiketė negali atskirti seno diegimo nuo pataisyto, o rankos paspaudimas negali pasakyti, ką daro nesusijusi paslauga tame pačiame hoste. Naudokite antrąjį ir nustokite naudoti pirmąjį.

Skaitykite versiją, kurią paslauga iš tikrųjų pasirenka

Pradėkite nuo komponentų įvardijimo: kliento realizacija, serverio realizacija, TLS galinis taškas ir viskas tarp jų, kas užbaigia ir iš naujo nustato TLS. Apkrovos balansuotojas, kuris užbaigia TLS ir su backend kalba paprastu HTTP, pakeičia tai, kurio įrenginio politiką turite skaityti.

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

Užrašykite galinį tašką ir laiką šalia rezultato, nes vėlesnis politikos pakeitimas datuoto stebėjimo neturinčio stebėjimo nebevertina. Pakartokite patikrinimą iš kliento, esančio tame pačiame tinklo kelyje kaip jums svarbūs naudotojai, nes perėmimo įrenginys gali užbaigti TLS savo nustatymais. Jei dvi pozicijos nesutampa, radote komponentą, kuris svarbus. Jei sutampa, turite įrodymą, o ne šūkį.

Atskirkite įrašo lauką nuo derybų

Senuotyviškai atrodantis versijos numeris viename lauke nėra tas pats faktas kaip SSL 3.0 sesija. RFC 7568 įrašų sluoksnio versiją ir suderintą protokolą laiko atskirais klausimais, ir būtent iš šio skirtumo kyla užtikrinti neteisingi atsakymai. Perskaitykite suderintą protokolą, tada šifrą, ir tik tada darykite išvadą apie sesiją.

Tas pats dokumentas aiškiai sako apie patį protokolą: SSL 3.0 naudoti negalima, o derėtis dėl jo ar grįžti prie jo draudžiama. Priežastis yra sugedusi CBC konstrukcija, kurią išnaudojo POODLE ataka, ir tai yra protokolo savybė, o ne vienos programos konfigūracija.

Todėl „šią apkrovą tikriausiai sunku išnaudoti“ nėra argumentas palikti SSL 3.0 įjungtą. Reikalavimas yra pašalinti protokolą, o ne laimėti ginčą dėl vieno demonstravimo.

Atsisakykite SSL 3.0 su politika, kurią galite pagrįsti

Windows sistemoje Schannel protokolo nustatymai yra po Protocols raktu ir skaitomi atskirai kliento bei serverio vaidmeniui, todėl vieną kryptį taisantis pakeitimas gali palikti kitą nepaliestą. Dabartinius nustatymus ir jų perkrovimo reikalavimus dokumentuoja Microsoft, o trečiosios šalies TLS biblioteka tame pačiame hoste jų visiškai nepaiso.

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

Pakeiskite politiką palaikomu administravimo keliu, patvirtinkite, kad savininkė paslauga iš naujo gauna konfigūraciją, ir palikite patvirtintą grįžimo kelią. Plačių registro scenarijų įklijavimas iš kitos aplinkos yra būdas, kuriuo vienos paslaugos pataisymas tampa visų mašinos TLS klientų sutrikimu. Perkrovimo apimtis čia svarbi: nustatymas, kuris atrodo pritaikytas, gali vis dar būti tos paslaugos atmintyje, kuri jo neperkrovė.

Partneriui, kuris vis dar reikalauja pasenusios versijos, reikia atnaujinimo arba migracijos plano. Nedokumentuota išimtis, kuri tyliai atkuria seną protokolą, nėra suderinamumo strategija ir neišgyvens kito audito.

Priimkite pakeitimą su naujais ryšiais

Po politikos pakeitimo testuokite naujomis sesijomis, nes prieš pakeitimą užmegztas ryšys nieko neįrodo apie dabar galiojančią konfigūraciją. Patvirtinkite, kad leidžiamas protokolas pavyksta, o draudžiamas nepavyksta autorizuotame validavimo procese, ir tada palikite sertifikato tapatybę bei pasitikėjimo patikras lygiai tokias, kokios buvo.

Prisiminkite, ko rankos paspaudimas neapima. SSTP perduoda PPP autentifikaciją po TLS sluoksnio, todėl šiuolaikinė protokolo versija nieko nesako apie tai, kuris naudotojas buvo autorizuotas ar kuriuos išteklius sesija gali pasiekti. Tai atskiri valdikliai su atskirais įrodymais.

Užrašykite rezultatą kaip paslauga, backend, leidžiama politika ir stebima versija. Toks įrašas tiksliai atsako į saugumo klausimą, ko niekada nepadaro nei etiketės argumentas, nei nepatogumo argumentas.