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 или неpodudarnost између tls-auth и tls-crypt могу прекинути размену пре него што избор скупа уопште постане важан. Прочитајте грешку сервера пре него што промените списак клијента, јер «handshake failed» покрива четири различита узрока и само је један од њих неpodudarnost шифре.

Усмеравање openssl s_client на VPN порт такође не репродукује питање. Контролни канал ради унутар сопственог оквира OpenVPN-а, па сирова TLS сонда тестира други протокол на порту који очекује нешто друго. Сваки закључак из ње односи се на сонду, а не на тунел.

Забележите два резултата и држите их одвојено

Свежа дозвољена сесија ствара ред контролног канала који наводи верзију протокола и изабрану шифру, и засебан ред податковног канала који наводи шифру тунела. Забележите оба са верзијом клијента и називом профила и забележите која је инстанца сервера одговорила:

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

Затим прочитајте та два реда из те датотеке, а не из сећања. Пар је доказ; сам назив скупа је преференција, а граница верзије је засебна тврдња о томе шта сервер одбија.

Извршите провере овим редом. Потврдите градњу и backend помоћу --version. Забележите --show-tls пре него што било шта промените. Наведите тражену доњу границу верзије одвојено од списка скупова. Потврдите ефективну политику покренуте инстанце са њеним власником. Посматрајте једну дозвољену сесију и, ако план дозвољава, један одбијен покушај са старијом верзијом. Забележите резултате контролног и податковног канала као засебне налазе.

Ако потребни клијент не може да испуни нови минимум, донесите ту одлуку о миграцији или изузетку изричито, уместо да тихо снизите неповезано правило прихватања како би увођење изгледало завршено.