OpenVPN EC vs ED: бұл атаулар неге қуат сатысы емес
EC, ED, ECDHE және auth түрлі сұрақтарға жауап береді. Бірдеңені салыстыру немесе өңдеу алдында OpenVPN профилін әр атаудың атқаратын жұмысына қарай реттеңіз.
Бір профильге ec, ed, ecdh, ecdsa, auth және TLS шифрлерінің тізімін қатар қойыңыз, сонда файл алты позициялы қуат реттегішіне ұқсай бастайды. Бірақ олай емес. Әр атау түрлі сұраққа жауап береді, ал солардың біреуінде ерекшеленетін екі профиль бір-бірінен міндетті түрде күшті немесе әлсіз бола бермейді. Атауларды атқаратын жұмысына қарай реттеу шамамен бес минут алады және адамдар жұмыс істеп тұрған конфигурацияға жасайтын нашар өзгерістердің көбін болдырмайды.
Төмендегі реттеу шатасудың өзінен басталып, содан кейін сыртқа, профильдің трафигіңізді шын мәнінде қорғайтын бөліктеріне қарай жылжиды. Әр бөлім кезекпен бір қате оқуды алып, атаудың шын мәнінде неге байланғанын көрсетеді.
Екі әріп, екі түрлі сұрақ
Ең көп дау тудыратын жұп — EC және ED, ал дау әдетте оларды бір сұраққа бәсекелес жауаптар деп болжайды. Олар тіпті бір осьте де емес. EC математиканың бір отбасын сипаттайды: эллиптикалық қисық криптографиясы, мұнда қауіпсіздік үлкен ақырлы өрісте емес, қисықтағы дискретті логарифмнің қиындығынан келеді.
ED сол отбасының ішіндегі қисық пішінін сипаттайды. Twisted Edwards қисықтары жылдамдық және бірнеше іске асыру қателіктеріне төзімділік үшін таңдалған көрініс, ал 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 қатаң түрде қолтаңба схемасын білдіреді, алайда екі қисық байланысты болғандықтан атау алмасу үшін еркін қолданылады: қол қоюға пайдаланылатын Edwards түрі мен X25519 үшін пайдаланылатын Montgomery түрі бір негізгі топты сипаттайды.
Неге 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 нұсқасы мен тоқтаған жиынтығын қоса көрсетеді. Егер профиль өзгерісін осы екі шығыстың бірімен де негіздеу мүмкін болмаса, бұл қасиеттің емес, атаудың өзгерісі болуы ықтимал.