SSTP ഉം SSL 3.0 ഉം: ലേബലും ചർച്ച ചെയ്ത പതിപ്പും

രണ്ട് പേർക്ക് ഒരേ SSTP വിന്യാസം കണ്ട് വിരുദ്ധ നിഗമനങ്ങളിൽ എത്താം. ഒരാൾ ഉൽപ്പന്ന രേഖ പഠിച്ച്, SSL അക്ഷരങ്ങൾ കണ്ട്, വർഷങ്ങൾക്ക് മുമ്പ് പിൻവലിച്ച പ്രോട്ടോക്കോളാണ് ടണൽ പ്രവർത്തിപ്പിക്കുന്നതെന്ന് കരുതുന്നു. മറ്റൊരാൾ ആധുനിക ഹാൻഡ്ഷേക്കിലേക്ക് ചൂണ്ടി ചോദ്യം അവസാനിച്ചു എന്ന് പറയുന്നു. ഇരുവരും ലേബലുകളിൽ നിന്നാണ് വാദിക്കുന്നത്, ചർച്ച ചെയ്ത പതിപ്പിൽ നിന്നല്ല, ഇവയിൽ ഒന്ന് മാത്രമാണ് തെളിവ്. ചെയ്യാൻ യോഗ്യമായ താരതമ്യം പേര് എന്ത് വാഗ്ദാനം ചെയ്യുന്നു, സേവനം യഥാർത്ഥത്തിൽ എന്ത് തിരഞ്ഞെടുക്കുന്നു എന്നതിനിടയിലാണ്.

ഒരേ ചോദ്യത്തിന് രണ്ട് ഉത്തരങ്ങൾ

ലേബൽ വാദം പറയാൻ എളുപ്പമാണ്: SSTP സുരക്ഷിത സോക്കറ്റ് ടണലിംഗ് പ്രോട്ടോക്കോളായി വിവരിക്കുന്നു, ചരിത്രപരമായ പേര് SSL എന്ന് പറയുന്നു, അതിനാൽ കണക്ഷൻ SSL 3.0 ആയിരിക്കണം. പേര് യഥാർത്ഥത്തിൽ ആ പരമ്പരയിൽ നിന്ന് വന്നതിനാലും അത് ആവർത്തിക്കുന്നവരിൽ ഭൂരിഭാഗവും ഒരിക്കലും ഹാൻഡ്ഷേക്ക് നോക്കിയിട്ടില്ലാത്തതിനാലും അത് നിലനിൽക്കുന്നു. നിഗമനം ജാഗ്രതയുള്ളതായി തോന്നുന്നതിനാലും അത് നിലനിൽക്കുന്നു, ഏറ്റവും മോശമായത് അനുമാനിക്കുന്നതാണ് സുരക്ഷിതമായ തിരഞ്ഞെടുപ്പ് എന്ന പോലെ. ഏറ്റവും മോശമായത് അനുമാനിക്കുന്നതും യഥാർത്ഥ പതിപ്പ് അളക്കുന്നതും വ്യത്യസ്ത പ്രവൃത്തികളാണ്, ഇവയിൽ ഒന്ന് മാത്രമാണ് എന്തെങ്കിലും മാറ്റുന്നത്.

തെളിവിന്റെ വാദം കൂടുതൽ ഇടുങ്ങിയ ചോദ്യം ചോദിക്കുന്നു. ഈ ക്ലയന്റും ഈ സെർവറും ഈ അവസാന പോയിന്റിൽ, ഈ സമയത്ത് ഏത് പ്രോട്ടോക്കോൾ പതിപ്പിൽ യോജിച്ചു? ഉത്തരം TLS അവസാനിപ്പിക്കുന്ന സേവനത്തിൽ നിന്ന് വരുന്നു, ഏതെങ്കിലും മാർക്കറ്റിംഗ് പേജിൽ നിന്നോ സമാനമായ പേരുള്ള സൈറ്റിൽ എത്തിയ ബ്രൗസറിൽ നിന്നോ അല്ല.

രണ്ട് വാദങ്ങളും എന്ത് തെളിയിക്കാം എന്നതിൽ വ്യത്യസ്തമാണ്. ലേബലിന് പഴയ വിന്യാസത്തെ പാച്ച് ചെയ്തതിൽ നിന്ന് വേർതിരിക്കാനാവില്ല, ഹാൻഡ്ഷേക്കിന് അതേ ഹോസ്റ്റിലുള്ള അസംബന്ധ സേവനം എന്ത് ചെയ്യുന്നു എന്ന് പറയാനാവില്ല. രണ്ടാമത്തേത് ഉപയോഗിക്കുക, ആദ്യത്തേത് ഉപയോഗിക്കുന്നത് നിർത്തുക.

