Authentification basique sur HTTPS face à IPsec : ce que chacune protège

Ouvrez les outils de développement, chargez l’application interne et regardez une requête traverser quatre points de contrôle avant que la page ne s’affiche. D’abord le nom se résout, puis une connexion TCP s’ouvre, puis une poignée de main TLS établit qui est le serveur, et seulement ensuite l’application demande qui vous êtes. Traitez ces étapes comme des événements distincts, car chacune échoue avec des preuves différentes et chacune appartient à une équipe différente. L’essentiel de la confusion lors d’un incident vient de lire un 401 comme un problème de tunnel, ou un problème de tunnel comme un mauvais mot de passe.

Point de contrôle un : est-ce bien le serveur auquel vous vouliez parler

La poignée de main TLS répond à cette question avant qu’aucun identifiant ne soit envoyé. Votre client valide la chaîne de certificats auprès d’un magasin de confiance et vérifie que le nom du certificat correspond à l’hôte que vous avez saisi. Si cela échoue, le navigateur affiche une erreur de certificat et n’envoie jamais l’en-tête Authorization. Une demande de mot de passe n’est donc pas la preuve que le serveur est authentique ; c’est la preuve que l’application a répondu.

C’est ici qu’apparaît la première frontière. TLS protège la connexion jusqu’à son point de terminaison. Si un répartiteur de charge termine TLS et transmet du HTTP en clair à l’application, le segment chiffré s’arrête au répartiteur, et les identifiants ne sont protégés que sur ce premier saut.

Point de contrôle deux : ce qui circule réellement dans un échange 401

L’authentification basique HTTP envoie l’identifiant utilisateur et le mot de passe dans un en-tête, encodés en Base64 comme décrit dans la RFC 7617. Authorization: Basic dXNlcjpwYXNz en est la forme ; l’encodage peut être inversé par quiconque peut lire la requête, donc tout le secret vient du transport en dessous. curl -v montre à la fois le défi WWW-Authenticate: Basic et l’en-tête que vous renvoyez.

Cet en-tête indique à l’application qui demande. Il n’indique pas au réseau qui peut se connecter, et il ne chiffre rien par lui-même. L’application doit encore vérifier l’identifiant auprès d’un magasin et décider ce que ce compte peut faire, ce qui est de l’autorisation et se produit après l’authentification.

Où se situe le tunnel IPsec dans ce chemin

Remontez maintenant vers l’extérieur depuis le navigateur. Un tunnel IPsec de passerelle à passerelle protège le trafic sélectionné entre deux passerelles de sécurité, pas entre votre ordinateur portable et le processus de l’application. L’ESP en mode tunnel encapsule le paquet d’origine, les passerelles le chiffrent et l’authentifient, et les adresses internes survivent pour que le côté distant puisse router la requête vers l’application.

La sélection est la partie qui fait trébucher les gens. Les tunnels basés sur des politiques utilisent des sélecteurs de trafic, souvent exprimés sous forme de listes de contrôle d’accès, pour décider quels paquets entrent dans le tunnel. Les tunnels basés sur des routes utilisent à la place une interface virtuelle et la table de routage. Sous Linux, ip xfrm policy affiche les sélecteurs et ip xfrm state les associations de sécurité établies ; sur un appareil pare-feu, l’équivalent est la table SA du tunnel plus un traceur de paquets.

La conséquence mérite d’être dite clairement. Un paquet peut se trouver dans un tunnel parfaitement sain et transporter malgré tout une requête HTTPS que l’application rejette, et des identifiants valides peuvent arriver par un chemin sans aucun tunnel si le routage le permet.

Lisez la panne à la couche qui l’a signalée

Un 401 signifie que l’application n’a pas accepté l’identifiant. Un 403 signifie qu’elle a accepté l’identité et refusé l’opération. Une erreur TLS signifie que le client n’a pas accepté le serveur. Aucune route ou un décalage de politique signifie que le paquet n’a jamais atteint la passerelle distante. Quatre pannes différentes, quatre propriétaires différents, et aucune d’elles ne se diagnostique en fixant le formulaire de connexion.

Utilisez les preuves que chaque couche produit : le panneau réseau du navigateur pour les statuts et les en-têtes, openssl s_client -connect host:443 pour la chaîne de certificats, les compteurs SA et les journaux de la passerelle pour le trafic du tunnel, et le journal de l’application pour la décision de compte. Quand deux couches signalent des erreurs en même temps, corrigez d’abord la plus basse, car un tunnel mort peut facilement masquer un échec d’authentification et inversement.

Cartographiez un service de bout en bout

Écrivez cinq lignes pour le service que vous dépannez : quels pairs le tunnel relie, quels sous-réseaux et ports les sélecteurs autorisent, où TLS se termine et quelle identité le certificat affirme, quel compte et quel rôle d’application sont utilisés, et où chaque couche journalise. Gardez-les sur une seule page, car l’intérêt de la carte est de montrer où la responsabilité d’une couche finit et où la suivante commence.

Testez ensuite un cas négatif par couche. Utilisez un mauvais mot de passe et confirmez que vous obtenez un 401, pas un délai d’attente. Connectez-vous depuis un sous-réseau hors des sélecteurs et confirmez que le paquet n’est pas acheminé dans le tunnel. Présentez un certificat pour le mauvais nom et confirmez que le client refuse avant d’envoyer des identifiants. Ces trois résultats vous en disent plus sur la conception que n’importe quel schéma de boîtes.

Enfin, décidez délibérément quelle protection chaque relation exige. L’authentification basique sur TLS est un choix raisonnable pour un petit outil interne derrière une passerelle ; elle ne remplace ni l’autorisation par utilisateur ni la protection du trafic au-delà du point de terminaison TLS. Le tunnel protège le chemin, le certificat protège le saut, et le 401 protège le compte, et seul le dernier sait qui vous êtes.