Summary

  • L'écoute HTTP de RFC 10011 répond à un cas précis : TLS est terminé par un composant externe. Elle ne légitime pas l'exposition publique d'un service RESTCONF en clair.
  • Le RFC dit que le périmètre de sécurité s'étend au terminateur. Déclarer une adresse, un nombre de relais ou un en-tête de certificat décrit l'architecture voulue, sans attester le chemin réellement emprunté.
  • Daniel Kade propose un reçu de frontière TLS reliant l'authentification externe, l'hygiène des en-têtes, l'accès au serveur et la décision NACM, avec des références et des empreintes plutôt que des secrets.

Une frontière que l'on ne peut pas sous-traiter

Une équipe réseau gère le répartiteur. Une équipe identité choisit les autorités de confiance. Une équipe d'exploitation maintient le serveur RESTCONF. Une quatrième administre NACM. Chacune peut produire un indicateur vert et, pourtant, aucune ne peut prouver seule qu'une opération de configuration a été autorisée au nom du bon pair.

Le problème apparaît au point où TLS est déchiffré. Le répartiteur connaît la session externe et, éventuellement, le certificat client. Le serveur RESTCONF reçoit une requête HTTP et une identité déjà transformée. La confiance doit franchir ce changement de support sans devenir une simple chaîne de caractères que n'importe quel chemin interne pourrait injecter.

RFC 10011 rend cette réalité visible dans un modèle de configuration. Il définit les modules ietf-restconf-client et ietf-restconf-server, pour les connexions ordinaires comme pour Call Home. HTTPS reste le transport requis par RESTCONF. L'option HTTP n'existe que pour le cas où un terminateur TLS se trouve en amont. Dans ce montage, précise le texte, le périmètre de sécurité s'étend jusqu'au terminateur.

Il ne s'agit donc ni d'une dispense ni d'un raccourci sémantique. C'est un transfert de responsabilités.

Le mot « HTTP » ne suffit pas à décrire le risque

RFC 8040 interdit l'usage de RESTCONF sur HTTP sans TLS. RFC 10011 ne contredit pas cette règle lorsqu'il permet à un serveur de recevoir HTTP derrière un terminateur. La connexion exposée reste protégée ; c'est l'emplacement de la terminaison qui change.

Qualifier toute liaison interne en clair de non conforme serait tout aussi imprécis que de la déclarer sûre par nature. Le modèle accepte l'architecture externe. La question de gouvernance porte sur les garanties placées entre le point de terminaison et le processus qui agit : isolation, origine autorisée, traitement des en-têtes, nombre de relais, traçabilité et refus des chemins de contournement.

Le bénéfice opérationnel est réel. Une terminaison centralisée simplifie le renouvellement des certificats et l'absorption des connexions. Son coût institutionnel est une dépendance supplémentaire : celui qui contrôle l'authentification n'est plus nécessairement celui qui applique l'autorisation.

external-endpoint est une déclaration, pas un témoin

Dans le modèle serveur, le conteneur external-endpoint permet de décrire l'adresse et le port visibles, le trusted-proxy-count et le champ client-cert-var. Ce dernier indique le nom de l'en-tête HTTP par lequel le terminateur peut relayer un certificat client ; X-Client-Cert est donné comme exemple. Le champ demeure facultatif, puisque RESTCONF peut authentifier autrement.

Cette précision est bienvenue. Elle permet à l'automatisation de savoir que le serveur ne termine pas lui-même TLS. Mais aucun de ces paramètres ne rend compte d'une transaction en cours.

Une adresse configurée n'établit pas que la requête est passée par cette adresse. Un compte de mandataires ne mesure pas les sauts présents. Un nom d'en-tête ne prouve pas que les valeurs fournies par le client ont été supprimées, que le terminateur a réécrit le champ, ni que le certificat transporté a été validé sur la session correspondante.

La distinction rejoint la primauté du code en fonctionnement : une intention de configuration doit être rapprochée de l'état chargé et du comportement observé. Le modèle fournit le vocabulaire commun ; il ne fabrique pas l'observation.

L'identité change de mains

Lorsque le serveur traite directement TLS, il peut lier le pair authentifié au canal qui transporte la requête. Après terminaison externe, cette liaison doit être reconstruite. Le composant frontal produit une affirmation ; le serveur en consomme une représentation.

Plusieurs décisions se cachent dans ce relais. Quelle partie du certificat devient le nom RESTCONF ? Les variantes de casse ou d'encodage sont-elles normalisées ? Une identité absente conduit-elle à un refus ? Les en-têtes homonymes venant de l'extérieur sont-ils systématiquement effacés ? Seuls des processus ou adresses approuvés peuvent-ils atteindre l'écoute interne ? Une nouvelle tentative conserve-t-elle un identifiant qui remonte à la session TLS d'origine ?