സേവനം യഥാർത്ഥത്തിൽ തിരഞ്ഞെടുക്കുന്ന പതിപ്പ് വായിക്കുക

ഘടകങ്ങൾ പേരിട്ട് തുടങ്ങുക: ക്ലയന്റ് നടപ്പാക്കൽ, സെർവർ നടപ്പാക്കൽ, TLS അവസാന പോയിന്റ്, അവയ്ക്കിടയിൽ TLS അവസാനിപ്പിച്ച് വീണ്ടും സ്ഥാപിക്കുന്ന എല്ലാം. TLS അവസാനിപ്പിച്ച് ബാക്കെൻഡിനോട് സാധാരണ HTTP സംസാരിക്കുന്ന ലോഡ് ബാലൻസർ, നിങ്ങൾ ഏത് ഉപകരണത്തിന്റെ നയം വായിക്കണം എന്നത് മാറ്റുന്നു.

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

ഫലത്തോടൊപ്പം അവസാന പോയിന്റും സമയവും രേഖപ്പെടുത്തുക, കാരണം പിന്നീട് നയം മാറിയാൽ തീയതിയില്ലാത്ത നിരീക്ഷണം നിഷ്പ്രയോജനമാകും. നിങ്ങൾക്ക് പ്രധാനമായ ഉപയോക്താക്കൾ ഉള്ള അതേ നെറ്റ്‌വർക്ക് പാതയിലുള്ള ക്ലയന്റിൽ നിന്ന് പരിശോധന ആവർത്തിക്കുക, കാരണം തടസ്സപ്പെടുത്തുന്ന ഉപകരണത്തിന് സ്വന്തം ക്രമീകരണങ്ങളോടെ TLS അവസാനിപ്പിക്കാം. രണ്ട് നിലപാടുകളും യോജിക്കുന്നില്ലെങ്കിൽ, പ്രധാന ഘടകം നിങ്ങൾ കണ്ടെത്തി. യോജിക്കുന്നുവെങ്കിൽ, മുദ്രാവാക്യത്തിന് പകരം തെളിവ് നിങ്ങളുടെ പക്കലുണ്ട്.

രേഖാ ഫീൽഡിനെ ചർച്ചയിൽ നിന്ന് വേർതിരിക്കുക

ഒരു ഫീൽഡിലെ പഴയതായി തോന്നുന്ന പതിപ്പ് നമ്പർ SSL 3.0 സെഷന് തുല്യമായ വസ്തുതയല്ല. RFC 7568 രേഖാ പാളിയുടെ പതിപ്പും ചർച്ച ചെയ്ത പ്രോട്ടോക്കോളും വെവ്വേറെ കാര്യങ്ങളായി കാണുന്നു, ഈ വേർതിരിവിൽ നിന്നാണ് ആത്മവിശ്വാസമുള്ള തെറ്റായ ഉത്തരങ്ങൾ വരുന്നത്. ചർച്ച ചെയ്ത പ്രോട്ടോക്കോൾ വായിക്കുക, പിന്നെ സൈഫർ, അതിന് ശേഷം മാത്രം സെഷനെക്കുറിച്ച് നിഗമനത്തിൽ എത്തുക.

അതേ രേഖ പ്രോട്ടോക്കോളിനെക്കുറിച്ച് വ്യക്തമാണ്: SSL 3.0 ഉപയോഗിക്കരുത്, അതിൽ ചർച്ചയോ പിൻവാങ്ങലോ നിരോധിച്ചിരിക്കുന്നു. കാരണം POODLE ആക്രമണം ഉപയോഗിച്ച തകർന്ന CBC ഘടനയാണ്, അത് പ്രോട്ടോക്കോളിന്റെ സ്വഭാവമാണ്, ഒരു അപ്ലിക്കേഷന്റെ ക്രമീകരണമല്ല.

അതുകൊണ്ടാണ് “ഈ ഭാരം ചൂഷണം ചെയ്യാൻ ബുദ്ധിമുട്ടാണ്” എന്നത് SSL 3.0 സജീവമായി നിലനിർത്താനുള്ള വാദമല്ല. ആവശ്യം പ്രോട്ടോക്കോൾ നീക്കം ചെയ്യുകയാണ്, ഒരു പ്രദർശനത്തെക്കുറിച്ചുള്ള തർക്കം നേടുകയല്ല.

SSL 3.0 നിങ്ങൾക്ക് ന്യായീകരിക്കാവുന്ന നയത്തോടെ പിൻവലിക്കുക

