Résumé

  • Une configuration valide et une configuration effectivement appliquée constituent deux objets de preuve distincts. L’architecture de gestion distingue explicitement l’intention de l’état opérationnel ; même leur concordance ne démontre pas qu’une tentative de connexion a réussi. RFC 8342, sections 5.1.4 et 5.3.
  • L’acceptation du relais, l’authentification du serveur et l’exécution d’une opération ne sont pas interchangeables. La conclusion de disponibilité doit être limitée à une identité, une destination, un chemin, une opération et une période observés, plutôt qu’étendue à tout le service à partir d’un succès intermédiaire. Cette distinction découle notamment des fonctions séparées de SOCKS5 et de l’authentification TLS.

Le mauvais feu vert est donné avant la première connexion

La décision fautive consiste à clore une mise en service dès que l’outil de gestion accepte le choix du proxy. L’exploitant dispose alors d’une description du chemin souhaité. Il lui manque encore l’observation permettant d’affirmer que ce chemin conduit au bon interlocuteur et permet l’usage attendu. Même en tenant la validation de la configuration pour acquise, le saut logique demeure entier.

Les modules ietf-tcp-common, ietf-tcp-client et ietf-tcp-server portent respectivement tcp-common-grouping, tcp-client-grouping et tcp-server-grouping : paramètres communs, connexion cliente et écoute serveur. Ils ne définissent ni nœuds config false, ni actions ou notifications de résultat. RFC 9643, sections 2 à 5.

Cette portée restreinte n’est pas une lacune cachée. Un groupement YANG est une structure réutilisable ; sa définition ne crée pas, à elle seule, de nœuds dans l’arbre du modèle. Un module consommateur l’instancie avec uses. Les fonctionnalités conditionnelles délimitent par ailleurs les éléments pris en charge par une implémentation : une possibilité décrite dans une norme n’est pas automatiquement disponible dans chaque produit. RFC 7950, sections 7.12, 7.13 et 7.20.

Pour une direction d’infrastructure, demander « la configuration est-elle conforme ? » reste nécessaire, mais ne répond pas à « le service est-il utilisable ? ». Le premier contrôle concerne une description et ses contraintes. Le second exige une observation de l’exécution. Aucun verdict global ne devrait effacer cette différence.

L’intention doit être rapprochée de ce qui est réellement utilisé

Lorsque la gestion passe par NETCONF, il faut d’abord identifier l’opération réussie. <validate> examine une configuration ; <edit-config> modifie le magasin désigné ; lorsque la capacité correspondante est disponible, <commit> fait de la configuration candidate la nouvelle configuration courante. Un <ok/> répond à l’opération de gestion concernée : il ne rapporte pas le succès d’une transaction vers une application distante. RFC 6241, sections 4.4, 7.2, 8.3 et 8.6.

L’architecture NMDA précise ensuite la différence entre magasins. <running> contient la configuration courante, qui peut nécessiter des transformations. <intended> représente celle que le système cherche à appliquer après ces transformations. <operational> rassemble les valeurs effectivement utilisées et l’état du système. Une ressource absente peut empêcher l’application ; une ancienne configuration peut aussi subsister temporairement pendant la libération de ses ressources. RFC 8342, sections 5.1.3 à 5.3.2.

L’absence de nœuds config false dans les groupements TCP ne signifie donc pas que leurs valeurs de configuration seraient exclues de l’état opérationnel. Celui-ci comprend aussi des données de configuration. Il faut distinguer cette présence des éventuelles informations supplémentaires sur une connexion ou une transaction. RFC 8342, section 5.3.

La règle d’exploitation proposée consiste à conserver deux constats séparés : la version voulue a été acceptée ; les valeurs nécessaires à l’usage sont effectivement appliquées. La tentative de connexion doit ensuite être rattachée à cette version. Un test réussi mais impossible à associer au changement ne valide pas ce changement. Une session ouverte avant la modification ne devrait pas servir, sans vérification supplémentaire, à qualifier le nouveau chemin.

Deux destinations qu’il ne faut pas confondre

Le proxy reste facultatif. Dans tcp-client-grouping, remote-address vise la cible ; sous proxy-server, son homonyme vise le relais. Le port du proxy vaut 1080 par défaut ; le port cible n’a pas de défaut dans ce groupement. SOCKS4, SOCKS4a et SOCKS5 sont des choix conditionnés par des fonctionnalités YANG. RFC 9643, section 3.

Cette séparation devrait se retrouver dans les preuves conservées. L’équipe réseau doit pouvoir expliquer quelle destination a été demandée et quel relais a été joint, plutôt que présenter une seule adresse comme la preuve de tout le parcours. Le nom configuré, l’adresse effectivement utilisée et l’identité attendue du service méritent des champs distincts dans le dossier.

SOCKS5 distingue dans sa requête les destinations IPv4, IPv6 et les noms de domaine. RFC 1928, sections 4 et 5. Il convient donc de conserver ce qui a réellement été transmis. Lorsqu’un nom a été confié au relais, une résolution effectuée depuis le poste d’administration ne suffit pas à établir l’adresse finalement jointe par celui-ci.

