SSTP at SSL 3.0: ang label kumpara sa napagkasunduang bersyon
Hindi pinapatunayan ng label na SSL ang isang sesyong SSL 3.0. Ihambing ang sinasabing protokol sa aktwal na pinag-uusapan ng serbisyo, pagkatapos ay alisin ang lumang bersyon.
Maaaring titingnan ng dalawang tao ang parehong deployment ng SSTP at makarating sa magkasalungat na konklusyon. Binabasa ng isa ang dokumentasyon ng produkto, nakikita ang mga titik na SSL at ipinapalagay na ang tunel ay nagpapatakbo ng protokol na inalis mga taon na ang nakalipas. Itinuturo ng iba ang modernong pagkakamay at sinasabing tapos na ang tanong. Parehong nakikipagtalo sila mula sa mga label at hindi mula sa napagkasunduang bersyon, at isa lamang sa mga ito ang ebidensya. Ang paghahambing na sulit gawin ay sa pagitan ng ipinangangako ng pangalan at aktwal na pinipili ng serbisyo.
Dalawang sagot sa isang tanong
Madaling sabihin ang argumento ng label: inilalarawan ang SSTP bilang secure na socket tunneling protocol, sinasabi ng makasaysayang pangalan ang SSL, kaya dapat SSL 3.0 ang koneksyon. Nananatili ito dahil talagang nagmula ang pangalan sa linyang iyon at dahil karamihan sa mga umuulit nito ay hindi pa kailanman tumingin sa pagkakamay. Nananatili rin ito dahil mukhang maingat ang konklusyon, na para bang ang pagpapalagay ng pinakamasama ang ligtas na pagpipilian. Ang pagpapalagay ng pinakamasama at ang pagsukat ng aktwal na bersyon ay dalawang magkaibang gawain, at isa lamang sa kanila ang may binabago.
Nagtatanong ng mas makitid na bagay ang argumento ng ebidensya. Anong bersyon ng protokol ang napagkasunduan ng client na ito at ng server na ito, sa endpoint na ito, sa oras na ito? Ang sagot ay nagmumula sa serbisyong nagtatapos ng TLS, hindi sa pahina ng marketing o sa browser na nakarating sa site na may katulad na pangalan.
Nagkakaiba ang dalawang argumento sa kayang patunayan. Hindi kayang ipagkaiba ng label ang lumang deployment sa isang may patch, at hindi kayang sabihin ng pagkakamay kung ano ang ginagawa ng walang kaugnayang serbisyo sa parehong host. Gamitin ang pangalawa at itigil ang paggamit ng una.
Basahin ang bersyong aktwal na pinipili ng serbisyo
Magsimula sa pagpangalan ng mga bahagi: implementasyon ng client, implementasyon ng server, endpoint ng TLS at lahat ng nasa pagitan na nagtatapos at nagpapanumbalik ng TLS. Ang load balancer na nagtatapos ng TLS at nagsasalita ng simpleng HTTP sa backend ay nagbabago kung aling device ang dapat mong basahin ng patakaran.
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
Itala ang endpoint at oras sa tabi ng resulta, dahil ang pagbabago ng patakaran sa hinaharap ay nagpapawalang-silbi sa obserbasyong walang petsa. Ulitin ang pagsusuri mula sa client na nasa parehong landas ng network ng mga user na mahalaga sa iyo, dahil ang aparatong nanghihimasok ay maaaring magtapos ng TLS sa sarili nitong mga setting. Kung hindi magkatugma ang dalawang posisyon, natagpuan mo ang bahaging mahalaga. Kung magkatugma, may ebidensya ka at hindi slogan.
Paghiwalayin ang field ng rekord sa negosasyon
Ang mukhang lumang numero ng bersyon sa isang field ay hindi parehong katotohanan ng isang sesyong SSL 3.0. Itinuturing ng RFC 7568 ang bersyon ng record layer at ang napagkasunduang protokol bilang magkaibang usapin, at sa pagkakaibang iyon nagmumula ang mga mali ngunit kumpiyansang sagot. Basahin ang napagkasunduang protokol, pagkatapos ang cipher, at pagkatapos lamang gumawa ng konklusyon tungkol sa sesyon.
Ang parehong dokumento ay malinaw tungkol sa protokol mismo: hindi dapat gamitin ang SSL 3.0, at ipinagbabawal ang negosasyon o pagbabalik dito. Ang dahilan ay ang sirang CBC construction na pinagsamantalahan ng POODLE attack, at ito ay katangian ng protokol, hindi configuration ng isang application.
Kaya naman ang „malamang mahirap pagsamantalahan ang workload na ito” ay hindi argumento para panatilihing naka-enable ang SSL 3.0. Ang kailangan ay alisin ang protokol, hindi manalo ng debate tungkol sa isang demonstrasyon.
Alisin ang SSL 3.0 gamit ang patakarang kayang ipagtanggol
Sa Windows, ang mga setting ng protokol ng Schannel ay nasa ilalim ng key na Protocols at binabasa nang hiwalay para sa papel ng client at server, kaya ang pagbabagong nag-aayos ng isang direksyon ay maaaring iwanang hindi nagalaw ang isa. Ang mga kasalukuyang setting at ang kanilang pangangailangan sa restart ay dokumentado ng Microsoft, at binabalewala nang buo ng third-party na TLS library sa parehong host ang mga ito.
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
Baguhin ang patakaran sa sinusuportahang landas ng administrasyon, tiyakin na muling nakukuha ng pag-aaring serbisyo ang configuration nito, at panatilihin ang aprubadong paraan ng pagbabalik. Ang pag-paste ng malawak na registry script mula sa ibang kapaligiran ang paraan para maging outage para sa bawat TLS client sa makina ang pag-aayos ng isang serbisyo. Mahalaga dito ang saklaw ng restart: ang setting na mukhang naipatupad ay maaaring hawak pa rin sa memorya ng serbisyong hindi pa ito na-reload.
Ang kasosyong humihingi pa ng lipas nang bersyon ay kailangan ng update o migration plan. Ang hindi dokumentadong pagbubukod na tahimik na nagbabalik ng lumang protokol ay hindi estratehiya ng compatibility at hindi makakalampas sa susunod na audit.
Tanggapin ang pagbabago gamit ang mga bagong koneksyon
Subukan sa mga bagong sesyon pagkatapos ng pagbabago ng patakaran, dahil ang koneksyong itinatag bago ang pagbabago ay walang pinapatunayan tungkol sa configuration na umiiral ngayon. Tiyakin na nagtatagumpay ang pinapayagang protokol at nabibigo ang ipinagbabawal sa awtorisadong proseso ng validation, pagkatapos ay iwanan ang pagkakakilanlan ng sertipiko at mga pagsusuri ng tiwala nang eksakto tulad ng dati.
Tandaan kung ano ang hindi sakop ng pagkakamay. Nagdadala ang SSTP ng PPP authentication pagkatapos ng TLS layer, kaya walang sinasabi ang modernong bersyon ng protokol tungkol sa kung aling user ang awtorisado o kung anong mga resource ang maaabot ng sesyon. Magkaibang kontrol ang mga iyon na may magkaibang ebidensya.
Isulat ang resulta bilang serbisyo, backend, pinapayagang patakaran at naobserbahang bersyon. Ang gayong rekord ay tumpak na sinasagot ang tanong ng seguridad, na hindi nagagawa ng argumento ng label ni ng argumento ng abala.