OpenVPN: EC மற்றும் ED — இந்தப் பெயர்கள் ஏன் வலிமையின் படிக்கட்டு அல்ல
EC, ED, ECDHE மற்றும் auth வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. எதையும் ஒப்பிடுவதற்கு அல்லது திருத்துவதற்கு முன், ஒவ்வொரு பெயரும் செய்யும் வேலையின்படி OpenVPN சுயவிவரத்தை வரிசைப்படுத்துங்கள்.
ec, ed, ecdh, ecdsa, auth மற்றும் ஒரு TLS சைஃபர் பட்டியலை ஒரே சுயவிவரத்தில் பக்கத்துக்குப் பக்கம் வைத்தால், கோப்பு ஆறு நிலைகள் கொண்ட ஒரு வலிமை டயலைப் போலத் தோன்றும். அது அப்படியல்ல. ஒவ்வொரு பெயரும் வேறு ஒரு கேள்விக்குப் பதிலளிக்கிறது, அவற்றில் ஒன்றில் மட்டும் வேறுபடும் இரு சுயவிவரங்கள் ஒன்று மற்றதைவிட வலிமையானதோ பலவீனமானதோ என்பது கட்டாயமில்லை. பெயர்களை அவை செய்யும் வேலையின்படி வரிசைப்படுத்த ஏறக்குறைய ஐந்து நிமிடங்கள் ஆகும், இது வேலை செய்யும் உள்ளமைவில் மக்கள் செய்யும் பெரும்பாலான மோசமான திருத்தங்களைத் தடுக்கிறது.
கீழேயுள்ள வரிசைப்படுத்தல் குழப்பத்திலிருந்தே தொடங்கி, உங்கள் போக்குவரத்தை உண்மையில் எது பாதுகாக்கிறது என்பதைத் தீர்மானிக்கும் சுயவிவரத்தின் பகுதிகளை நோக்கி வெளிப்புறமாக நகர்கிறது. ஒவ்வொரு பகுதியும் ஒரு தவறான வாசிப்பை எடுத்து, அந்தப் பெயர் உண்மையில் எதனுடன் இணைந்துள்ளது என்பதைக் காட்டுகிறது.
இரு எழுத்துக்கள், இரு வேறு கேள்விகள்
அதிக விவாதத்தை ஏற்படுத்தும் ஜோடி EC மற்றும் ED, இந்த விவாதம் பொதுவாக அவை ஒரே கேள்விக்கான போட்டிப் பதில்கள் என்று கருதுகிறது. அவை ஒரே அச்சில்கூட இல்லை. EC ஒரு கணிதக் குடும்பத்தை விவரிக்கிறது: நீள்வட்ட வளைவு மறையியல், இதில் பாதுகாப்பு ஒரு பெரிய முடிவுள்ள புலத்தில் அல்லாமல் ஒரு வளைவின் மீதான தனித்த மடக்கையின் கடினத்தன்மையிலிருந்து வருகிறது.
ED அந்தக் குடும்பத்தின் உள்ளே ஒரு வளைவு வடிவத்தை விவரிக்கிறது. முறுக்கப்பட்ட எட்வர்ட்ஸ் வளைவுகள் வேகத்திற்காகவும் பல செயலாக்கத் தவறுகளுக்கு எதிரான எதிர்ப்பிற்காகவும் தேர்ந்தெடுக்கப்பட்ட ஒரு குறியீட்டு முறை, மேலும் மக்கள் பொதுவாகக் குறிப்பிடும் பெயர் Ed25519. இந்த வளைவு நீள்வட்ட வளைவு மறையியலுக்குப் போட்டியாளர் அல்ல; இது ஒரு நீள்வட்ட வளைவை எழுதும் ஒரு வழி. ED-ஐ “புதியதும் வலிமையானதுமான EC” என்று படிப்பது முதல் தவறான திருப்பம், அதற்குப் பிறகு எல்லாமே பொதுவாக அதே திசையில் தவறாக இருக்கும்.
கையொப்பமிடுவதும் திறவி பரிமாற்றமும் தனித்தனி வேலைகள்
குடும்பக் கேள்வி தீர்ந்ததும், மீதமுள்ள பெயர்கள் ஒன்றுக்கொன்று ஒருபோதும் மாற்றீடாகாத இரு நெடுவரிசைகளாகப் பிரிகின்றன. ஒரு நெடுவரிசை கையொப்பமிடுகிறது, மற்றது பகிரப்பட்ட ரகசியத்தில் உடன்படுகிறது.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA-வும் ECDSA-வும் இரண்டும் கையொப்பமிடுகின்றன, ஆனால் அவை வெவ்வேறு திறவி வடிவங்களைக் கொண்ட வெவ்வேறு திட்டங்கள், எனவே ஒன்றுக்கு வழங்கப்பட்ட சான்றிதழ் மற்றொன்றாகப் பயன்படுத்த முடியாது. EdDSA ஒரு சிறிய வளைவுத் தொகுப்புக்கு வரையறுக்கப்பட்டுள்ளது; P-256 அவற்றில் ஒன்றல்ல, அதனால்தான் P-256 சான்றிதழ் ECDSA-வால் சரிபார்க்கப்படுகிறது, ஒருபோதும் Ed25519-ஆல் அல்ல.
பரிமாற்ற நெடுவரிசைக்கு EdDH என்று அழைக்கப்படும் இணை எதுவும் இல்லை. Curve25519 திறவியின் மீதான தற்காலிக உடன்பாடு X25519, அது ஒரு குறிப்பிட்ட வளைவைக் கொண்ட ECDH, P-256-ல் இருப்பதைப் போலவே. Ed25519 கண்டிப்பாக கையொப்பத் திட்டத்தையே குறிக்கிறது, ஆனால் இரு வளைவுகளும் தொடர்புடையவை என்பதால் அந்தப் பெயர் பரிமாற்றத்திற்கும் தளர்வாகப் பயன்படுத்தப்படுகிறது: கையொப்பமிடுவதற்குப் பயன்படும் எட்வர்ட்ஸ் வடிவமும் X25519-க்குப் பயன்படும் மாண்ட்கோமெரி வடிவமும் ஒரே அடிப்படைக் குலத்தை விவரிக்கின்றன.
EC சுயவிவரத்தில் ஏன் dh கோப்பு இல்லை
ஒரு dh கோப்பு முடிவுள்ள புல Diffie-Hellman-க்கான முன்கூட்டியே உருவாக்கப்பட்ட அளவுருக்களைக் கொண்டுள்ளது, அந்த அளவுருக்கள் ஒரு பெரிய பகா எண்ணும் ஒரு இனப்பெருக்கியும் எங்கிருந்தாவது வர வேண்டும் என்பதால் இருக்கின்றன. நீள்வட்ட வளைவுப் பரிமாற்றத்திற்கு அவை தேவையில்லை: பெயரிடப்பட்ட வளைவே அளவுருத் தொகுப்பு, இரு பக்கங்களும் அதை ஏற்கனவே அறியும். EC சுயவிவரம் இந்த ஆணையைத் தவிர்க்கக்கூடிய முழுக் காரணம் அதுவே.
இல்லாவிட்டால் நவீனமாகத் தோன்றும் ஒரு சுயவிவரத்தில் dh வரியை இன்னும் உருவாக்கும் இரு சூழ்நிலைகள் உள்ளன. முதலாவது, முடிவுள்ள புலக் குலங்களை உண்மையிலேயே பேச்சுவார்த்தை செய்யும் இரண்டாவது கேட்பான் அல்லது பழைய இணை. இரண்டாவது, RSA கால வார்ப்புருவிலிருந்து நகலெடுக்கப்பட்டு ஒருபோதும் அகற்றப்படாத எஞ்சிய உரை. பரிமாற்றத்திற்கு ஒரு வளைவைப் பெயரிட்டும் 2048-பிட் dh கோப்பை இன்னும் ஏற்றும் ஒரு சுயவிவரம் அவ்வாறு செய்ததால் மேலும் பாதுகாப்பாகாது; அது பயன்படுத்தப்படாத ஒரு பொருளைச் சுமக்கிறது.
TLS 1.3 திறவி பரிமாற்றத்தைப் பெயரிலிருந்து நீக்கியது
TLS_AES_256_GCM_SHA384-ஐ TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384-உடன் ஒப்பிடுங்கள், குறுகிய பெயர் ஒரு தரக்குறைவு போலத் தெரிகிறது. இது ஒரு மறுபெயரிடல், காரணம் கட்டமைப்புசார்ந்தது: TLS 1.3 நிலையான RSA-வையும் முடிவுள்ள புல Diffie-Hellman திறவி பரிமாற்றத்தையும் நீக்கியது, எனவே தற்காலிக நீள்வட்ட வளைவுப் பரிமாற்றமே PSK அல்லாத ஒரே தேர்வாக எஞ்சியது. ஒவ்வொரு தொகுப்பிலும் அதைப் பெயரிட்டால் அதே உண்மை ஒரு டஜன் முறை திரும்பத் திரும்பக் கூறப்படும்.
சான்றிதழ் வகை தொடர்புடைய காரணத்தால் பெயரிலிருந்து மறைந்தது. 1.3-ல் சான்றிதழ் திறவி உடன்பாட்டை அல்ல, கைக்குலுக்கல் கையொப்பத்தை அங்கீகரிக்கிறது, எனவே அது இனித் தொகுப்பைத் தேர்ந்தெடுக்காது. உள்ளமைவில் 1.3-க்கு தனி சைஃபர் பட்டியல் இருப்பதற்குக் காரணமும் அதுவே: தொகுப்புகள் மறுபெயரிடப்பட்டு மறுசீரமைக்கப்பட்டன, பலவீனப்படுத்தப்படவில்லை.
ஒரு விளைவை நேரடியாகச் சொல்ல வேண்டும். ECDHE ஒரு திறவி பரிமாற்ற வழிமுறை, ஒருபோதும் ஒரு சைஃபர் அல்ல. “நீள்வட்ட” என்று விவரிக்கப்படும் ஒரு தொகுப்பு இரு இணைகள் ஒரு பகிரப்பட்ட திறவிக்கு எவ்வாறு வந்தன என்பதைப் பற்றிச் சொல்கிறது, அதன் பிறகு பேலோடை எது மறையாக்குகிறது என்பதைப் பற்றி எதுவும் சொல்லவில்லை.
auth பாக்கெட்டுகளை அங்கீகரிக்கிறது, பேலோடுகளை அல்ல
auth ஆணை பாக்கெட்டுகளை அங்கீகரிக்கும் HMAC சுருக்கத்தைத் தேர்ந்தெடுக்கிறது, அதன் வரலாற்று இயல்புநிலை SHA1. AEAD அல்லாத தரவு சைஃபருடன் OpenVPN மறையாக்கப்பட்ட உரையின் மீது சுருக்கத்தைக் கணக்கிட்டு அதை இறுதியில் இணைக்கிறது; இந்த முதலில் மறையாக்கு-பின்னர் MAC அமைப்பே இணைப்பு மாற்றத்தை நடைமுறைக்கு உகந்ததல்லாமல் ஆக்குகிறது.
இங்குள்ள கட்டுக்கதை, auth-ஐ SHA512-க்கு உயர்த்தினால் சுரங்கப்பாதை வலுவடையும் என்பது. அது மறையாக்கத்தின் வலிமையை உயர்த்தாது, மேலும் பேச்சுவார்த்தை செய்யப்பட்ட தரவு சைஃபர் AES-256-GCM போன்ற AEAD முறையாக இருந்தால், சுருக்கம் தரவுப் பாக்கெட்டுகளுக்கு எல்லாவற்றிற்கும் பயன்படுத்தப்படுவதே இல்லை. GCM குறிச்சொல் ஏற்கனவே அவற்றை அங்கீகரிக்கிறது, auth மதிப்பு கட்டுப்பாட்டு-தட HMAC-க்கும் இன்னும் பயன்பாட்டில் உள்ள AEAD அல்லாத சைஃபருக்கும் ஒதுக்கப்படுகிறது.
எனவே அந்த ஆணை முக்கியமானது, ஆனால் கோப்பில் அதன் இடம் காட்டுவதைவிடக் குறுகிய இடத்தில் முக்கியமானது. உண்மையில் எந்தச் சைஃபர் பேச்சுவார்த்தை செய்யப்பட்டது என்பதைச் சரிபார்ப்பது அது பொருந்துகிறதா என்பதைச் சொல்லும்.
சுயவிவரத்தைத் தரவரிசையின்படி அல்ல, நெடுவரிசையின்படி படியுங்கள்
மூன்று கேள்விகள் இந்த அடுக்குகளைத் தெளிவாகப் பிரிக்கின்றன, ஒவ்வொன்றுக்கும் பேச்சுவார்த்தை செய்யப்பட்ட அமர்வின் வேறு பகுதி பதிலளிக்கிறது. எந்தச் சைஃபர் பேலோடைப் பாதுகாக்கிறது? ஒவ்வொரு பாக்கெட்டுக்கும் எந்தக் குறிச்சொல் அல்லது சுருக்கம் உத்தரவாதம் அளிக்கிறது, பயன்படுத்தப்படும் சைஃபருக்கு அது தேவையா? யாருடைய சான்றிதழ் கைக்குலுக்கலை முடித்தது, கட்டுப்பாட்டுத் தடம் கூடுதலாக tls-auth அல்லது tls-crypt-ஆல் பாதுகாக்கப்படுகிறதா?
EC அல்லது ED என்ற பெயர்ச்சீட்டில் எதுவும் அந்த மூன்றில் எதையும் தீர்மானிக்கவில்லை, ஒரு தொகுப்பின் பெயர் மட்டும் எதையும் தீர்மானிக்கவில்லை. பேச்சுவார்த்தை செய்யப்பட்ட முடிவே ஒரே சான்று, எனவே சொற்களஞ்சியத்திலிருந்து வலிமையை ஊகிப்பதற்குப் பதிலாக அதைப் படியுங்கள்:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logமுதல் கட்டளை உங்கள் சான்றிதழ் உண்மையில் எந்தக் கையொப்பத் திட்டத்தைப் பயன்படுத்துகிறது என்பதைச் சொல்கிறது, நீங்கள் ECDSA-வையா அல்லது Ed25519-ஐயா இயக்குகிறீர்கள் என்பதை அறியும் ஒரே நம்பகமான வழி அதுவே. இரண்டாவது, வாடிக்கையாளர் அமர்வுக்காகப் பதிவில் எழுதிய கட்டுப்பாட்டுத் தட வரியைக் காட்டுகிறது, அதில் TLS பதிப்பும் அது தேர்ந்தெடுத்த தொகுப்பும் அடங்கும். ஒரு சுயவிவரத் திருத்தத்தை அந்த இரு வெளியீடுகளில் ஒன்றால் நியாயப்படுத்த முடியாவிட்டால், அது ஒரு பண்பில் அல்ல, ஒரு பெயரில் செய்யப்பட்ட மாற்றமாக இருக்கலாம்.