Si cette information n’est pas accessible, la conclusion doit garder cette limite. Un résultat de résolution supposé ne devrait pas compléter artificiellement un dossier incomplet. Inversement, constater une opération réussie ne nécessite pas de capturer chaque segment : il faut surtout éviter d’attribuer ce succès à un chemin dont l’usage n’a pas été suffisamment documenté.

Au relais, l’authentification ne vaut pas autorisation

Dans la branche SOCKS5, le conteneur facultatif authentication-parameters choisit GSS-API ou identifiant et mot de passe. Le conteneur GSS-API reste vide, destiné à des compléments. RFC 9643, section 3.3.

L’échange commence par TCP vers le proxy. Le client propose des méthodes ; le serveur en sélectionne une. La valeur 0xff impose la fermeture faute de méthode acceptable. Après la sous-négociation éventuelle, CONNECT demande l’accès à la destination. Le protocole prévoit aussi une méthode sans authentification supplémentaire. RFC 1928, sections 3 et 4.

Un conteneur absent n’est donc pas un compte rendu de négociation. Pour conclure sur la sécurité du parcours, l’exploitant devrait rapprocher la méthode observée de la politique approuvée. La seule configuration ne permet pas de remplacer ce contrôle par une supposition sur le comportement effectif.

Avec l’identifiant et le mot de passe, le statut 0x00 indique le succès de la sous-négociation d’authentification. Il ne constitue pas encore la décision de relais vers la cible. La spécification précise également que cette méthode transporte le mot de passe en clair. RFC 1929, sections 2 et 3.

Le stockage et le transport doivent être examinés séparément. password-grouping permet notamment de représenter un mot de passe chiffré dans les données de configuration ; cette représentation ne change pas le format de l’échange SOCKS. Un TLS établi ensuite avec l’application ne protège pas rétroactivement les justificatifs déjà envoyés au relais. RFC 9640, section 2.1.4.2 ; RFC 1929, section 3.

GSS-API appelle d’autres observations : établissement du contexte de sécurité, puis niveau de protection négocié. La méthode SOCKS correspondante distingue notamment l’intégrité seule de l’intégrité accompagnée de confidentialité. Le nom de la méthode ne démontre donc pas que tous les messages bénéficient des deux protections. RFC 1961, sections 3 à 5.

Les responsabilités devraient suivre ces différences. Le gestionnaire des identités rend les justificatifs utilisables. Le responsable de la sécurité approuve les protections exigées. L’administrateur du proxy décide des accès permis. Aucun de ces contrôles, considéré isolément, ne permet encore d’attester le bon fonctionnement de l’application distante.

Une connexion TCP peut s’arrêter au mauvais niveau de preuve

Dans la réponse SOCKS5, REP=0x00 signale un succès, 0x02 un refus par les règles et 0x05 une connexion refusée. Pour CONNECT, BND.ADDR et BND.PORT décrivent l’extrémité utilisée par le relais pour sa connexion sortante, non l’identité cryptographique de la cible. RFC 1928, section 6.

L’établissement TCP observé localement concerne le proxy ; celui-ci établit la connexion vers la cible. RFC 1928, section 3. Le succès annoncé par le relais est une information utile. L’exploitant doit toutefois préciser s’il possède seulement cette annonce ou également une observation de la connexion sortante.

TCP fournit un flux d’octets fiable et ordonné. L’établissement de ce transport ne constitue ni une authentification du service applicatif ni un résultat de traitement métier. RFC 9293, sections 2.2 et 3.5.

Il convient donc de ne pas demander au mauvais instrument la bonne conclusion. Une observation côté client documente ce qu’elle peut voir ; elle ne doit pas être présentée comme une observation directe de l’ensemble du parcours. La décision de relais et la réponse de l’application doivent rester identifiables séparément, avec leur provenance et leur portée.

Les sondes TCP ne remplacent pas une opération utile

Les paramètres idle-time, max-probes et probe-interval règlent les sondes TCP. Le délai de détection décrit est approximativement idle-time + max-probes × probe-interval, pas une échéance applicative. RFC 9643, section 2.3.

Lorsqu’une implémentation TCP propose ces sondes, elles doivent être désactivées par défaut et contrôlables par connexion. L’intervalle d’inactivité doit être configurable, avec un défaut d’au moins deux heures. L’absence de réponse à une sonde isolée ne doit pas suffire à déclarer la connexion morte. Les sondes sollicitent le correspondant TCP, pas une opération métier. RFC 9293, section 3.8.4.

Pour le client connecté au relais, une réponse de la pile TCP du proxy ne prouve donc pas la progression d’un traitement distant. C’est une conséquence de la portée du test, non une anomalie du mécanisme.

La décision pratique consiste à séparer la récupération des ressources d’une connexion abandonnée et la surveillance de l’usage attendu. Accélérer les sondes ne transforme pas le premier contrôle en second. Le propriétaire de l’application devrait définir ce qui constitue un progrès observable et à partir de quelle attente l’usage devient inacceptable, sans emprunter automatiquement les délais du transport.

SSH et TLS ouvrent une autre chaîne de vérification

