Basic- und Digest-Authentifizierung am Proxy
Wähle eine von beiden Seiten unterstützte Proxy-Authentifizierung und unterscheide eine Digest-Challenge von verschlüsseltem Transport.
Lies die Proxy-Authenticate-Challenge des Proxys, bevor du Basic oder Digest erzwingst. Der Client muss eine vom Dienst angebotene Methode unterstützen; die Auswahl von Digest kann diese Methode einem reinen Basic-Proxy nicht hinzufügen.
Für einen Endpunkt mit Digest-Unterstützung kann curl Folgendes verwenden:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Verwende den tatsächlichen Endpunkt und das echte Konto. Ein Benutzername ohne Passwort erlaubt curl, danach zu fragen. Für Basic wählst du --proxy-basic; die Authentifizierung am Ursprungsserver verwendet andere Optionen. Prüfe neben der Challenge auch die Unterstützung des tatsächlich ausgeführten curl-Builds.
| Methode | Austausch der Zugangsdaten | Zu bewertender Schutz |
|---|---|---|
| Basic | Ein kodiertes Paar aus Benutzername und Passwort. | Die Kodierung ist keine Verschlüsselung. |
| Digest | Eine aus der Challenge abgeleitete Antwort. | Algorithmen, Challenge-Parameter und Clientimplementierung bestimmen den Schutz; Anfrage- und Antwortinhalte bleiben durch diese Methode unverschlüsselt. |
Beide benötigen weiterhin einen geeigneten Transport vom Client zum Proxy. HTTPS zum Ziel beginnt zu spät, um eine vorherige unverschlüsselte Proxyanmeldung zu schützen.
Auf dem Server können Digest-Hilfsprogramme realm-spezifisches Zugangsdatenmaterial und ein eigenes Format verlangen. Eine Basic-NCSA-Datei ist nicht automatisch ein Digest-Backend. Verwende das dokumentierte Format des gewählten Hilfsprogramms und prüfe anschließend fehlende Zugangsdaten, falsche Zugangsdaten und eine berechtigte Anfrage, während Quell- und Zielbeschränkungen wirksam bleiben.