ஒரு பழைய பியர் TLS 1.0 ஐ கட்டாயப்படுத்துகிறது: விதிவிலக்கை வரம்பிடுங்கள், ஹோஸ்ட் அல்ல

ஒரு பழைய சாதனம் தோன்றுகிறது, இணைக்க முடியவில்லை, விரைவாகத் தோன்றும் பழுதுநீக்கமானது இணைப்பு வெற்றிபெறும் வரை முழு ஹோஸ்டையும் பலவீனப்படுத்துவதாகும். அந்த பரிமாற்றம் அந்தக் கணத்தில் கண்ணுக்குத் தெரியாதது, நடைமுறையில் நிரந்தரமானது, ஏனெனில் இறுதியில் வேலை செய்யும் கீழ் வரம்பை யாரும் அகற்றுவதில்லை. மிகவும் வேறுபட்ட இரண்டு குறைபாடுகள் இந்த அழுத்தத்தை உருவாக்குகின்றன, அவற்றில் ஒன்று மட்டுமே சைஃபர்களைப் பற்றியது. முதலில் குறைபாட்டை வகைப்படுத்தி, பின்னர் விதிவிலக்கை அது பரவ முடியாத இடத்தில் வையுங்கள்.

ஒரு உத்தரவை மாற்றுவதற்கு முன் தோல்வியை இரண்டாகப் பிரிக்கவும்

பொதுவான சைஃபர் இல்லை அல்லது ஆதரிக்கப்படாத நெறிமுறை பதிப்பு என்ற சேவையகப் பதிவு வரி கட்டுப்பாட்டு சேனலிலிருந்து வருகிறது: இரு முனைகளும் பேச்சுவார்த்தையையே எப்படிப் பாதுகாப்பது என்பதில் உடன்பட முடியவில்லை. சேவையக சான்றிதழ் சரிபார்ப்பு முறை எதுவும் இயக்கப்படவில்லை என்ற கிளையன்ட் வரி முற்றிலும் வேறு இடத்திலிருந்து வருகிறது, ஏனெனில் அந்த கிளையன்ட் யார் பதிலளித்தார் என்பதையே சரிபார்க்கவில்லை. தரவு சைஃபரை மாற்றுவது இரண்டாவது வழக்குக்கு எதுவும் செய்யாது, பங்கு சரிபார்ப்பைச் சேர்ப்பது முதல் வழக்குக்கு எதுவும் செய்யாது.

துண்டிப்புக்கு முந்தைய கடைசி வரியை அல்ல, ஒவ்வொரு பக்கத்தின் மிக முந்தைய தோல்வி வரியை எடுங்கள், ஏனெனில் கடைசியானது பொதுவாக ஒரு விளைவு மட்டுமே. பின்னர் கிளையன்ட் உண்மையில் எந்தக் கோப்பைத் திறந்தது என்பதை உறுதிசெய்யுங்கள்: இறக்குமதி செய்யப்பட்ட சுயவிவரம் பெரும்பாலும் வெவ்வேறு காட்சிப் பெயர்களில் இரண்டு முறை இருக்கும், யாரும் படிக்காத நகலைத் திருத்துவது நம்பத்தகுந்த மாற்றமின்மையை உருவாக்குகிறது. இயங்கும் செயல்முறை தொடங்கியபோதைய அமைப்புகளை வைத்திருக்கும், எனவே சேமித்த கோப்பு ஏற்றப்பட்ட கோப்பு அல்ல. கீழேயுள்ள கட்டளைகள் அதே முயற்சியின் கிளையன்ட் பேச்சுவார்த்தையையும் சேவையகத்தின் பார்வையையும் பக்கத்து பக்கத்தில் காட்டுகின்றன.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

பலவீனமான கீழ் வரம்புக்கு இரண்டாவது லிசனர் தான் நேர்மையான இடம்

சாதனம் 2.5 க்கு முந்தைய தரவு சேனலுடன் TLS 1.0 இல் நிற்கும்போது, சேவையகம் கட்டுப்பாட்டு சேனலுக்கான தாழ்ந்த கீழ் வரம்பையும் பழைய கிளையன்ட் அடையாளம் காணும் தரவு சைஃபரையும் வழங்க வேண்டும். ஃபால்பேக் உத்தரவு அந்த பியருக்காகவே உள்ளது, சைஃபர் பட்டியல் நவீன கிளையன்ட்களை நவீன தொகுப்புகளில் வைத்திருக்கிறது. இரண்டு உத்தரவுகளும் பயனர் அல்லது இணைப்புக்கு அல்ல, லிசனருக்கே சொந்தம், பின்னர் எந்த ஒரு-கிளையன்ட் விருப்பமும் அவற்றைக் குறுகச்செய்யாது. அதனால்தான் பிரதான துறையில் ஒரு பழைய சாதனம் இருப்பது அந்தத் துறையைப் பகிரும் ஒவ்வொரு பியர் பற்றிய முடிவாகும்.

