HTTPS Basic автентифікація проти IPsec: що захищає кожна з них

Відкрийте інструменти розробника, завантажте внутрішній застосунок і простежте, як один запит проходить чотири контрольні точки, перш ніж сторінка відрендериться. Спершу ім'я розв'язується, потім відкривається TCP-з'єднання, далі рукостискання TLS встановлює, хто є сервером, і лише після цього застосунок питає, хто ви. Розглядайте це як окремі події, бо кожна з них завершується невдачею з різними доказами і кожна належить іншій команді. Найбільше плутанини в інцидентах виникає, коли 401 читають як проблему тунелю, а проблему тунелю як поганий пароль.

Перша контрольна точка: чи це той сервер, з яким ви хотіли говорити

Рукостискання TLS відповідає на це питання раніше, ніж надсилається будь-який обліковий запис. Ваш клієнт перевіряє ланцюжок сертифікатів за сховищем довіри і звіряє, чи ім'я в сертифікаті збігається з хостом, який ви ввели. Якщо це не вдається, браузер показує помилку сертифіката і взагалі не надсилає заголовок Authorization. Тому запит пароля не є доказом того, що сервер справжній; це доказ того, що застосунок відповів.

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

Друга контрольна точка: що насправді передається в обміні 401

Автентифікація HTTP Basic надсилає ідентифікатор користувача і пароль у заголовку, закодовані Base64, як описано в RFC 7617. Authorization: Basic dXNlcjpwYXNz це форма; кодування може обернути кожен, хто може прочитати запит, тож уся таємність походить від транспорту під ним. curl -v показує і виклик WWW-Authenticate: Basic, і заголовок, який ви надсилаєте у відповідь.

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

Де тунель IPsec стоїть на цьому шляху

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

Вибір це та частина, об яку спотикаються люди. Тунелі на основі політик використовують селектори трафіку, часто виражені як списки контролю доступу, щоб вирішити, які пакети входять у тунель. Тунелі на основі маршрутів натомість використовують віртуальний інтерфейс і таблицю маршрутизації. У Linux ip xfrm policy показує селектори, а ip xfrm state показує встановлені асоціації безпеки; на пристрої брандмауера еквівалентом є таблиця SA тунелю плюс трасувальник пакетів.

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

Читайте збій на тому рівні, який його повідомив

401 означає, що застосунок не прийняв облікові дані. 403 означає, що він прийняв особу і відмовив в операції. Помилка TLS означає, що клієнт не прийняв сервер. Відсутність маршруту або невідповідність політики означає, що пакет так і не дістався далекого шлюзу. Чотири різні збої, чотири різні власники, і жоден з них не діагностується поглядом на форму входу.

Використовуйте докази, які створює кожен рівень: мережева панель браузера для статусу і заголовків, openssl s_client -connect host:443 для ланцюжка сертифікатів, лічильники SA і журнали шлюзу для трафіку тунелю, і журнал застосунку для рішення про обліковий запис. Коли два рівні повідомляють про помилки одночасно, спершу виправте нижчий, бо мертвий тунель легко може замаскувати збій автентифікації і навпаки.

Складіть карту однієї послуги від початку до кінця

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

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

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