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 அங்கீகாரத்தை எடுத்துச் செல்கிறது, எனவே நவீன நெறிமுறைப் பதிப்பு எந்தப் பயனர் அங்கீகரிக்கப்பட்டார் அல்லது அமர்வு எந்த வளங்களை அடையலாம் என்பதைப் பற்றி எதுவும் கூறாது. இவை தனித்தனி கட்டுப்பாடுகள் தனித்தனி சான்றுகளுடன்.

முடிவை சேவை, பின்தளம், அனுமதிக்கப்பட்ட கொள்கை, கவனிக்கப்பட்ட பதிப்பு என எழுதுங்கள். அத்தகைய பதிவு பாதுகாப்புக் கேள்விக்குத் துல்லியமாகப் பதிலளிக்கிறது, லேபல் வாதமோ அசௌகரிய வாதமோ அதை ஒருபோதும் செய்வதில்லை.