Базовая аутентификация HTTPS и 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 защищает аккаунт, и только последний знает, кто вы.