Basisauthentifizierung über HTTPS gegenüber IPsec: Was jede Schicht schützt

Öffnen Sie die Entwicklerwerkzeuge, laden Sie die interne Anwendung und beobachten Sie, wie eine Anfrage vier Kontrollpunkte durchläuft, bevor die Seite gerendert wird. Zuerst wird der Name aufgelöst, dann öffnet sich eine TCP-Verbindung, dann stellt ein TLS-Handshake fest, wer der Server ist, und erst danach fragt die Anwendung, wer Sie sind. Behandeln Sie diese als getrennte Ereignisse, denn jedes scheitert mit anderen Beweisen und jedes gehört zu einem anderen Team. Die meiste Verwirrung bei Störungen entsteht daraus, eine 401 als Tunnelproblem zu lesen oder ein Tunnelproblem als schlechtes Passwort.

Kontrollpunkt eins: Ist dies der Server, mit dem Sie sprechen wollten

Der TLS-Handshake beantwortet diese Frage, bevor irgendein Anmeldedatum gesendet wird. Ihr Client prüft die Zertifikatskette gegen einen Vertrauensspeicher und kontrolliert, ob der Name im Zertifikat zum eingegebenen Host passt. Wenn das fehlschlägt, zeigt der Browser einen Zertifikatsfehler und sendet den Authorization-Header überhaupt nicht. Eine Passwortabfrage ist daher kein Beweis dafür, dass der Server echt ist; sie beweist, dass die Anwendung geantwortet hat.

Hier erscheint die erste Grenze. TLS schützt die Verbindung bis zu ihrem Beendigungspunkt. Wenn ein Lastverteiler TLS beendet und einfaches HTTP an die Anwendung weiterleitet, endet das verschlüsselte Segment am Lastverteiler, und die Anmeldedaten sind nur auf dem ersten Sprung geschützt.

Kontrollpunkt zwei: Was in einem 401-Austausch tatsächlich übertragen wird

HTTP-Basisauthentifizierung sendet die Benutzerkennung und das Passwort in einem Header, kodiert mit Base64, wie in RFC 7617 beschrieben. Authorization: Basic dXNlcjpwYXNz ist die Form; die Kodierung kann jeder umkehren, der die Anfrage lesen kann, also kommt die gesamte Geheimhaltung vom Transport darunter. curl -v zeigt sowohl die WWW-Authenticate: Basic-Aufforderung als auch den Header, den Sie zurücksenden.

Dieser Header sagt der Anwendung, wer fragt. Er sagt dem Netzwerk nicht, wer sich verbinden darf, und verschlüsselt selbst nichts. Die Anwendung muss die Anmeldedaten weiterhin gegen einen Speicher prüfen und entscheiden, was dieses Konto darf; das ist Autorisierung und geschieht nach der Authentifizierung.

Wo der IPsec-Tunnel in diesem Pfad liegt

Gehen Sie nun vom Browser nach außen. Ein IPsec-Tunnel zwischen zwei Gateways schützt ausgewählten Verkehr zwischen zwei Sicherheitsgateways, nicht zwischen Ihrem Laptop und dem Anwendungsprozess. ESP im Tunnelmodus verpackt das ursprüngliche Paket, die Gateways verschlüsseln und authentifizieren es, und die inneren Adressen bleiben erhalten, damit die Gegenseite die Anfrage an die Anwendung weiterleiten kann.

Die Auswahl ist der Teil, über den Menschen stolpern. Richtlinienbasierte Tunnel verwenden Verkehrsselektoren, oft als Zugriffskontrolllisten ausgedrückt, um zu entscheiden, welche Pakete in den Tunnel gelangen. Routenbasierte Tunnel verwenden stattdessen eine virtuelle Schnittstelle und die Routing-Tabelle. Unter Linux zeigt ip xfrm policy die Selektoren und ip xfrm state die eingerichteten Sicherheitsassoziationen; auf einer Firewall-Appliance ist das Äquivalent die SA-Tabelle des Tunnels plus ein Paket-Tracer.

Die Konsequenz verdient eine klare Aussage. Ein Paket kann in einem völlig gesunden Tunnel sitzen und dennoch eine HTTPS-Anfrage tragen, die die Anwendung ablehnt, und gültige Anmeldedaten können über einen Pfad ohne jeglichen Tunnel ankommen, wenn das Routing es zulässt.

Lesen Sie den Fehler auf der Schicht, die ihn gemeldet hat

Eine 401 bedeutet, dass die Anwendung die Anmeldedaten nicht akzeptiert hat. Eine 403 bedeutet, dass sie die Identität akzeptiert und die Operation verweigert hat. Ein TLS-Fehler bedeutet, dass der Client den Server nicht akzeptiert hat. Keine Route oder eine Richtlinienabweichung bedeutet, dass das Paket das entfernte Gateway nie erreicht hat. Vier verschiedene Fehler, vier verschiedene Zuständige, und keiner davon wird diagnostiziert, indem man das Anmeldeformular anstarrt.

Nutzen Sie die Beweise, die jede Schicht erzeugt: das Netzwerkpanel des Browsers für Status und Header, openssl s_client -connect host:443 für die Zertifikatskette, die SA-Zähler und Protokolle des Gateways für den Tunnelverkehr und das Anwendungsprotokoll für die Kontoentscheidung. Wenn zwei Schichten gleichzeitig Fehler melden, beheben Sie zuerst die untere, denn ein toter Tunnel kann einen Authentifizierungsfehler leicht verdecken und umgekehrt.

Eine Dienstleistung von Ende zu Ende abbilden

Schreiben Sie fünf Zeilen für den Dienst, den Sie untersuchen: welche Gegenstellen der Tunnel verbindet, welche Subnetze und Ports die Selektoren zulassen, wo TLS endet und welche Identität das Zertifikat behauptet, welches Anwendungskonto und welche Rolle verwendet werden und wo jede Schicht protokolliert. Halten Sie sie auf einer Seite, denn der Sinn der Karte ist zu zeigen, wo die Verantwortung einer Schicht endet und die nächste beginnt.

Testen Sie dann einen Negativfall pro Schicht. Verwenden Sie ein falsches Passwort und bestätigen Sie, dass Sie eine 401 erhalten, keine Zeitüberschreitung. Verbinden Sie sich aus einem Subnetz außerhalb der Selektoren und bestätigen Sie, dass das Paket nicht durch den Tunnel geht. Zeigen Sie ein Zertifikat für den falschen Namen vor und bestätigen Sie, dass der Client ablehnt, bevor er Anmeldedaten sendet. Diese drei Ergebnisse sagen Ihnen mehr über das Design als jedes Kästchendiagramm.

Entscheiden Sie schließlich bewusst, welchen Schutz jede Beziehung braucht. Basisauthentifizierung über TLS ist eine vernünftige Wahl für ein kleines internes Werkzeug hinter einem Gateway; sie ersetzt weder die Autorisierung pro Benutzer noch den Schutz des Verkehrs jenseits des TLS-Endpunkts. Der Tunnel schützt den Weg, das Zertifikat schützt den Sprung, und die 401 schützt das Konto, und nur die letzte weiß, wer Sie sind.