OpenVPN: tls-ciphersuites супраць tls-version-min — што ўводзіць кожны

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

Праверце зборку, перш чым чытаць любы спіс

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

openvpn --version

Зборка 2.6, скомпанаваная з OpenSSL, прымае і tls-cipher, і tls-ciphersuites. Зборка з mbed TLS зусім не мае выбару набораў TLS 1.3, а кіраўніцтва 2.6 пазначае tls-ciphersuites як опцыю OpenSSL. Калі сервер перасабралі з іншым бэкендам, той жа профіль можа змяніць паводзіны, не змяніўшы ніводнага радка канфігурацыі.

Пакуль вы тут, запусціце openvpn --show-tls і захавайце вывад. Гэта інвентар, з якім вы будзеце параўноўваць пазней, і яго танна захаваць да таго, як хтосьці пачне рэдагаваць профілі.

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

Трымайце межы версій асобна ад спісаў шыфраў

У кіраўніцтве 2.6 гэта тры элементы кіравання, а не адзін:

• tls-cipher задае палітыку шыфраў для TLS 1.2 і ранейшых і перадаецца ў спіс шыфраў OpenSSL;
• tls-ciphersuites выбірае наборы TLS 1.3;
• tls-version-min і tls-version-max абмяжоўваюць версіі пратакола, якія можа выкарыстоўваць злучэнне.

Такім чынам, старанна ўрэзаны спіс набораў TLS 1.3 нічога не даказвае пра тое, што старая версія ўсё яшчэ дазволена. Калі патрабаванне — «толькі TLS 1.3», яго трымае ніжняя мяжа версіі, а спіс набораў толькі звужае выбар унутры гэтай мяжы:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Гэтая пара выконвае дзве задачы. Выдаленне аднаго з радкоў пакідае другі ўводзіць менш, чым вы думаеце, — і гэта менавіта тая памылка, для перахопу якой існуе ўся гэтая праверка.

Канал даных — гэта чацвёрты элемент кіравання. data-ciphers узгадняе сіметрычны шыфр унутры тунеля, і яго вынік нічога не кажа пра версію TLS кантрольнага канала. Бачыць AES-256-GCM у зводцы сеанса — не доказ пра TLS 1.3 ні ў які бок.

Чытайце show-tls як лакальны інвентар

--show-tls пералічвае наборы, якія падтрымлівае крыптаграфічная бібліятэка, з якой скомпанаваны гэты бінарнік, у парадку пераваг. Гэта не справаздача ад шлюзу. Кіраўніцтва ясна кажа, што спіс паходзіць з лакальнай бібліятэкі, а значыць, ноўтбук з OpenSSL 3.x і маршрутызатар са старой зборкай надрукуюць розныя спісы, размаўляючы з тым жа серверам.

Выкажам здагадку, што кліент падтрымлівае наборы A, B і C, а адзін сеанс выбірае B. Гэта нічога не ўстанаўлівае пра тое, ці дазваляе сервер A або C, і нічога пра тое, ці B — яго адзіны дазволены выбар. Трымайце тры радкі асобна, і большасць заблытаных абмеркаванняў TLS вырашыцца самі.

Інвентар усё ж варта захоўваць. Калі сеанс правальваецца, параўнанне спісу бібліятэкі са спісам профілю паказвае, ці меў кліент наогул шанц прапанаваць тое, што хацеў сервер. Яно таксама паказвае, ці змена бэкенда ціха выдаліла TLS_CHACHA20_POLY1305_SHA256 з пулу, на які спадзяюцца старыя кліенты, — тая рэгрэсія, якая выяўляецца як жменька карыстальнікаў, што не могуць падключыцца, пакуль усе астатнія нічога не заўважаюць.

Спытайце шлюз пра тое, на што ён здольны адказаць

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

Калі вы не адмініструеце яго, запытайце ў аператара падтрымоўваныя патрабаванні да кліентаў або абмежаваны тэст прыёмкі. Адхіленая спроба не азначае аўтаматычна адхілены набор: ніжняя мяжа версіі, праверкі ідэнтычнасці сертыфіката, такія як remote-cert-tls, або неадпаведнасць tls-auth і tls-crypt могуць скончыць абмен раней, чым выбар набору стане важным. Чытайце памылку сервера, перш чым змяняць спіс кліента, бо «handshake failed» ахоплівае чатыры розныя прычыны, і толькі адна з іх — неадпаведнасць шыфра.

Направіць openssl s_client на порт VPN таксама не ўзнаўляе пытанне. Кантрольны канал працуе ўнутры ўласнай структуры OpenVPN, таму сыры занд TLS правярае іншы пратакол на порце, які чакае нечага іншага. Любая выснова з яго — пра занд, а не пра тунель.

Запішыце два вынікі і трымайце іх асобна

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

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

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

Выконвайце праверкі ў гэтым парадку. Пацвердзіце зборку і бэкенд з дапамогай --version. Захавайце --show-tls да любых змен. Назавіце патрабаваную ніжнюю мяжу версіі асобна ад спісу набораў. Пацвердзіце эфектыўную палітыку працуючага асобніка ў яго ўладальніка. Назірайце адзін дазволены сеанс і, калі план дазваляе, адну адхіленую спробу са старой версіяй. Запішыце вынікі кантрольнага канала і канала даных як асобныя высновы.

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