Ці можа сертыфікат RSA працаваць з dh none у OpenVPN?

Вось канфігурацыя сервера, у якой побач з сертыфікатам RSA стаіць dh none, плюс надакучлівае падазрэнне, што адно з іх абавязкова памылковае. Нішто не памылковае. Сертыфікат падпісвае і аўтэнтыфікуе; абмен ключамі ўстанаўлівае агульны сакрэт. Гэта два розныя заданні ў адным рукапацісканні, і TLS дазваляе сертыфікату RSA аўтэнтыфікаваць рукапацісканне, якое выкарыстоўвае эфемерную дамову на эліптычнай крывой.

Блытаніна звычайна прыходзіць разам з кіраўніцтвам па міграцыі. Яно кажа замяніць файл параметраў DH на dh none, чытач заўважае, што сертыфікат не з'яўляецца сертыфікатам эліптычнай крывой, і два факты пачынаюць лічыць супярэчнасцю.

Чаму два параметры выглядаюць звязанымі

Старэйшая канфігурацыя OpenVPN патрабавала файл параметраў DH, бо Diffie-Hellman у канечным полі патрабуе параметраў дамена, на якіх згаджаюцца абодва бакі. Дырэктыва dh паказвала на гэты файл. Калі разгортванне пераходзіць на ECDH, параметры бяруцца з названай крывой, і файл больш не патрэбны — менавіта гэта выяўляе dh none.

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

Найменне робіць перакрыжаванне яшчэ горшым. Эліптычная крывая з'яўляецца і ў назвах набораў ECDHE, і ECDSA, таму лёгка меркаваць, што любое злучэнне, якое згадвае крыву, мусіць мець сертыфікат крывой. Гэта не так.

Як правільна чытаць назву набору TLS 1.2

Вазьміце ECDHE-RSA-AES256-GCM-SHA384. Першы токен — сямейства абмену ключамі: эфемерны Diffie-Hellman на эліптычнай крывой. Другі — сямейства аўтэнтыфікацыі: RSA. Астатняе апісвае абарону запісаў і хэш, які выкарыстоўваецца ў рукапацісканні.

Набор ECDHE-ECDSA выкарыстоўвае тое ж сямейства абмену ключамі з іншым метадам аўтэнтыфікацыі, таму яму патрэбны сертыфікат эліптычнай крывой. Набор DHE-RSA выкарыстоўвае эфемерны Diffie-Hellman у канечным полі з аўтэнтыфікацыяй RSA, і яму сапраўды патрэбны параметры DH.

Чытайце назву набору злева направа і прызначайце кожную частку яе заданню. Пасля падзелу токенаў пытанне змяняецца з «ці адпавядае мой сертыфікат dh none» на «ці дазваляе мой сервер набор, абмен ключамі якога не патрабуе файла DH».

Што насамрэч адключае dh none

dh none кажа серверу не загружаць файл параметраў DH у канечным полі. Ён не адключае аўтэнтыфікацыю, праверку сертыфікатаў або сам TLS. Ён патрабуе, каб узгоднены абмен ключамі не меў патрэбы ў гэтых параметрах, што на практыцы азначае набор ECDHE або рукапацісканне TLS 1.3.

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

З боку эліптычнай крывой крыву выбірае канфігурацыя TLS сервера, і OpenVPN прапануе опцыю выбару на старэйшых галінах. TLS 1.3 апрацоўвае ўзгадненне групы ўнутры пратаколу і зусім не звяртаецца да файла DH.

dh none сам па сабе не з'яўляецца паніжэннем бяспекі. Моц абмену залежыць ад крывой і набору, якія фактычна ўзгоднены, таму наступны крок — паглядзець, што выбралі бакі, а не на адсутны файл.

Пацверджанне ўзгаднення перад рэдагаваннем

Павялічце падрабязнасць сервера і кліента і прачытайце радок кантрольнага канала, які OpenVPN друкуе пасля злучэння. Ён называе версію TLS і ўзгоднены шыфр, а таксама паведамляе тып ключа сертыфіката суразмоўцы. Гэты адзін радок адказвае на пытанне, якое файл канфігурацыі толькі мае на ўвазе.

Калі ён паказвае TLS 1.2 з наборам ECDHE-RSA і сертыфікатам RSA, камбінацыя менавіта такая, якую чакае dh none, і рамантаваць нічога не трэба. Калі ён паказвае набор DHE або збой рукапаціскання без агульнага шыфра, выпраўленне ў палітыцы шыфраў або магчымасцях кліента, а не ў сертыфікаце.

Праверце найстарэйшага кліента, які вы збіраецеся падтрымліваць, бо сучасны кліент можа ўзгадніць TLS 1.3, а старэйшы абмежаваны наборамі TLS 1.2. Калі ў найстарэйшага кліента няма перакрыцця, пашырце дазволеныя наборы або абнавіце гэты вузел.

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

Кантрольны спіс: ці сертыфікат RSA, ці дазволены набор ECDHE, ці паказвае журнал гэты набор і ці ўзгадняе яго найстарэйшы кліент, які падтрымліваецца? Калі ўсе чатыры адказы «так», dh none робіць сваю справу.