NACM, défini par RFC 8341, autorise des opérations à partir d'un nom d'utilisateur authentifié. Il peut exécuter fidèlement une excellente politique sur une identité mal attribuée. Le résultat NACM n'atteste pas rétrospectivement la qualité du relais.

Call Home ajoute une subtilité. RFC 8071 inverse l'initiateur TCP, pas les rôles TLS et RESTCONF. Le client RESTCONF continue de valider le certificat du serveur. Le fait qu'un équipement appelle vers le centre n'est donc pas une preuve d'identité ; le terminateur placé au point d'écoute doit préserver les rôles du protocole.

Le chemin aval fait partie de la promesse

« Réseau interne » n'est pas une propriété de sécurité vérifiable. Entre le répartiteur et RESTCONF, il peut exister un segment dédié, un maillage de services, une protection mutuelle, une socket locale ou un réseau partagé. La solution technique peut varier ; la déclaration de sécurité doit citer celle qui est réellement employée.

La souveraineté pratique se mesure ici à la maîtrise des dépendances. Posséder la clé du service ne donne pas le contrôle d'un proxy administré ailleurs. Posséder la politique NACM ne permet pas de savoir qui peut atteindre le port interne. La chaîne est aussi forte que la capacité des propriétaires à réunir leurs preuves.

Les modèles de truststore, de keystore et de clients/serveurs TLS des RFC 9641, 9642 et 9645 améliorent la description des ancres, certificats et identités. Ils ne disent pas quelle révision le processus actif a chargée, ni quelle affirmation a accompagné une requête donnée.

Le reçu de frontière TLS

Je propose un reçu de frontière TLS par point RESTCONF terminé à l'extérieur. C'est une règle éditoriale de gouvernance, non une prescription de RFC 10011.

Le reçu commence par la limite déclarée : point externe, rôle, version de configuration, chaîne de mandataires attendue et propriétaires. Il référence la politique de confiance, l'identité du certificat du terminateur, la méthode d'authentification client et leur état de rotation. Les clés, jetons et configurations complètes n'y figurent jamais.

Une deuxième section fixe le contrat d'identité : champs autorisés, règle de transformation, suppression des valeurs entrantes, écrasement par le terminateur, comportement en cas de doublon ou d'absence. Elle distingue le certificat observé à l'extérieur de l'attribut livré au serveur.

La troisième décrit le contrôle aval : sources autorisées, protection appliquée, nombre de relais attendu et résultat d'un test de contournement. Des identifiants de politique et des empreintes suffisent ; publier les adresses privées ou les règles intégrales créerait un nouveau risque.

Enfin, un identifiant de trace rapproche l'événement TLS, la requête interne, le nom RESTCONF dérivé et la décision NACM. Horodatage, versions de logiciel et de politique, résultat de validation et empreintes de journaux rendent la chaîne contrôlable. Le contenu de la requête de gestion reste hors du reçu.

Vérifier les jointures

Un scanner TLS teste le bord. Une lecture YANG teste l'état déclaré. Un essai NACM teste une identité. L'architecture n'est démontrée que par des tests qui traversent les jointures.

Il faut présenter l'en-tête protégé depuis une origine non approuvée et vérifier son rejet ; utiliser un certificat de faible privilège et observer l'identité exacte reçue ; tenter d'atteindre directement le serveur ; modifier le nombre de relais ; faire échouer l'authentification externe et confirmer qu'aucune requête aval correspondante n'existe. Les chemins de secours, anciens répartiteurs et interfaces de maintenance méritent leurs propres essais.

Les libellés d'assurance doivent rester proportionnés : « TLS externe validé », « relais d'identité accepté d'un terminateur approuvé », « accès direct refusé », « décision NACM corrélée ». « RESTCONF sécurisé » n'est défendable que si la couverture de cette chaîne est connue.

La vertu de RFC 10011 est de ne pas masquer l'architecture derrière le cadenas TLS. Il admet que le chiffrement s'arrête à un endroit ; la responsabilité, elle, doit continuer jusqu'à l'action.

Sources

  1. Lu Heng — Souveraineté des données : réalités techniques et pratiques
  2. Lu Heng — Pourquoi BTW Media existe
  3. Lu Heng — Primauté du code en fonctionnement
  4. IANA — Paramètres YANG
  5. RFC 10011 — Modèle YANG pour clients et serveurs RESTCONF
  6. RFC 8040 — Protocole RESTCONF
  7. RFC 8071 — NETCONF et RESTCONF Call Home
  8. RFC 8341 — Modèle de contrôle d'accès à la configuration réseau
  9. RFC 8342 — Architecture des magasins de données de gestion réseau
  10. RFC 8446 — TLS 1.3
  11. RFC 9000 — QUIC
  12. RFC 9110 — Sémantique HTTP
  13. RFC 9641 — Modèle YANG de truststore
  14. RFC 9642 — Modèle YANG de keystore
  15. RFC 9645 — Groupements YANG pour TLS
  16. RFC 10009 — Groupements YANG pour HTTP