Windows ൽ Schannel ന്റെ പ്രോട്ടോക്കോൾ ക്രമീകരണങ്ങൾ Protocols കീയുടെ കീഴിലാണ്, ക്ലയന്റ്, സെർവർ റോളുകൾക്ക് വെവ്വേറെ വായിക്കുന്നു, അതുകൊണ്ടാണ് ഒരു ദിശ ശരിയാക്കുന്ന മാറ്റം മറ്റേതിനെ തൊടാതെ വിടാനാകുന്നത്. നിലവിലെ ക്രമീകരണങ്ങളും അവയുടെ റീസ്റ്റാർട്ട് ആവശ്യകതകളും Microsoft രേഖപ്പെടുത്തിയിട്ടുണ്ട്, അതേ ഹോസ്റ്റിലുള്ള മൂന്നാം കക്ഷി TLS ലൈബ്രറി അവ പൂർണ്ണമായി അവഗണിക്കുന്നു.

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

നയം പിന്തുണയുള്ള അഡ്മിനിസ്ട്രേഷൻ പാതയിലൂടെ മാറ്റുക, ഉടമസ്ഥ സേവനം അതിന്റെ ക്രമീകരണം വീണ്ടും സ്വീകരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, തിരികെ പോകാൻ അംഗീകൃത വഴി സൂക്ഷിക്കുക. മറ്റൊരു പരിസ്ഥിതിയിൽ നിന്ന് വിശാലമായ രജിസ്ട്രി സ്ക്രിപ്റ്റ് ഒട്ടിക്കുന്നതാണ് ഒരു സേവനത്തിന്റെ അറ്റകുറ്റപ്പണി യന്ത്രത്തിലെ എല്ലാ TLS ക്ലയന്റിനും തടസ്സമാകുന്ന വഴി. ഇവിടെ റീസ്റ്റാർട്ടിന്റെ പരിധി പ്രധാനമാണ്: പ്രയോഗിച്ചതായി തോന്നുന്ന ക്രമീകരണം വീണ്ടും ലോഡ് ചെയ്യാത്ത സേവനത്തിന്റെ മെമ്മറിയിൽ ഇപ്പോഴും ഉണ്ടായേക്കാം.

ഇപ്പോഴും കാലഹരണപ്പെട്ട പതിപ്പ് ആവശ്യപ്പെടുന്ന പങ്കാളിക്ക് അപ്ഡേറ്റോ കുടിയേറ്റ പ്ലാനോ വേണം. പഴയ പ്രോട്ടോക്കോൾ നിശ്ശബ്ദമായി പുനഃസ്ഥാപിക്കുന്ന രേഖപ്പെടുത്താത്ത ഒഴിവാക്കൽ അനുയോജ്യതാ തന്ത്രമല്ല, അടുത്ത ഓഡിറ്റ് വരെ നിലനിൽക്കില്ല.

മാറ്റം പുതിയ കണക്ഷനുകളോടെ സ്വീകരിക്കുക

നയ മാറ്റത്തിന് ശേഷം പുതിയ സെഷനുകളോടെ പരിശോധിക്കുക, കാരണം മാറ്റത്തിന് മുമ്പ് സ്ഥാപിച്ച കണക്ഷൻ ഇപ്പോൾ പ്രാബല്യത്തിലുള്ള ക്രമീകരണത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. അനുവദനീയമായ പ്രോട്ടോക്കോൾ വിജയിക്കുന്നുവെന്നും നിരോധിത പ്രോട്ടോക്കോൾ അധികാരപ്പെടുത്തിയ സാധൂകരണ പ്രക്രിയയിൽ പരാജയപ്പെടുന്നുവെന്നും ഉറപ്പാക്കുക, തുടർന്ന് സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റിയും വിശ്വാസ പരിശോധനകളും ഉണ്ടായിരുന്നതുപോലെ വിടുക.

ഹാൻഡ്ഷേക്ക് എന്ത് ഉൾക്കൊള്ളുന്നില്ല എന്ന് ഓർക്കുക. SSTP TLS പാളിക്ക് ശേഷം PPP പ്രാമാണീകരണം വഹിക്കുന്നു, അതിനാൽ ആധുനിക പ്രോട്ടോക്കോൾ പതിപ്പ് ഏത് ഉപയോക്താവിനെ അധികാരപ്പെടുത്തി അല്ലെങ്കിൽ സെഷന് ഏത് വിഭവങ്ങളിൽ എത്താം എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഇവ വെവ്വേറെ നിയന്ത്രണങ്ങളാണ് വെവ്വേറെ തെളിവുകളോടെ.

ഫലം സേവനം, ബാക്കെൻഡ്, അനുവദിച്ച നയം, നിരീക്ഷിച്ച പതിപ്പ് എന്നിവയായി എഴുതുക. അത്തരം രേഖ സുരക്ഷാ ചോദ്യത്തിന് കൃത്യമായി ഉത്തരം നൽകുന്നു, ലേബൽ വാദമോ അസൗകര്യ വാദമോ അത് ഒരിക്കലും ചെയ്യുന്നില്ല.