Недопустимая версия 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: одноразовая виртуальная машина или контейнер

Для подрядчика, который две недели атакует один старый шлюз, выделенная ВМ с ослабленной политикой — более чистая граница, чем рабочая станция. Старая поверхность и повседневный профиль браузера перестают делить политику ядра, а утилизация — это удаление, а не находка аудита.

Это по-прежнему машина в сети, поэтому ограничьте доступ и держите её в стороне от общего просмотра. Стоимость обслуживания — ещё один образ, который нужно патчить, что реально, но ограничено и заметно, в отличие от забытого флага LEGACY на ноутбуке.

Что оставляет вам сравнение

Выбирайте по трём вопросам: кому нужен старый протокол, на сколько и кто заметит, если исключение переживёт свою причину. Одно приложение, один человек, несколько дней указывают на настройку для процесса. Целый парк за одним устройством указывает на сам шлюз. Всё, что требует постоянной политики LEGACY на хосте, — это закупочное решение в техническом костюме.

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