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. Якщо сервер перезібрано з іншим backend, той самий профіль може змінити поведінку, не змінивши жодного рядка конфігурації.

Поки ви тут, запустіть 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 вирішаться самі.

Інвентар усе ж варто зберігати. Коли сесія не вдається, порівняння списку бібліотеки зі списком профілю показує, чи мав клієнт узагалі можливість запропонувати те, чого хотів сервер. Воно також показує, чи не прибрала зміна backend тихо 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

Потім читайте ці два рядки з того файлу, а не з пам'яті. Пара — це доказ; сама назва набору — перевага, а межа версії — окреме твердження про те, від чого сервер відмовляється.

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

Якщо потрібний клієнт не може виконати новий мінімум, ухваліть це рішення про міграцію або виняток явно, замість того щоб тихо знижувати не пов'язане правило приймання, аби розгортання виглядало завершеним.