Авторизация в прокси-серверах: Basic, Digest и NTLM

Прокси-серверы играют ключевую роль в современных сетях, обеспечивая контроль доступа, кэширование и безопасность трафика. Одним из важных аспектов их работы является механизм авторизации клиентов, который позволяет проверять права доступа перед передачей запросов к целевым ресурсам. В протоколе HTTP для авторизации через прокси используются специальные заголовки: Proxy-Authenticate (в ответе сервера с кодом 407 Proxy Authentication Required) и Proxy-Authorization (в запросе клиента с учетными данными). Эти заголовки аналогичны WWW-Authenticate и Authorization для прямой авторизации на сервере, но применяются именно к прокси.

Среди распространенных схем авторизации в прокси-серверах выделяются три: Basic, Digest и NTLM. Каждая из них имеет свои особенности в плане безопасности, реализации и совместимости. Basic — самая простая, но наименее защищенная. Digest улучшает безопасность за счет хэширования. NTLM, разработанная Microsoft, ориентирована на интеграцию с Windows-доменами и использует более сложный обмен сообщениями. Выбор схемы зависит от требований к безопасности и среды развертывания.

Эти методы описаны в стандартах HTTP, таких как RFC 7235 для общего фреймворка авторизации, RFC 7617 для Basic и RFC 7616 для Digest. NTLM не является открытым стандартом IETF, но широко используется в корпоративных сетях.

Механизм авторизации в прокси-серверах

Процесс авторизации через прокси следует схеме challenge-response. Когда клиент отправляет запрос без учетных данных, прокси отвечает кодом 407 и заголовком Proxy-Authenticate, указывающим поддерживаемые схемы. Клиент повторяет запрос, добавляя заголовок Proxy-Authorization с credentials.

Этот механизм позволяет прокси аутентифицировать клиента независимо от целевого сервера. В отличие от прямой авторизации (с кодом 401), здесь используется отдельный набор заголовков, чтобы избежать конфликтов в цепочках прокси. Если прокси поддерживает несколько схем, он может перечислить их в Proxy-Authenticate, а клиент выбирает подходящую.

Важно отметить, что авторизация применяется к соединению или запросу, в зависимости от схемы. Для безопасности рекомендуется использовать HTTPS, особенно с слабыми методами.

ProxyCove — это международный провайдер прокси-серверов, специализирующийся на предоставлении высококачественных решений для бизнеса и частных пользователей, которым необходимы платные прокси с прозрачной моделью оплаты за трафик, а не за подписку. Компания предлагает прокси дата-центров, резидентные и мобильные прокси в 195+ странах с поддержкой IPv4 и IPv6, высокой скоростью, стабильным аптаймом и гибкой ротацией IP, что делает сервис востребованным для парсинга данных, SMM, SEO-задач, арбитража трафика, мультиаккаунтинга и автоматизации. ProxyCove выделяется отсутствием абонентской платы, возможностью использования до тысяч одновременных потоков, бессрочным трафиком и удобным управлением через личный кабинет и Telegram-инструменты, обеспечивая профессиональный уровень сервиса по конкурентной стоимости.

Basic Authentication

Basic — самая простая и широко поддерживаемая схема, определенная в RFC 7617. Она передает учетные данные в виде строки «username:password», закодированной в Base64.

Процесс начинается с ответа прокси 407 и заголовком Proxy-Authenticate: Basic realm=»…» . Клиент формирует Proxy-Authorization: Basic <base64-encoded credentials>. Base64 не является шифрованием, поэтому пароль легко декодируется при перехвате. Из-за этого Basic рекомендуется только поверх TLS.

Преимущества Basic в простоте реализации и совместимости: она поддерживается практически всеми клиентами и серверами. Однако в корпоративных прокси ее часто избегают из-за уязвимости к атакам man-in-the-middle. Многие современные системы деприцируют Basic в пользу более защищенных альтернатив.

Digest Authentication

