SSTP dhe SSL 3.0: etiketa kundrejt versionit të negociuar

Dy njerëz mund të shikojnë të njëjtin vendosje SSTP dhe të arrijnë në përfundime të kundërta. Njëri lexon dokumentacionin e produktit, sheh shkronjat SSL dhe supozon se tuneli po ekzekuton një protokoll të tërhequr vite më parë. Tjetri tregon një shtrëngim duarsh modern dhe përfundon se pyetja është mbyllur. Të dy argumentojnë nga etiketa dhe jo nga versioni i negociuar, dhe vetëm njëri prej tyre është provë. Krahasimi që ia vlen të bëhet është ai midis asaj që premton emri dhe asaj që zgjedh në të vërtetë shërbimi.

Dy përgjigje për të njëjtën pyetje

Argumenti i etiketës është i lehtë për t'u formuluar: SSTP përshkruhet si protokoll i sigurt tuneli mbi soketa, emri historik thotë SSL, prandaj lidhja duhet të jetë SSL 3.0. Ai qëndron sepse emri vërtet vjen nga ajo linjë dhe sepse shumica e atyre që e përsëritin nuk kanë parë kurrë një shtrëngim duarsh. Ai qëndron gjithashtu sepse përfundimi tingëllon i kujdesshëm, sikur supozimi i më të keqes të ishte zgjedhja e sigurt. Supozimi i më të keqes dhe matja e versionit aktual janë dy veprimtari të ndryshme, dhe vetëm njëra prej tyre ndryshon diçka.

Argumenti i provës shtron një pyetje më të ngushtë. Për cilin version protokolli u dakordësuan ky klient dhe ky server, në këtë pikë fundore, në këtë moment? Përgjigja vjen nga shërbimi që përfundon TLS, jo nga një faqe marketingu ose një shfletues që arriti një sajt me emër të ngjashëm.

Dy argumentet ndryshojnë në atë që mund të provojnë. Etiketa nuk mund të dallojë një vendosje të vjetër nga një e rregulluar, dhe shtrëngimi i duarve nuk mund t'ju thotë çfarë bën një shërbim i palidhur në të njëjtin host. Përdorni të dytin dhe ndaloni përdorimin e të parit.

Lexoni versionin që zgjedh në të vërtetë shërbimi

Filloni duke emërtuar komponentët: implementimi i klientit, implementimi i serverit, pika fundore TLS dhe gjithçka në mes që përfundon dhe rithemelon TLS. Një balancues ngarkese që përfundon TLS dhe flet HTTP të thjeshtë me backend-in ndryshon se cilën politikë pajisjeje duhet të lexoni.

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

Shënoni pikën fundore dhe kohën pranë rezultatit, sepse një ndryshim i mëvonshëm i politikës e bën të pavlefshme një vëzhgim pa datë. Përsëriteni provën nga një klient në të njëjtën rrugë rrjeti si përdoruesit që ju interesojnë, pasi një pajisje përgjimi mund të përfundojë TLS me cilësimet e veta. Nëse dy pozicionet nuk përputhen, keni gjetur komponentin që ka rëndësi. Nëse përputhen, keni provë dhe jo slogan.

Ndani fushën e regjistrit nga negociatat

Një numër versioni me pamje të vjetër në një fushë nuk është i njëjti fakt si një sesion SSL 3.0. RFC 7568 e trajton versionin e shtresës së regjistrit dhe protokollin e negociuar si çështje të ndara, dhe pikërisht nga ky dallim vijnë përgjigjet e gabuara dhe të sigurta. Lexoni protokollin e negociuar, pastaj shifrimin, dhe vetëm atëherë nxirrni një përfundim për sesionin.

I njëjti dokument është i qartë për vetë protokollin: SSL 3.0 nuk duhet të përdoret, dhe negociata ose kthimi pas në të janë të ndaluara. Arsyeja është konstruksioni i thyer CBC që shfrytëzoi sulmi POODLE, dhe kjo është veti e protokollit, jo konfigurim i një aplikacioni.

Prandaj „kjo ngarkesë është ndoshta e vështirë për t'u shfrytëzuar” nuk është argument për ta mbajtur SSL 3.0 të aktivizuar. Kërkesa është të hiqet protokolli, jo të fitohet një debat për një demonstrim.

Tërhiqni SSL 3.0 me një politikë që mund ta mbroni

Në Windows cilësimet e protokollit Schannel ndodhen nën çelësin Protocols dhe lexohen veçmas për rolin e klientit dhe të serverit, prandaj një ndryshim që rregullon një drejtim mund ta lërë tjetrin të paprekur. Cilësimet aktuale dhe kërkesat e rinisjes së tyre dokumentohen nga Microsoft, dhe një bibliotekë TLS e palës së tretë në të njëjtin host i shpërfill plotësisht ato.

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

Ndryshoni politikën përmes rrugës së miratuar të administrimit, konfirmoni që shërbimi pronar e rifiton konfigurimin dhe mbani një rrugë kthimi të miratuar. Ngjitja e një skripti të gjerë regjistri nga një mjedis tjetër është mënyra se si rregullimi i një shërbimi kthehet në ndërprerje për çdo klient TLS në makinë. Shtrirja e rinisjes ka rëndësi këtu: një cilësim që duket i zbatuar mund të mbahet ende në memorie nga një shërbim që nuk e ka ringarkuar.

Një palë që ende kërkon një version të vjetruar ka nevojë për një përditësim ose një plan migrimi. Një përjashtim i padokumentuar që rikthen në heshtje protokollin e vjetër nuk është strategji përputhshmërie dhe nuk do t'i mbijetojë auditimit të radhës.

Pranoni ndryshimin me lidhje të reja

Testoni me sesione të reja pas ndryshimit të politikës, sepse një lidhje e krijuar para ndryshimit nuk provon asgjë për konfigurimin që është tani në fuqi. Konfirmoni që protokolli i lejuar ka sukses dhe ai i ndaluar dështon përmes procesit të autorizuar të vlerësimit, pastaj lini identitetin e certifikatës dhe kontrollet e besimit saktësisht siç ishin.

Mbani mend çfarë nuk mbulon shtrëngimi i duarve. SSTP mbart vërtetim PPP pas shtresës TLS, kështu që një version modern protokolli nuk thotë asgjë për atë se cili përdorues u autorizua ose cilat burime mund të arrijë sesioni. Këto janë kontrolle të ndara me prova të ndara.

Shkruani rezultatin si shërbim, backend, politikë e lejuar dhe version i vëzhguar. Një regjistrim i tillë i përgjigjet saktësisht pyetjes së sigurisë, gjë që as argumenti i etiketës dhe as ai i shqetësimit nuk e bëjnë kurrë.