Résumé

  • HTTP 511 indique qu’un équipement doit satisfaire le réseau d’accès avant d’obtenir la connectivité ; il est destiné au mandataire intercepteur, jamais à l’origine demandée.
  • La réponse renvoie vers une ressource de connexion distincte au lieu de présenter un défi sous l’identité de l’origine. Cette précaution limite la confusion sans rendre l’interception fiable ni réparer TLS.

Une réponse émise par la mauvaise autorité

Une application météo rejoint un nouveau réseau et demande un document au service qu’elle connaît. Elle reçoit à la place une page d’hôtel. Les octets arrivent sur son échange HTTP, mais l’hôtel n’est pas l’origine météo et la page n’est pas la réponse attendue.

Un navigateur peut montrer cette anomalie à une personne. Un agenda, une mise à jour logicielle ou une API risque de lire le HTML comme une donnée de l’origine, de le mettre en cache ou de suivre une redirection. Le réseau a remplacé le message d’une autre autorité par sa propre condition.

RFC 6585 a défini en 2012 511 Network Authentication Required. Le client doit interagir pour obtenir l’accès au réseau. Le point décisif est l’émetteur : non pas l’origine nommée dans la requête, mais un mandataire interposé pour contrôler la connectivité.

Admission au réseau et authentification de l’application

Le mot authentification couvre deux relations. Une origine peut demander des identifiants pour une ressource applicative. Un réseau peut exiger paiement, acceptation de conditions ou autre action avant de transporter des paquets. Ces mandats ne se confondent pas.

RFC 6585 dit qu’une origine ne devrait pas produire 511. Elle dispose des mécanismes HTTP d’authentification et d’autorisation. Le 511 décrit une condition du chemin d’accès.

Le portail n’acquiert pas le droit d’imiter le service météo parce qu’il peut bloquer le trafic. L’origine n’est pas responsable du contrat du portail. Le client comprend que changer son mot de passe applicatif ne résoudra probablement pas la branche présente.

Un lien, pas un formulaire empruntant le nom de l’origine

La représentation 511 devrait contenir un lien vers la ressource où l’utilisateur satisfait la condition. Elle ne devrait pas porter elle-même un défi ou une interface de connexion.

Un navigateur affiche la réponse dans le contexte de l’URL demandée. Si l’intercepteur y insère un formulaire, celui-ci peut sembler appartenir à l’origine. Un défi peut pareillement faire croire que le site demande le secret.

Le lien déplace l’interaction vers une ressource dotée de son propre nom. Cette séparation est meilleure, mais ne prouve pas que la cible soit sûre. Le client doit montrer l’hôte, vérifier le certificat TLS et laisser à l’utilisateur la décision d’ouvrir. Le portail ne peut demander que les justificatifs qu’il est autorisé à recevoir.

511 est donc une transmission de contrôle, pas l’achèvement de la requête initiale. Après l’interaction, le client doit reprendre l’opération voulue auprès de la véritable origine.

Les agents non graphiques ont révélé le dommage

RFC 6585 présente 511 comme une limitation des dégâts des portails captifs, surtout pour les logiciels sans navigateur. Il ne les encourage pas.

Une mise à jour qui attend un manifeste peut prendre une page HTML pour des métadonnées corrompues. Un client de synchronisation peut signaler une erreur ou conserver un faux état. La redirection ne restaure pas l’autorité : le logiciel peut la suivre et continuer à interpréter le portail dans le flux de travail d’origine.

Plus HTTP porte de protocoles, plus une substitution générale traverse des frontières que l’opérateur ignore. Un code distinct permet à un client robuste de suspendre l’action sur l’origine au lieu de modifier, stocker ou répéter aveuglément.

Le cache ne doit pas transformer la captivité en état d’origine

RFC 6585 interdit de stocker 511. La condition appartient à un réseau attaché, un état d’admission et un instant. Une réponse mémorisée pourrait suivre le client après l’ouverture de l’accès ou sur un autre réseau, et sembler décrire l’origine.

Seul le système d’admission actuel peut produire un verdict frais. Le cache ne possède aucune autorité pour prolonger l’interception.

TLS refuse l’identité empruntée

Sur HTTP en clair, un intermédiaire peut remplacer la réponse. Sur HTTPS, le client authentifie d’abord le nom du serveur. Le portail ne possède pas le certificat de l’origine demandée ; RFC 6585 rappelle que l’interception produit donc une erreur de certificat.

511 ne peut pas apparaître après une négociation TLS que le portail ne peut conclure honnêtement. Ignorer l’erreur donnerait au réseau l’identité de l’origine, précisément ce que la séparation devait éviter.

L’intermédiaire peut aussi observer des justificatifs HTTP ou perturber les cookies de l’origine. Ces dangers existent avec ou sans 511. Une erreur plus claire ne rend pas le chemin sain.

De l’interception surprise à l’état annoncé

RFC 8952 sépare équipement, service de provisionnement, API, portail utilisateur et dispositif d’application. RFC 8908 définit l’échange API en HTTPS.

Lors de l’attachement, le client reçoit l’URI de l’API au lieu de sonder une origine quelconque en clair. Il valide le certificat du serveur, demande son état captif et obtient un booléen obligatoire ainsi qu’une URL de portail TLS lorsqu’une interaction est nécessaire.

Une fois les conditions satisfaites, il interroge de nouveau l’API pour vérifier la fin de la captivité. Le succès d’un formulaire ou d’une redirection ne suffit pas. L’état doit correspondre au même équipement que celui gouverné par l’application du réseau.

Cette architecture n’abolit pas les portails anciens et l’identifiant entre API et enforcement reste délicat. Elle déplace néanmoins la parole du réseau vers un nom qu’il a le droit d’exploiter, sans faire de l’origine météo une surface de découverte involontaire.

La vérité étroite de 511

511 n’authentifie pas le portail, ne légalise pas l’interception, ne vainc pas TLS et ne prouve pas le consentement d’une personne. Il ne remplace pas 401 ou 403 côté origine. Il peut seulement dire que le chemin d’accès exige une interaction et empêcher cette demande de devenir un contenu d’origine réutilisable.

Le principe durable est simple : un pouvoir doit parler sous son propre nom. Le réseau peut contrôler le transport ; il ne devrait pas emprunter la voix de la destination pour l’expliquer.

Sources