Digest — более безопасная альтернатива Basic, описанная в RFC 7616 (обновление RFC 2617). Она использует хэширование MD5 или SHA-256, чтобы избежать передачи пароля в открытом виде.

Прокси отправляет challenge в Proxy-Authenticate: Digest realm=»…», nonce=»…», qop=»auth» и т.д. Клиент вычисляет хэш на основе username, password, nonce, метода и URI, отправляя его в Proxy-Authorization. Nonce — случайное значение от сервера — защищает от replay-атак. Опция qop=»auth-int» добавляет проверку целостности тела запроса.

Digest не требует хранения пароля в открытом виде на сервере (достаточно хэша). Она устойчива к перехвату, но уязвима к атакам на MD5 (хотя SHA-256 решает эту проблему в новых реализациях). По сравнению с Basic, Digest требует дополнительных раунд-трипов, но значительно повышает безопасность без TLS.

NTLM Authentication

NTLM (NT LAN Manager) — проприетарная схема Microsoft, часто используемая в Windows-средах для seamless-авторизации. Она основана на challenge-response с хэшированием и не передает пароль напрямую.

Обмен сообщениями сложнее: обычно требуется три этапа (Type 1, Type 2, Type 3). Прокси отвечает Proxy-Authenticate: NTLM (или Negotiate), отправляя challenge. Клиент отвечает Proxy-Authorization: NTLM <base64-encoded message>. NTLM интегрируется с Active Directory и поддерживает single sign-on через текущие учетные данные Windows.

NTLM аутентифицирует соединение, а не отдельный запрос, и требует persistent connections (HTTP keep-alive). Она не может использоваться одновременно для прокси и сервера на одном соединении. По безопасности NTLM лучше Basic, но слабее Kerberos (который часто выбирается через Negotiate). В корпоративных прокси NTLM популярна для прозрачной авторизации без ввода пароля.

Сравнение схем авторизации

Для наглядного сравнения основных характеристик схем приведем следующий список:

1. Basic Authentication. Это самая простая схема, где credentials кодируются в Base64 и отправляются в каждом запросе. Она требует всего двух обменов (challenge и response), совместима со всеми HTTP-клиентами. Однако отсутствие шифрования делает ее уязвимой: пароль легко извлекается при перехвате трафика. Basic подходит для внутренних сетей с TLS, но не рекомендуется для открытых каналов.
2. Digest Authentication. Здесь используется хэширование (MD5 или SHA-256) с nonce для защиты от replay-атак. Клиент вычисляет response на основе challenge от сервера, не передавая пароль. Это повышает безопасность по сравнению с Basic, добавляя mutual authentication в некоторых режимах. Digest требует дополнительных вычислений и раунд-трипов, но остается совместимой и не нуждается в хранении чистого пароля на сервере.
3. NTLM Authentication. Схема ориентирована на Windows, использует многоэтапный handshake (обычно три сообщения) с хэшами на основе challenge. Она поддерживает интеграцию с доменом и SSO, аутентифицируя соединение целиком. NTLM устойчива к простому перехвату, но сложна в реализации вне Microsoft-экосистемы. Минусы — невозможность одновременной авторизации прокси и сервера, зависимость от keep-alive.

Заключение

Выбор схемы авторизации в прокси-серверах зависит от баланса между безопасностью, совместимостью и удобством. Basic проста, но требует обязательного TLS. Digest предлагает хороший компромисс для открытых стандартов. NTLM идеальна в Windows-окружениях с Active Directory. В современных системах рекомендуется комбинировать эти методы с HTTPS и, где возможно, переходить на более продвинутые протоколы вроде Kerberos или OAuth. Правильная настройка авторизации обеспечивает надежную защиту трафика и контроль доступа в корпоративных сетях.

Вопросы и ответы

1. Что такое авторизация в прокси-серверах и зачем она нужна? Авторизация в прокси-серверах — это процесс проверки учетных данных клиента перед тем, как прокси разрешит передачу его запросов к целевым ресурсам в интернете или внутренней сети. В отличие от обычной авторизации на веб-сервере (с кодом 401), прокси использует отдельный механизм с кодом 407 Proxy Authentication Required и специальными заголовками Proxy-Authenticate и Proxy-Authorization. Это позволяет прокси контролировать доступ независимо от конечного сервера.

