SSTP și SSL 3.0: eticheta față de versiunea negociată

Două persoane pot privi același deployment SSTP și pot ajunge la concluzii opuse. Una citește documentația produsului, vede literele SSL și presupune că tunelul rulează un protocol retras acum ani. Cealaltă indică un handshake modern și concluzionează că întrebarea este închisă. Ambele argumentează din etichete, nu din versiunea negociată, și doar unul dintre aceste lucruri este o dovadă. Comparația care merită făcută este între ce promite numele și ce selectează efectiv serviciul.

Două răspunsuri la aceeași întrebare

Argumentul etichetei este ușor de formulat: SSTP este descris ca protocol de tunelare securizată prin socket-uri, numele istoric spune SSL, deci conexiunea trebuie să fie SSL 3.0. Rezistă pentru că numele chiar provine din acea linie și pentru că majoritatea celor care îl repetă nu s-au uitat niciodată la un handshake. Rezistă și pentru că concluzia sună prudent, ca și cum a presupune ce e mai rău ar fi alegerea sigură. A presupune ce e mai rău și a măsura versiunea reală sunt activități diferite, și doar una dintre ele schimbă ceva.

Argumentul dovezii pune o întrebare mai îngustă. Pe ce versiune de protocol s-au înțeles acest client și acest server, la acest punct final, în acest moment? Răspunsul vine de la serviciul care termină TLS, nu de la o pagină de marketing sau de la un browser care a ajuns pe un site cu nume similar.

Cele două argumente diferă prin ce pot dovedi. Eticheta nu poate distinge un deployment vechi de unul corectat, iar handshake-ul nu vă poate spune ce face un serviciu fără legătură pe același host. Folosiți-l pe al doilea și opriți-vă din a-l folosi pe primul.

Citiți versiunea pe care serviciul o selectează efectiv

Începeți prin a numi componentele: implementarea client, implementarea server, punctul final TLS și tot ce se află între ele și termină și restabilește TLS. Un balansator de încărcare care termină TLS și vorbește HTTP simplu cu backendul schimbă a cui dispozitiv politică trebuie să o citiți.

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

Notați punctul final și ora lângă rezultat, pentru că o modificare ulterioară a politicii face inutilă o observație fără dată. Repetați sondarea de la un client aflat pe aceeași cale de rețea ca utilizatorii care vă interesează, deoarece un dispozitiv de interceptare poate termina TLS cu propriile setări. Dacă cele două poziții nu concordă, ați găsit componenta care contează. Dacă concordă, aveți o dovadă în loc de un slogan.

Separați câmpul de înregistrare de negociere

Un număr de versiune cu aspect învechit într-un câmp nu este același fapt ca o sesiune SSL 3.0. RFC 7568 tratează versiunea stratului de înregistrare și protocolul negociat ca aspecte distincte, și exact din această distincție provin răspunsurile greșite și încrezătoare. Citiți protocolul negociat, apoi cifrul, și abia apoi trageți o concluzie despre sesiune.

Același document este lipsit de ambiguitate cu privire la protocolul în sine: SSL 3.0 nu trebuie folosit, iar negocierea sau revenirea la el sunt interzise. Motivul este construcția CBC defectuoasă exploatată de atacul POODLE, iar aceasta este o proprietate a protocolului, nu configurația unei aplicații.

De aceea „această încărcare de lucru este probabil greu de exploatat” nu este un argument pentru a menține SSL 3.0 activat. Cerința este să eliminați protocolul, nu să câștigați o dezbatere despre o singură demonstrație.

Retrageți SSL 3.0 cu o politică pe care o puteți susține

În Windows, setările de protocol Schannel se află sub cheia Protocols și sunt citite separat pentru rolul de client și de server, motiv pentru care o modificare care repară o direcție o poate lăsa neatinsă pe cealaltă. Setările actuale și cerințele lor de repornire sunt documentate de Microsoft, iar o bibliotecă TLS terță pe același host le ignoră complet.

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

Modificați politica prin calea de administrare acceptată, confirmați că serviciul proprietar își reia configurația și păstrați o cale de revenire aprobată. Lipirea unui script de registru amplu din alt mediu este modul în care o corecție pentru un serviciu devine o pană pentru fiecare client TLS de pe mașină. Amploarea repornirii contează aici: o setare care pare aplicată poate fi încă ținută în memorie de un serviciu care nu a reîncărcat-o.

Un partener care încă necesită o versiune învechită are nevoie de o actualizare sau de un plan de migrare. O excepție nedocumentată care restaurează în tăcere protocolul vechi nu este o strategie de compatibilitate și nu va supraviețui următorului audit.

Acceptați modificarea cu conexiuni noi

Testați cu sesiuni noi după modificarea politicii, pentru că o conexiune stabilită înainte de modificare nu dovedește nimic despre configurația aflată acum în vigoare. Confirmați că protocolul aprobat reușește și că cel interzis eșuează prin procesul de validare autorizat, apoi lăsați identitatea certificatului și verificările de încredere exact așa cum erau.

Amintiți-vă ce nu acoperă handshake-ul. SSTP transportă autentificare PPP după stratul TLS, deci o versiune modernă de protocol nu spune nimic despre ce utilizator a fost autorizat sau la ce resurse poate ajunge sesiunea. Sunt controale separate cu dovezi separate.

Scrieți rezultatul ca serviciu, backend, politică permisă și versiune observată. Acea înregistrare răspunde precis la întrebarea de securitate, ceea ce nu reușește niciodată nici argumentul etichetei, nici un argument al inconvenienței.