Невалидна версия на TLS в AnyConnect под Linux: първо очертайте обхвата на поправката

Тази грешка се появява преди подканата за парола и това е полезната част: нищо още не е удостоверено, така че проблемът не е в идентификационните данни. В Linux същият диалог на AnyConnect може да идва от стара версия на протокола, 1024-битова група за обмен на ключове или шифров набор, който системната криптополитика отхвърля. Изчиствал съм го по три различни начина на три машини и това, което различава тези решения, е обхватът, а не хитростта. Всяко е защитимо на правилното място и лоша настройка по подразбиране навсякъде другаде.

Прочетете съобщението, преди да пипате политиката

Запазете точния низ от диалога. Оплакването за версия сочи към протоколния слой, оплакването за сертификат — към доверие или именуване, а неуспешният вход — към идентификационни данни. Шлюз, който предлага TLS 1.0 с 1024-битова DHE група, AES-256-CBC и подпис SHA-1, може да има напълно валиден сертификат и пак да бъде отхвърлен от модерна политика, преди данните ви изобщо да бъдат изпратени.

Проверете крайната точка със системния OpenSSL, като използвате реалното име на хоста и порта, който клиентът използва.

Провал на openssl s_client -connect vpn.example.com:443 -servername vpn.example.com, докато -tls1 -cipher DEFAULT@SECLEVEL=0 успява, ви казва, че границата е версия и размер на ключа заедно. Ако първата команда съобщи за малък DH ключ, а не за протоколно предупреждение, версията е наред и само групата се нуждае от внимание. Никога не слагайте частен ключ или парола в проверката.

Вариант 1: разхлабете целия хост с криптополитиката

В Fedora и RHEL 8 и 9 update-crypto-policies --set LEGACY понижава системната политика на OpenSSL, а update-crypto-policies --show потвърждава какво е активно. Обикновено това възстановява тунела, но политиката се чете при стартиране на процес, затова рестартирайте клиента и всеки помощен процес, който е създал, преди да тествате отново. Тя също разрешава по-стари протоколи и по-слаби групи за всеки TLS клиент на машината — от браузъра в съседния прозорец до пакетния мениджър, който обновява ядрото.

Тази широта е целият смисъл и целият проблем. LEGACY е за целия хост, устойчиво и лесно за забравяне, затова трябва да е диагностична стъпка или документирано изключение в управлявана сглобка, никога постоянно състояние на работна станция. Виждал съм такава, която остана на LEGACY две години, защото един вътрешен портал го изискваше, и никой не можеше да каже кога е започнало.

Debian и Ubuntu нямат един превключвател за това. Еквивалентът е редакция на /etc/ssl/openssl.cnf, която задава по-нисък MinProtocol и CipherString = DEFAULT@SECLEVEL=0 в раздела за системни настройки по подразбиране. Същият обхват, различен файл, малко по-лесно за изгубване при обновяване на изданието.

Вариант 2: един конфигурационен файл за един клиент

Конфигурация на OpenSSL за отделен процес държи промяната в едно дърво от процеси, но само ако файлът е свързан така, както библиотеката очаква. Да назовете раздел ssl_conf не е достатъчно: OpenSSL чете ключа от най-горно ниво openssl_conf, следва го до раздел за инициализация и само тогава стига до SSL настройките по подразбиране.

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

Насочете OPENSSL_CONF към този файл и стартирайте VPN клиента през обвивка, която го експортира. Всичко останало на хоста запазва политиката по подразбиране и това е свойството, което има значение, когато дойде въпросът за съответствие. Потвърдете, че файлът наистина действа, преди да обвинявате шлюза: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 трябва да изброи TLS 1.0 шифри, а празен резултат означава, че веригата е скъсана и клиентът тихо е запазил системните настройки.

Файлът е чувствителен към версията. OpenSSL 1.1.1 и 3.x приемат същите имена на раздели, но обработката на директиви около доставчиците се промени в 3.x, затова проверявайте с лога на клиента и тестово ръкостискане, вместо да предполагате, че файлът е прочетен. Печатна грешка в името на раздела се проваля отворено и клиентът тихо използва системните настройки.

Ограничението е покритието. Всичко, свързано с GnuTLS или NSS, игнорира OPENSSL_CONF, както и всеки помощен процес, който клиентът стартира без наследена среда. Проверете с ldd с коя TLS библиотека реално се свързва изпълнимият файл, преди да строите обвивката, защото отговорът решава дали тази опция изобщо съществува.

Вариант 3: еднократна VM или контейнер

За изпълнител, който две седмици удря един стар шлюз, отделна VM с разхлабената политика е по-чиста граница от работната станция. Старата повърхност и ежедневният профил на браузъра спират да делят ядрена политика, а изхвърлянето е изтриване, а не констатация от одит.

Тя пак е машина в мрежата, затова ограничете достъпа ѝ и я дръжте далеч от общо сърфиране. Цената за поддръжка е още един образ за пачване, което е реално, но ограничено и видимо, за разлика от забравен флаг LEGACY на лаптоп.

Какво ви оставя сравнението

Избирайте по три въпроса: кой има нужда от стария протокол, за колко време и кой ще забележи, ако изключението надживее причината си. Едно приложение, един човек, няколко дни сочат към конфигурацията за процес. Цял парк зад едно устройство сочи към самия шлюз. Всичко, което изисква постоянна LEGACY политика на хоста, е решение за доставка, облечено в технически костюм.

Трайното решение принадлежи на устройството: TLS 1.2 или по-нов, група от поне 2048 бита, AEAD шифър и сертификат със съвременен подпис. Поискайте тази промяна от собственика на устройството, после потвърдете договорената версия и шифър в лога на клиента. Запишете изключението с хоста, шлюза, договорения протокол, одобряващия и крайна дата, защото бележката е това, което спира временно решение да стане настройка по подразбиране.