Як OpenConnect перетворює cookie входу на тунель?

OpenConnect пов'язує два окремі обміни однією короткоживучою величиною: веб-вхід і тунель VPN. Перший обмін — звичайний HTTPS: облікові дані, круговий рейс SAML або токен ідуть до шлюзу, а відповідь несе cookie автентифікації. Другий обмін пред'являє цей cookie тому самому шлюзу як доказ, що веб-фаза вже відбулася, і лише тоді піднімається тунель.

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

Що клієнт і шлюз обмінюють, по порядку

Фаза автентифікації виглядає як звичайний захищений сайт. OpenConnect надсилає облікові дані користувача або йде за переспрямуванням шлюзу до постачальника ідентичності, а шлюз відповідає документом, у який вбудовано cookie автентифікації. У протоколі AnyConnect це значення подорожує в заголовку cookie в наступних запитах, зазвичай під іменем на кшталт webvpn, і посібник розглядає його як облікові дані, що несуть сесію далі.

Друга фаза — це запит CONNECT до VPN-кінцевої точки шлюзу з прикріпленим cookie. Шлюз перевіряє його, призначає адресу, і клієнт запускає CSTP поверх TLS, а DTLS слугує необов'язковим швидшим шляхом даних, коли сесія вже існує. Лише в цей момент встановлюються параметри тунелю, маршрути, налаштування DNS і ключі трафіку сесії. Cookie провело клієнта крізь двері; воно нічого не зашифрувало.

Ця послідовність пояснює, чому існує openconnect --authenticate. Запустіть його, і він виконає веб-фазу, виведе невеликий блок змінних оболонки на кшталт COOKIE, HOST, CONNECT_URL і FINGERPRINT, а потім завершиться до побудови будь-якого тунелю. Скрипт-обгортка може потім почати справжнє з'єднання з цими значеннями, і це саме той поділ, якого потребує розгортання без екрана або у двох контейнерах.

Cookie — носій сесії, а не ключ

Ставтеся до значення так, як ви ставилися б до ідентифікатора сесії у вебзастосунку. Хто володіє ним протягом його життя, може попросити у шлюзу тунель, на який ця сесія має право, тому його таємність важлива. Але копіювання не розкриває трафік, бо конфіденційність тунелю походить із рукостискання TLS і похідних ключів, а не з рядка cookie.

Це також не постійний дозвіл. Шлюз і постачальник ідентичності вирішують, скільки живе сесія, а браузер, який ще показує сторінку входу, нічого не говорить про те, чи сесія тунелю ще дійсна. Повторне підключення після завершення означає повторити веб-фазу і створити свіже cookie, і в цьому сенс повторної автентифікації, а не перешкода, яку треба обходити інженерними засобами.

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

Передавання cookie без залишених копій

Найбезпечніше механічне передавання в Linux — стандартний ввід. --cookie-on-stdin читає значення з stdin, тому cookie ніколи не з'являється в списку аргументів процесу, де будь-який локальний користувач може прочитати його через ps. Конвеєр, який автентифікується в одному процесі й живить тунель в іншому, тримає значення в каналі, а не у файлі чи змінній середовища.

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

Тримайте й межу привілеїв усвідомленою. Процес, який говорить із постачальником ідентичності й, можливо, відкриває браузер, має працювати від імені користувача, якому належить цей вхід. Процесу, який налаштовує маршрути, DNS і пристрій тунелю, може знадобитися більше привілеїв. Запуск усього браузера від root, щоб його cookie було доступне тунелю, що належить root, — неправильний обмін, а сучасні налаштування OpenConnect уміють явно передавати значення через цю межу.

Журналювання заслуговує на ту саму підозру. Докладний вивід клієнта, допоміжні скрипти й діагностика шлюзу можуть повторювати матеріал запиту, і не кожен рівень журналу приховує cookie. Записуйте мінімальний потрібний запис про помилку, тримайте його поза спільними каналами і перевіряйте відредагований зразок, перш ніж долучити його до тікета.

Перевірка й завершення в другій фазі

Друга фаза все ще має перевіряти сервер. FINGERPRINT, який виводить --authenticate, — це закріплення сертифіката у формі pin-sha256:, і передавання його виклику тунелю з --servercert утримує перевірку прив'язаною до того шлюзу, проти якого ви автентифікувалися. Вимкнення перевірки сертифікатів заради спрощення скрипта прибирає єдиний доказ того, що cookie передається потрібному хосту.

Коли шлюз відкидає cookie, рішення — новий раунд автентифікації, а не довший кеш. Зберігайте cookie лише на час з'єднання, видаляйте тимчасові файли під час виходу і використовуйте процедуру видалення сесії постачальника ідентичності або шлюзу, коли сесію викрито або пристрій втрачено. Кешоване cookie не є звільненням від MFA.

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