SSTP na SSL 3.0: lebo dhidi ya toleo lililojadiliwa
Lebo ya SSL haithibitishi kikao cha SSL 3.0. Linganisha itifaki inayodaiwa na ile ambayo huduma hujadili kwa kweli, kisha ondoa toleo la zamani.
Watu wawili wanaweza kutazama usambazaji huo wa SSTP na kufikia hitimisho zilizopingana. Mmoja anasoma nyaraka za bidhaa, anaona herufi SSL na kudhani kwamba handaki linaendesha itifaki iliyoondolewa miaka kadhaa iliyopita. Mwingine anaonyesha ukumbusho wa mkono wa kisasa na kuhitimisha kwamba swali limefungwa. Wote wawili wanabishana kwa lebo na si kwa toleo lililojadiliwa, na ni moja tu ya hayo ambayo ni ushahidi. Ulinganisho unaostahili kufanywa ni kati ya kile jina linaahidi na kile huduma huchagua kwa kweli.
Majibu mawili kwa swali moja
Hoja ya lebo ni rahisi kusema: SSTP inaelezewa kama itifaki salama ya handaki kupitia soketi, jina la kihistoria linasema SSL, kwa hiyo muunganisho lazima uwe SSL 3.0. Inadumu kwa sababu jina kwa kweli linatoka kwenye mstari huo na kwa sababu wengi wanaoirudia hawajawahi kutazama ukumbusho wa mkono. Inadumu pia kwa sababu hitimisho linasikika kwa tahadhari, kana kwamba kudhani kibaya zaidi ndiyo chaguo salama. Kudhani kibaya zaidi na kupima toleo halisi ni shughuli mbili tofauti, na ni moja tu inayobadilisha kitu.
Hoja ya ushahidi inauliza swali jembamba. Ni toleo gani la itifaki ambalo mteja huyu na seva hii walikubaliana, katika kituo hiki cha mwisho, kwa wakati huu? Jibu linatoka kwa huduma inayomaliza TLS, si kwa ukurasa wa masoko au kivinjari kilichofikia tovuti yenye jina linalofanana.
Hoja hizi mbili zinatofautiana katika kile zinachoweza kuthibitisha. Lebo haiwezi kutofautisha usambazaji wa zamani na ule uliorekebishwa, na ukumbusho wa mkono hauwezi kukuambia huduma isiyohusiana kwenye mwenyeji huyo huyo inafanya nini. Tumia ya pili na acha kutumia ya kwanza.
Soma toleo ambalo huduma huchagua kwa kweli
Anza kwa kutaja vipengele: utekelezaji wa mteja, utekelezaji wa seva, kituo cha mwisho cha TLS na kila kitu kati yao kinachomaliza na kuanzisha upya TLS. Kibalansi cha mzigo kinachomaliza TLS na kuzungumza HTTP rahisi na sehemu ya nyuma hubadilisha ni sera ya kifaa gani unapaswa kusoma.
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
Andika kituo cha mwisho na wakati kando ya matokeo, kwa sababu mabadiliko ya sera baadaye hufanya uchunguzi usio na tarehe kuwa bure. Rudia jaribio kutoka kwa mteja aliye kwenye njia hiyo ya mtandao kama watumiaji unaowajali, kwa sababu kifaa cha kukatiza kinaweza kumaliza TLS kwa mipangilio yake mwenyewe. Ikiwa misimamo miwili hailingani, umepata kipengele kilicho muhimu. Ikilingana, una ushahidi badala ya kaulimbiu.
Tenganisha uwanja wa rekodi na majadiliano
Namba ya toleo inayoonekana ya zamani katika uwanja mmoja si ukweli ule ule kama kikao cha SSL 3.0. RFC 7568 huchukua toleo la tabaka la rekodi na itifaki iliyojadiliwa kama masuala tofauti, na ni kutokana na tofauti hiyo hasa zinapotoka majibu sahihi yasiyofaa yenye kujiamini. Soma itifaki iliyojadiliwa, kisha cipher, na kisha tu fanya hitimisho kuhusu kikao.
Hati hiyo hiyo iko wazi kuhusu itifaki yenyewe: SSL 3.0 haipaswi kutumiwa, na majadiliano au kurudi nyuma kwake ni marufuku. Sababu ni muundo wa CBC uliovunjika ambao shambulio la POODLE lilitumia, na hilo ni sifa ya itifaki, si usanidi wa programu moja.
Ndiyo sababu „mzigo huu wa kazi huenda ni mgumu kutumia vibaya“ si hoja ya kuacha SSL 3.0 ikiwa imewezeshwa. Sharti ni kuondoa itifaki, si kushinda mjadala kuhusu onyesho moja.
Ondoa SSL 3.0 kwa sera unayoweza kuitetea
Katika Windows mipangilio ya itifaki ya Schannel iko chini ya ufunguo wa Protocols na husomwa tofauti kwa jukumu la mteja na la seva, ndiyo sababu mabadiliko yanayorekebisha mwelekeo mmoja yanaweza kuacha mwingine bila kuguswa. Mipangilio ya sasa na mahitaji yake ya kuwasha upya yameandikwa na Microsoft, na maktaba ya TLS ya mtu wa tatu kwenye mwenyeji huyo huyo huipuuza kabisa.
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
Badilisha sera kupitia njia ya utawala inayotumika, hakikisha huduma inayomiliki inapata usanidi wake tena, na uweke njia ya kurudi iliyoidhinishwa. Kubandika skripti pana ya rejista kutoka mazingira mengine ndiyo njia ambayo marekebisho ya huduma moja huwa kukatika kwa kila mteja wa TLS kwenye mashine. Wigo wa kuwasha upya ni muhimu hapa: mpangilio unaoonekana umetumika unaweza bado kushikiliwa kwenye kumbukumbu na huduma ambayo haijapakia upya.
Mshirika anayedai toleo lililopitwa na wakati bado anahitaji sasisho au mpango wa uhamishaji. Isipokuwa lisiloandikwa linalorejesha kwa utulivu itifaki ya zamani si mkakati wa uoanifu na halitaendelea hadi ukaguzi ujao.
Kubali mabadiliko kwa miunganisho mipya
Jaribu kwa vikao vipya baada ya mabadiliko ya sera, kwa sababu muunganisho ulioanzishwa kabla ya mabadiliko hauthibitishi chochote kuhusu usanidi unaotumika sasa. Hakikisha itifaki inayoruhusiwa inafanikiwa na ile iliyokatazwa inashindwa katika mchakato wa uthibitishaji ulioidhinishwa, kisha acha utambulisho wa cheti na ukaguzi wa uaminifu kama zilivyokuwa.
Kumbuka kile ukumbusho wa mkono haukufuniki. SSTP hubeba uthibitishaji wa PPP baada ya tabaka la TLS, kwa hiyo toleo la kisasa la itifaki halisemi chochote kuhusu mtumiaji gani aliidhinishwa au rasilimali gani kikao kinaweza kufikia. Hizo ni udhibiti tofauti na ushahidi tofauti.
Andika matokeo kama huduma, sehemu ya nyuma, sera inayoruhusiwa na toleo lililozingatiwa. Rekodi kama hiyo hujibu swali la usalama kwa usahihi, jambo ambalo hoja ya lebo wala hoja ya usumbufu haifanyi kamwe.