சுய-கையொப்பமிட்ட VPN சான்றிதழ்: அதன் பொருள் என்ன, அது எதை நம்புகிறது

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

சான்றிதழ் ஒரு நம்பிக்கைக் களஞ்சியம் அல்ல

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

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

OpenVPN இன் ca விருப்பம் பயன்பாட்டு-வரம்புடைய நம்பிக்கையின் தெளிவான நிகழ்வு. அந்தக் கோப்பு வாடிக்கையாளர் ஏற்கும் நங்கூரங்களைப் பெயரிடுகிறது, மேலும் அதில் ஒரு தனியார் CA அல்லது சிறிய பயன்பாட்டில் சேவையகத்தின் சொந்த சுய-கையொப்பமிட்ட சான்றிதழ் இருக்கலாம். பதிப்பு 2.6 CA கோப்பை விநியோகிப்பதற்குப் பதிலாக SHA-256 விரல்முத்திரையைப் பதிக்க --peer-fingerprint ஐயும் ஏற்கிறது. WireGuard இன்னும் வெளியே உள்ளது: அதில் சான்றிதழ்களே இல்லை, ஒவ்வொரு கூட்டாளிக்கும் ஒரு நிலையான பொது விசை மட்டுமே, எனவே சுய-கையொப்பக் கேள்வி அதற்குப் பொருந்தாது.

நம்பிக்கையை எங்கு நிறுவுகிறீர்கள் என்பது அதை யார் வாரிசாகப் பெறுவார்கள் என்பதைத் தீர்மானிக்கிறது

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

Debian அல்லது Ubuntu இல், /usr/local/share/ca-certificates/ இல் கோப்பை இடுவதும் update-ca-certificates ஐ இயக்குவதும் கணினி முழுவதும் தொகுப்பை மாற்றுகிறது. Windows இல், certutil -addstore -f Root இயந்திரக் களஞ்சியத்தில் எழுதுகிறது, உயர்த்தப்பட்ட கட்டளை தேவைப்படுகிறது, ஆனால் -user சேர்ப்பது அதற்குப் பதிலாக தற்போதைய பயனரின் களஞ்சியத்தை இலக்காகக் கொள்கிறது; இரண்டையும் மாற்றிக்கொள்ள முடியாது. Firefox தனது சொந்த NSS தரவுத்தளத்தை வைத்திருக்கிறது, எனவே OS அளவிலான இறக்குமதி அங்கே ஒருபோதும் தோன்றாமல் இருக்கலாம்.

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

பொது CA இல்லாமலும் நீங்கள் இன்னும் மறையாக்குகிறீர்கள்

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

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

வழங்குநரை நம்புவது பெயர்ச் சரிபார்ப்பைத் தவிர்க்கவில்லை

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

OpenVPN பிரிவைத் தெரியப்படுத்துகிறது. verify-x509-name name, name-prefix அல்லது subject பொருத்தத்தின் மூலம் எதிர்பார்க்கப்பட்ட பொருளைப் பதிக்கிறது. remote-cert-tls server கூட்டாளியின் சான்றிதழ் சேவையகச் சான்றிதழாகப் பயன்படுத்தக்கூடியதாக இருக்க வேண்டும் எனக் கோருகிறது, இது வழங்குநரை நம்பினாலும் வாடிக்கையாளர்-மட்டும் சான்றிதழை நிராகரிக்கிறது. இரண்டு அமைப்புகளில் எதுவும் CA கோப்பை அனுப்புவதால் மாற்றப்படவில்லை.

எதையும் தீர்மானிக்கும் முன் சான்றிதழைப் பாருங்கள்:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName யார் வழங்கியது, எந்தப் பெயர்களுக்கு, எப்போது வரை என்பதைக் காட்டுகிறது.
• openssl verify -CAfile ca.crt server.crt நீங்கள் அனுப்பவிருக்கும் சங்கிலி இலையை உண்மையில் சரிபார்க்கிறதா எனப் பார்க்கிறது.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error வலைப் போர்ட்டல் போன்ற TLS இறுதிப் புள்ளிகளுக்கு வேலை செய்கிறது; 1194 இல் OpenVPN நெறிமுறை சாதாரண TLS ஸ்ட்ரீம் அல்ல, எனவே அந்தச் சோதனை அங்கே பொருந்தாது.

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

ஒன்றை ஏற்கும் முன் ஐந்து சரிபார்ப்புகள்

நீங்கள் சரிசெய்ய முயற்சிக்கும் இணைப்பு அல்லாத ஒரு சேனலில் விரல்முத்திரையை ஒப்பிடுங்கள்: ஒரு பணியகம், உங்களிடம் ஏற்கனவே உள்ள நிறுவி, கையொப்பமிடப்பட்ட உள்ளமைவுக் கோப்பு. சேவையகத்தில் openssl x509 -in server.crt -noout -fingerprint -sha256 மற்றும் வாடிக்கையாளர் பதிவில் அதே மதிப்பு ஒரே பொருளைப் பார்க்கிறீர்கள் என்பதை அறிய போதுமானது.

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

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

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