Authentification proxy Basic et Digest
Choisissez une méthode d’authentification prise en charge aux deux extrémités et distinguez un défi Digest d’un transport chiffré.
Dans le Proxy-Authenticate du proxy, lisez le défi avant d’imposer Basic ou Digest. Le client doit prendre en charge une méthode proposée par le service ; sélectionner Digest ne peut pas l’ajouter à un proxy qui ne propose que Basic.
Pour un point de terminaison prenant en charge Digest, curl peut utiliser :
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Utilisez le point de terminaison et le compte réels. Un nom d’utilisateur sans mot de passe permet à curl de le demander. Pour Basic, choisissez --proxy-basic ; l’authentification du serveur d’origine emploie d’autres options. Vérifiez la prise en charge du binaire curl exécuté ainsi que le défi.
| Méthode | Échange d’identifiants | Protection à évaluer |
|---|---|---|
| Basic | Une paire nom d’utilisateur/mot de passe encodée. | L’encodage n’est pas du chiffrement. |
| Digest | Une réponse calculée à partir du défi. | Les algorithmes, les paramètres du défi et l’implémentation du client déterminent la protection ; la méthode ne chiffre pas le contenu des requêtes et réponses. |
Les deux nécessitent toujours un transport adapté entre le client et le proxy. Le HTTPS vers la destination commence trop tard pour protéger une connexion au proxy effectuée auparavant en clair.
Côté serveur, les auxiliaires Digest peuvent exiger des éléments d’identification propres au realm et leur propre format. Un fichier NCSA Basic n’est pas automatiquement un backend Digest. Utilisez le format documenté de l’auxiliaire choisi, puis vérifiez les cas sans identifiants, avec identifiants erronés et avec une requête autorisée, en maintenant les restrictions de source et de destination.