Такая авторизация необходима в корпоративных сетях для обеспечения безопасности, учета трафика и ограничения доступа сотрудников к определенным ресурсам. Без нее любой клиент в локальной сети мог бы использовать прокси анонимно, что создает риски утечек данных и несанкционированного использования ресурсов.

2. Чем отличается Proxy-Authenticate от WWW-Authenticate? Заголовок Proxy-Authenticate используется прокси-сервером в ответе с кодом 407 и указывает, какие схемы авторизации поддерживает именно прокси. Заголовок WWW-Authenticate, напротив, отправляется конечным веб-сервером при коде 401 и относится к авторизации на самом ресурсе.

Разделение этих заголовков критически важно в цепочках прокси, когда клиент может проходить через несколько посредников. Это позволяет одновременно аутентифицироваться и на прокси, и на целевом сервере, не смешивая учетные данные.

3. Как работает общий механизм challenge-response в прокси? При первом запросе без учетных данных прокси отвечает кодом 407 и заголовком Proxy-Authenticate, содержащим challenge (вызов) — параметры для выбранной схемы. Клиент анализирует этот заголовок, формирует ответ с учетными данными и повторяет запрос, добавляя Proxy-Authorization.

Если данные верны, прокси пропускает трафик. Если нет — снова возвращает 407. Этот механизм позволяет избежать передачи пароля в каждом запросе без необходимости и защищает от несанкционированного доступа.

4. Почему Basic Authentication считается небезопасной? Basic Authentication передает пару «логин:пароль» в Base64-кодировке, которая не является шифрованием и легко декодируется. Любой, кто перехватит трафик, сможет мгновенно получить учетные данные.

Из-за этого Basic рекомендуется использовать только поверх защищенного соединения TLS/SSL. Без шифрования канала схема уязвима к атакам man-in-the-middle и простому прослушиванию сети.

5. В каких случаях всё ещё используют Basic Authentication? Basic продолжают использовать в внутренних защищенных сетях, где весь трафик идет через TLS, и требуется максимальная совместимость. Практически все HTTP-клиенты и библиотеки поддерживают её из коробки.

Также её применяют в простых скриптах и тестах, где безопасность не критична, а важна скорость разработки. В современных системах её постепенно вытесняют более защищенные альтернативы.

6. Как устроен процесс авторизации по схеме Digest? Прокси отправляет challenge с параметрами: realm, nonce, qop и алгоритмом (MD5 или SHA-256). Клиент вычисляет хэш от комбинации логина, пароля, nonce, метода запроса и URI, и отправляет его в Proxy-Authorization.

Сервер выполняет те же вычисления и сравнивает хэши. Nonce защищает от повторного использования ответа (replay-атака). При qop=»auth-int» добавляется проверка целостности тела запроса.

7. Чем Digest лучше Basic? Digest не передает пароль в открытом или легко обратимом виде, а использует одностороннее хэширование. Это делает перехваченные данные бесполезными без знания пароля.

Кроме того, наличие nonce предотвращает replay-атаки, а опциональная mutual authentication позволяет клиенту убедиться в подлинности сервера.

8. Какие недостатки есть у Digest Authentication? Основной недостаток — уязвимость алгоритма MD5 к коллизиям и атакам предвычисления, хотя современные реализации поддерживают SHA-256. Также требуется дополнительный раунд-трип для получения nonce.

На сервере обычно нужно хранить хэши паролей, а не сами пароли, что усложняет миграцию с других систем.

9. Что такое NTLM и в каких средах она чаще всего используется? NTLM (NT LAN Manager) — это проприетарная схема авторизации Microsoft, предназначенная для Windows-сетей. Она широко применяется в корпоративных прокси (например, ISA Server, Forefront TMG, Squid с NTLM) для seamless-авторизации пользователей домена.

