Проксі-автентифікація 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. Використовуйте документований формат вибраної програми, потім перевірте відсутність облікових даних, неправильні дані та авторизований запит, зберігаючи обмеження джерела й адресата.