தளம் அனுமதிக்கும் இடத்தில், பழைய லிசனரை தனித் துறையில் அதன் சொந்த நிகழ்வாக இயக்கவும், அந்தத் துறையை சாதனத்தின் முகவரியிலிருந்து மட்டும் அனுமதிக்கவும், பிரதான சேவையை அப்படியே விடவும். இரண்டாவது லிசனர் ஏன் உள்ளது என்பதை அதன் உள்ளமைவு உள்ள கோப்பில் எழுதி வையுங்கள், இல்லையெனில் எதிர்கால சுத்தம் அதை மீதமான குப்பையாகப் படிக்கும். பலவீனமான கீழ் வரம்பு சாதனம் முடியும் இடத்திலேயே முடிந்தால் மட்டுமே இந்தப் பிரிவு மதிப்புள்ளது.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

பழைய வழங்குநர் சான்றிதழ் உண்மையில் எதை உடைக்கிறது

சரிபார்ப்புப் பிழை என்பது காணாமல் போன பங்குப் பிணைப்பு: அது இல்லாமல் கிளையன்ட் நம்பகமான CA உடன் சங்கிலியாக இணையும் எந்தச் சான்றிதழையும் ஏற்கும், அது சேவையகத்திற்கு வழங்கப்பட்டதா என்பதைப் பொருட்படுத்தாமல். முதலில் சான்றிதழை சேவையகப் பங்குடன் பிணைக்கவும், பிணைப்பை சரிசெய்யும் குமிழாக அல்ல, தேவையாகக் கருதுங்கள். அந்தப் படிக்குப் பிறகும் தோல்வியுறும் சுயவிவரத்திற்கு மட்டுமே உண்மையான சான்றிதழ் சிக்கல் உள்ளது.

விசை அளவு அல்லது கையொப்ப வழிமுறை இனி OpenSSL இன் இயல்புநிலைக் கொள்கையைப் பூர்த்தி செய்யாத பழைய வழங்குநர் சான்றிதழ், கட்டுப்பாட்டு சேனலில் பாதுகாப்பு நிலையை வரம்புடன் மாற்ற வேண்டிய நிலையாகும். அங்கு நிலையைத் தாழ்த்துவது சரிபார்ப்பை அணைக்காது, அதை ஒருபோதும் காலி CA, முடக்கப்பட்ட சரிபார்ப்பு அல்லது சரிபார்க்கப்படாத ஹோஸ்ட்பெயருடன் சேர்க்கக்கூடாது. அந்த வரியை அது தேவைப்படும் ஒரே சுயவிவரத்திற்குள் வைத்திருங்கள்; தளர்த்தப்பட்ட OpenSSL உள்ளமைவை உலகளவில் ஏற்றுமதி செய்வது இயந்திரத்தில் உள்ள ஒவ்வொரு நிரலுக்கும் அதே தளர்வைக் கொடுக்கும்.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

பேனரை அல்ல, பேச்சுவார்த்தையில் எட்டிய மதிப்புகளைப் படியுங்கள்

verbosity 4 இல் இரு முனைகளும் அவை ஒப்புக்கொண்ட கட்டுப்பாட்டு சேனல் TLS பதிப்பையும் சைஃபரையும், அமர்வின் தரவு சைஃபரையும் அச்சிடுகின்றன. துவக்க பேனரை அல்ல, அந்த வரிகளைப் படியுங்கள், ஏனெனில் பேனர் வெற்றியைத் தெரிவிக்கிறதே தவிர அதன் நிபந்தனைகளை அல்ல. பின்னர் நவீன கிளையன்ட்டை பிரதான லிசனருடன் மீண்டும் இணைத்து அது இன்னும் நவீன தொகுப்பில் தரையிறங்குகிறதா என்பதை உறுதிசெய்யுங்கள், ஏனெனில் பகிரப்பட்ட உள்ளமைவுக்குள் கசிந்த விதிவிலக்கு முதலில் இங்கேதான் தெரியும். நீங்கள் நகலெடுக்கும் மதிப்புகள் அடுத்த மதிப்பாய்வுக்கான அடிப்படையாகும்.

பழைய சாதனத்தைத் தனியாகச் சோதிக்கவும்: அது இணைக்க வேண்டும், பதிவுகளில் பலவீனமான அளவுருக்களைக் காட்டும் ஒரே அமர்வாக அது இருக்க வேண்டும். இரண்டாவது பியரும் பழைய தொகுப்பைப் பேச்சுவார்த்தை செய்தால், விதிவிலக்கு நோக்கியதை விடப் பரந்தது, லிசனர் பிரிவு உண்மையில் நடக்கவில்லை. முடிவை மட்டுமல்ல, இரண்டு அவதானிப்புகளையும் பதிவு செய்யுங்கள்.

ஒவ்வொரு விதிவிலக்குக்கும் உரிமையாளரும் தேதியும் தேவை

நீக்கும் நிபந்தனை இல்லாத விதிவிலக்கு அமைதியாக இயல்புநிலையாகிறது, எனவே சாதனம், உரிமையாளர், காரணம், அது மறையும் தேதி ஆகியவற்றை அது நியாயப்படுத்தும் உள்ளமைவுக்கு அருகில் வையுங்கள். அந்த வரி இல்லாவிட்டால் பலவீனமான கீழ் வரம்பு அதைத் தேவைப்பட்ட வன்பொருளை விட நீண்ட காலம் வாழும்.

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