OpenVPN: EC супраць ED — чаму гэтыя назвы не лесвіца трываласці

Пастаўце ec, ed, ecdh, ecdsa, auth і спіс шыфраў TLS побач у адным профілі, і файл пачне выглядаць як дыск складанасці з шасцю пазіцыямі. Але гэта не так. Кожная назва адказвае на іншае пытанне, і два профілі, якія адрозніваюцца адной з іх, не абавязкова мацнейшыя ці слабейшыя адзін за аднаго. Сартаванне назваў па іх рабоце займае каля пяці хвілін і прадухіляе большасць дрэнных правак, якія людзі робяць у працоўнай канфігурацыі.

Сартаванне ніжэй пачынаецца з самога заблытання, а затым ідзе вонкі, да частак профілю, якія насамрэч вызначаюць, што абараняе ваш трафік. Кожны раздзел па чарзе бярэ адно памылковае прачытанне і паказвае, да чаго назва сапраўды прывязаная.

Дзве літары, два розныя пытанні

Найбольш спрэчак выклікае пара EC і ED, і спрэчка звычайна мяркуе, што яны супернічаюць як адказы на адно пытанне. Яны нават не на адной восі. EC апісвае сямейства матэматыкі: крыптаграфію на эліптычных крывых, дзе бяспека паходзіць ад складанасці дыскрэтнага лагарыфма на крывой, а не ў вялікім канечным полі.

ED апісвае форму крывой унутры гэтага сямейства. Крывыя Twisted Edwards — гэта прадстаўленне, выбранае дзеля хуткасці і ўстойлівасці да некалькіх памылак рэалізацыі, а Ed25519 — гэта назва, якую звычайна маюць на ўвазе. Крывая не канкурэнт крыптаграфіі на эліптычных крывых; гэта адзін са спосабаў запісу эліптычнай крывой. Чытанне ED як «больш новага, больш моцнага EC» — гэта першы няправільны паварот, і ўсё пасля яго, як правіла, памылковае ў тым жа кірунку.

Подпіс і абмен — асобныя задачы

Калі пытанне сямейства вырашана, астатнія назвы дзеляцца на два слупкі, якія ніколі не замяняюць адзін аднаго. Адзін слупок падпісвае, другі дамаўляецца пра агульны сакрэт.

І EdDSA, і ECDSA падпісваюць, але гэта розныя схемы з рознымі фарматамі ключоў, таму сертыфікат, выдадзены для адной з іх, нельга выкарыстоўваць як другі. EdDSA вызначаны для невялікага набору крывых; P-256 не ўваходзіць у яго, таму сертыфікат P-256 правяраецца праз ECDSA і ніколі праз Ed25519.

У слупку абмену няма эквівалента пад назвай EdDH. Эфемерная дамова на ключы Curve25519 — гэта X25519, і гэта ECDH з пэўнай крывой, гэтак жа як з P-256. Ed25519 строга азначае схему подпісу, хоць назву свабодна ўжываюць для абмену, бо дзве крывыя звязаныя: форма Edwards для подпісу і форма Montgomery для X25519 апісваюць адну і тую ж групу.

Чаму ў профілі EC няма файла dh

Файл dh змяшчае загадзя створаныя параметры для Diffie-Hellman у канечным полі, і гэтыя параметры існуюць таму, што вялікі просты лік і генератар павінны адкульсьці ўзяцца. Абмену на эліптычных крывых яны не патрэбныя: названая крывая і ёсць набор параметраў, і абодва бакі ўжо яе ведаюць. Вось чаму профіль EC можа апусціць дырэктыву.

Дзве сітуацыі ўсё яшчэ ствараюць радок dh у профілі, які інакш выглядае сучасным. Першая — другі слухач або старэйшы партнёр, які сапраўды дамаўляецца пра групы канечнага поля. Другая — рэшткавы тэкст, скапіяваны з шаблона эпохі RSA і ніколі не выдалены. Профіль, які называе крыўю для абмену і ўсё яшчэ загружае файл dh на 2048 біт, не становіцца бяспечнейшым ад гэтага; ён нясе нявыкарыстаны артэфакт.

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 умацоўвае тунель. Гэта не павялічвае трываласць шыфравання, і калі ўзгоднены шыфр даных — гэта рэжым AEAD, такі як AES-256-GCM, то хэш зусім не ўжываецца да пакетаў даных. Тэг 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 і набор, на якім ён спыніўся. Калі праўку профілю нельга апраўдаць адным з гэтых двух вывадаў, гэта, хутчэй за ўсё, змена назвы, а не ўласцівасці.