Пользователь не вводит логин и пароль вручную — браузер использует текущие учетные данные Windows. Это удобно в Active Directory окружениях.

10. Сколько этапов в NTLM-обмене? Классический NTLM использует три сообщения: Type 1 (Negotiate) от клиента, Type 2 (Challenge) от сервера с nonce, Type 3 (Authenticate) от клиента с вычисленным ответом на challenge.

В некоторых случаях возможен сокращенный обмен, но обычно требуется три этапа. Это делает процесс более сложным по сравнению с Basic и Digest.

11. Почему NTLM аутентифицирует соединение, а не отдельный запрос? NTLM привязана к TCP-соединению и требует keep-alive. После успешной авторизации все последующие запросы по этому соединению считаются аутентифицированными.

Это повышает производительность, но создает проблемы при одновременной авторизации прокси и конечного сервера на одном соединении.

12. Можно ли использовать NTLM вне Windows-экосистемы? Да, но реализация сложна. Существуют открытые библиотеки (например, в Samba и Squid), но они не всегда полностью совместимы.

Вне Windows NTLM теряет главное преимущество — single sign-on, и пользователю приходится вводить учетные данные вручную.

13. Что такое Negotiate и как оно связано с NTLM? Negotiate — это схема-обертка (на основе SPNEGO), которая позволяет клиенту и серверу выбрать лучший доступный протокол: обычно Kerberos или NTLM как fallback.

В Windows-средах браузеры сначала пытаются Kerberos, а если он недоступен — переходят на NTLM. Это обеспечивает максимальную безопасность и совместимость.

14. Почему в современных системах рекомендуют отказываться от NTLM? Microsoft сама рекомендует отключать NTLM в пользу Kerberos там, где это возможно. NTLM имеет известные криптографические слабости и уязвима к pass-the-hash атакам.

Кроме того, она плохо масштабируется в облачных и гибридных средах.

15. Нужно ли использовать TLS при Digest авторизации? Не обязательно, так как пароль не передается в открытом виде. Однако TLS всё равно рекомендуется для защиты остальных данных запроса и ответа.

Без TLS возможны атаки на nonce или подмена challenge.

16. Может ли прокси поддерживать несколько схем авторизации одновременно? Да, прокси может перечислить несколько схем в заголовке Proxy-Authenticate, например: Basic, Digest, NTLM. Клиент выбирает наиболее предпочтительную (обычно самую безопасную из поддерживаемых).

Это полезно в смешанных средах, где часть клиентов Windows, а часть — другие платформы.

17. Как клиент выбирает схему авторизации? Браузеры и HTTP-клиенты имеют встроенный приоритет: сначала Negotiate/Kerberos, затем NTLM, Digest, и в последнюю очередь Basic.

Разработчики могут вручную задать предпочтения в коде приложения.

18. В каких RFC описаны схемы Basic и Digest? Basic Authentication описана в RFC 7617. Digest — в RFC 7616 (обновление более старого RFC 2617). Общий фреймворк HTTP-авторизации — RFC 7235.

NTLM не имеет публичного RFC, так как это проприетарный протокол Microsoft.

19. Можно ли использовать эти схемы для авторизации на конечном сервере, а не только на прокси? Да, все три схемы (Basic, Digest, NTLM/Negotiate) могут использоваться как для прокси (с префиксом Proxy-), так и для обычной серверной авторизации (с WWW-/Authorization).

Разница только в заголовках и коде ответа (407 vs 401).

20. Какой метод авторизации лучше выбрать для нового корпоративного прокси в 2025 году? В 2025 году оптимально использовать Negotiate с Kerberos в Windows-средах — это обеспечивает максимальную безопасность и seamless-опыт. Если нужна кросс-платформенность — Digest с SHA-256 поверх TLS.

Basic стоит избегать без крайней необходимости, а NTLM использовать только как fallback. В идеале переходить на современные протоколы вроде OAuth 2.0 или Mutual TLS для новых систем.