Прокси-аутентификация Basic и Digest
Выберите метод аутентификации, поддерживаемый обеими сторонами, и отличайте запрос Digest от шифрованного транспорта.
Прежде чем принудительно выбирать Basic или Digest, прочтите в Proxy-Authenticate прокси запрос аутентификации. Клиент должен поддерживать метод, предлагаемый сервисом; выбор Digest не добавит его прокси, поддерживающему только Basic.
Для адреса прокси с поддержкой Digest в curl можно использовать:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Укажите настоящий адрес и учётную запись. Имя пользователя без пароля позволяет curl запросить его. Для Basic выберите --proxy-basic; аутентификация на исходном сервере использует другие параметры. Проверьте не только запрос аутентификации, но и поддержку в реально запускаемой сборке curl.
| Метод | Обмен учётными данными | Какую защиту оценить |
|---|---|---|
| Basic | Закодированная пара имени пользователя и пароля. | Кодирование не является шифрованием. |
| Digest | Ответ, вычисленный на основе запроса аутентификации. | Защита определяется алгоритмами, параметрами запроса аутентификации и реализацией клиента; сам метод не шифрует содержимое запросов и ответов. |
Обоим по-прежнему нужен подходящий транспорт от клиента к прокси. HTTPS к адресату начинается слишком поздно, чтобы защитить предшествующий вход на прокси открытым текстом.
На сервере вспомогательные программы Digest могут требовать данные учётных записей для конкретного realm и собственный формат. Файл NCSA для Basic не становится автоматически бэкендом Digest. Используйте документированный формат выбранной программы, затем проверьте отсутствие учётных данных, неверные данные и разрешённый запрос, сохраняя ограничения источника и адресата.