Lorsque l’usage impose SSH ou TLS, la question suivante est celle de l’interlocuteur authentifié. La RFC 9644 distingue l’identité du client SSH des paramètres employés pour authentifier le serveur, notamment les clés d’hôte et les certificats de confiance. Il s’agit bien de deux questions : à qui le client parle-t-il, et sous quelle identité demande-t-il un accès ? RFC 9644, section 3.1.2.1.

Dans l’échange SSH à signature décrit par la RFC 4253, le client vérifie l’association de la clé d’hôte au serveur ainsi que la signature de l’échange. Lire une bannière SSH n’accomplit pas ces vérifications. Le texte avertit qu’accepter une clé sans vérifier son authenticité rend le protocole vulnérable aux attaques actives. RFC 4253, sections 4.2 et 8.

Pour TLS, les groupements de la RFC 9645 prévoient plusieurs formes d’authentification du serveur, dont les certificats, les clés publiques brutes et certaines clés prépartagées. Le dossier devrait enregistrer le mode effectivement utilisé ; tous les succès TLS ne supposent pas la présentation d’un certificat. RFC 9645, section 3.

Lorsqu’un serveur TLS 1.3 s’authentifie par certificat, CertificateVerify apporte une preuve de possession de la clé privée correspondante. La vérification de Finished authentifie l’échange et confirme les clés calculées. Ces résultats ne se déduisent pas de la présence d’un certificat dans une configuration. RFC 8446, sections 4.4.3 et 4.4.4.

Avec une authentification par certificat, il reste à faire correspondre l’identité présentée au service attendu. La RFC 9525 impose de construire les identifiants de référence indépendamment de ceux présentés par le serveur. Une information découverte en chemin ne devient pas automatiquement une nouvelle référence de confiance. RFC 9525, sections 6.1 et 6.2.

La conséquence opérationnelle est claire : la confiance accordée au relais ne doit pas remplacer celle exigée pour la cible. Dans une architecture où TLS se termine délibérément sur un intermédiaire, le dossier doit nommer cet interlocuteur. La preuve d’authentification obtenue par le client ne doit pas être étendue à un serveur situé au-delà sans justification supplémentaire.

La disponibilité se décide au niveau de l’opération

Même avec un serveur authentifié, il reste à déterminer si l’usage demandé est possible. Le propriétaire applicatif devrait préciser le compte utilisé, les droits nécessaires, l’opération représentative, le résultat acceptable et le délai. Une lecture réussie ne valide pas, par simple extension logique, une écriture ou un traitement différé.

NETCONF permet d’illustrer cette dernière frontière sans quitter les protocoles concernés. Une opération <get> demande des données de configuration et d’état ; une réponse <rpc-reply> reprend le message-id de la requête. Il existe donc une réponse applicative identifiable, distincte de l’ouverture du transport. RFC 6241, sections 4.2 et 7.7.

Pour un service de gestion, un contrôle proposé pourrait vérifier qu’une lecture autorisée renvoie les éléments attendus, dans le délai approuvé, sur la session authentifiée et le chemin documentés. Il ne suffirait pas de constater l’arrivée d’octets. Il faudrait interpréter le contenu reçu et distinguer un résultat exploitable, une erreur et une réponse insuffisante pour l’usage évalué.

Cette proposition n’attribue aucune capacité universelle à la lecture. Une opération sans modification des données métier peut fournir une preuve utile tout en laissant des droits ou des dépendances non exercés. Les fonctions non testées doivent rester hors de la conclusion. De même, lorsqu’une application sépare l’acceptation d’une demande de son achèvement, le contrat de surveillance devrait préciser lequel de ces événements constitue le succès attendu.

Conserver une preuve que l’on pourra encore interpréter

Le dossier proposé relie la version de configuration voulue et appliquée, le client émetteur, le relais joint, la destination demandée, la méthode négociée, la décision de relais, le résultat d’authentification du serveur et celui de l’opération. Un identifiant de corrélation et des horodatages permettent de rapprocher ces éléments sans prétendre qu’ils proviennent tous du même observateur.

Il convient également de conserver les limites de la collecte : informations absentes, incertitude sur les horodatages, rupture dans la corrélation ou détail connu seulement par une déclaration du relais. Une adresse rapportée par le proxy et une observation sur sa connexion sortante n’ont pas la même provenance. Une réponse applicative authentifiée répond encore à une autre question.

La conservation devrait privilégier les résultats, les versions et les empreintes nécessaires, sans recopier les mots de passe ni les charges utiles sensibles. Des traces protégées contre la modification, des lecteurs limités et une durée de conservation approuvée contribuent à préserver l’utilité du dossier. Protéger un journal ne rend pas son contenu intrinsèquement vrai : cela aide à maintenir la distinction entre ce qui a été observé, par qui et dans quelles conditions.

La conclusion défendable est bornée : une opération déterminée a obtenu le résultat attendu, sous une identité donnée, à travers le chemin documenté, pendant la période observée. Elle ne vaut ni promesse de disponibilité future ni validation des usages laissés hors du test. Le chemin configuré devient une hypothèse vérifiée pour cet usage, plutôt qu’un substitut à la preuve.