# Une clé d'hôte SSH révoquée peut-elle laisser entrer l'agent ?

Une clé d'hôte SSH révoquée doit arrêter un agent avant l'authentification de l'utilisateur, quel que soit le nom ou l'adresse employé. Si le test essaie seulement le nom d'hôte habituel une fois, il prouve bien moins que ce qu'il semble prouver. La configuration SSH peut associer plusieurs noms à un serveur, un port non standard modifie le jeton de recherche de known-hosts et un client multiplexé peut ouvrir un autre canal sans refaire la vérification de la clé d'hôte.

Considérez la révocation comme une propriété de l'identité cryptographique, puis testez chaque chemin capable de présenter ou de réutiliser cette identité. Il faut une liste de révocation de clés, un état client propre, des variantes de connexion explicites et une procédure distincte pour les connexions déjà établies. Un avertissement de changement de clé est utile, mais ce n'est pas le même contrôle.

## La révocation doit suivre la clé, pas le nom d'hôte

Une clé d'hôte authentifie le serveur pendant l'échange de clés SSH. La RFC 4253 décrit comment le client reçoit la clé publique du serveur, vérifie qu'elle appartient au serveur attendu et contrôle la signature du serveur sur l'échange. La révocation intervient à ce moment-là : si le serveur présente une clé publique interdite, le client doit la refuser avant d'envisager une clé utilisateur, un mot de passe ou une commande distante.

OpenSSH propose deux mécanismes qui se ressemblent, mais dont la portée diffère. Une ligne commençant par `@revoked` dans un fichier known-hosts associe un motif d'hôte à une clé révoquée. Elle fonctionne quand le nom de recherche de la connexion correspond à cette ligne. Un alias ou une autre forme d'adresse peut ne pas correspondre au motif, même si le serveur présente la même clé. Le manuel `sshd` d'OpenSSH indique qu'une entrée révoquée correspondante ne doit jamais être acceptée, mais le mot « correspondante » compte.

L'option cliente `RevokedHostKeys` convient mieux à une révocation liée à un incident. Elle pointe vers un fichier texte de clés publiques ou vers une liste de révocation de clés OpenSSH (KRL). OpenSSH compare l'identité présentée à ce fichier, que l'utilisateur ait saisi `build-test`, `build-test.example` ou une adresse IP littérale. J'utilise des entrées `@revoked` pour la gestion known-hosts ciblée ; j'utilise `RevokedHostKeys` quand une identité cryptographique doit être refusée partout.

Ne confondez aucun de ces mécanismes avec `StrictHostKeyChecking=yes`. La vérification stricte refuse les hôtes inconnus et les clés modifiées, ce qui empêche d'accorder silencieusement sa confiance lors de la première utilisation. Elle ne déclare pas révoquée une clé qui serait autrement fiable. Un test qui supprime l'ancienne entrée known-host et se félicite d'un échec pour hôte inconnu a testé une base de confiance vide, pas la révocation.

## Construisez un hôte de test que vous pouvez casser

Utilisez un serveur SSH jetable avec un port, une clé d'hôte, un compte utilisateur et un répertoire client dédiés. Ne répétez pas une révocation sur un hôte de préproduction partagé. Vous devez pouvoir remplacer des clés, arrêter des processus et fermer des sockets de contrôle sans vous demander qui d'autre en dépend.

L'organisation suivante conserve les preuves dans un seul répertoire. Le chemin exact de `sshd` et le modèle de privilèges varient selon le système d'exploitation ; exécutez donc le démon dans le conteneur, la VM ou le montage de test que votre équipe utilise déjà pour ses tests d'intégration SSH.

```bash
set -eu
work="$PWD/ssh-revocation-fixture"
mkdir -p "$work/client" "$work/server"
chmod 700 "$work/client"

ssh-keygen -q -t ed25519 -N '' \
  -C revoked-host-test -f "$work/server/ssh_host_ed25519_key"
ssh-keygen -q -t ed25519 -N '' \
  -C agent-test-user -f "$work/client/id_ed25519"

ssh-keygen -lf "$work/server/ssh_host_ed25519_key.pub"
```

La dernière commande affiche une ligne de cette forme :

```text
256 SHA256:<base64-fingerprint> revoked-host-test (ED25519)
```

Consignez cette empreinte dans le journal de test. Ne copiez jamais une empreinte depuis un ticket en supposant que le fichier du montage contient la même clé. Calculez-la depuis le fichier de clé publique réellement chargé par le serveur de test.

Configurez le démon pour qu'il utilise uniquement cette clé d'hôte. Remplissez son `AuthorizedKeysFile` avec la clé publique du client, désactivez les mots de passe et liez-le à une adresse de bouclage ou isolée. Un montage minimal doit aussi définir un `PidFile` explicite et une journalisation détaillée. Le but est la reproductibilité : un écouteur, une identité d'hôte et un chemin d'authentification.

Avant d'ajouter la révocation, faites réussir une connexion stricte et exécutez une commande témoin inoffensive comme `printf BASELINE_OK`. Capturez la clé d'hôte lors d'une étape de provisionnement authentifiée, et non avec un `ssh-keyscan` non contrôlé sur le chemin réseau que vous cherchez à protéger. `ssh-keyscan` récupère des clés sans prouver qui les a fournies.

## Placez l'identité révoquée dans une KRL

Une KRL centre le test sur la clé plutôt que sur l'orthographe de la destination. Générez-la directement depuis la clé publique chargée par le montage, puis interrogez-la avant toute tentative réseau :

```bash
work="$PWD/ssh-revocation-fixture"
ssh-keygen -k -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"

if ssh-keygen -Q -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"; then
  printf '%s\n' 'FAIL: fixture host key is not revoked'
  exit 1
else
  printf '%s\n' 'OK: fixture host key is revoked'
fi
```

Le code de sortie inversé piège souvent les équipes. Le manuel de `ssh-keygen` précise que `-Q` renvoie une valeur non nulle si l'une des clés interrogées est révoquée ou si une erreur survient ; zéro signifie qu'aucune ne l'est. Ne jetez pas stderr et distinguez dans le journal englobant une KRL illisible d'une correspondance de révocation valide.

Rattachez maintenant le fichier à la configuration cliente au niveau le plus large utilisé par l'agent :

```sshconfig
Host *
    BatchMode yes
    StrictHostKeyChecking yes
    UserKnownHostsFile ./ssh-revocation-fixture/client/known_hosts
    RevokedHostKeys ./ssh-revocation-fixture/client/revoked-hosts.krl
    ConnectTimeout 5
    ConnectionAttempts 1
```

OpenSSH échoue volontairement en mode fermé si le fichier `RevokedHostKeys` n'existe pas ou n'est pas lisible : il refuse l'authentification de tous les hôtes couverts par cette configuration. C'est plus sûr que d'ignorer le fichier, mais un déploiement cassé peut alors ressembler à un test de révocation réussi. La vérification préalable prouve que le fichier est lisible et contient la clé attendue.

Un simple fichier texte contenant une clé publique par ligne fonctionne aussi. La complexité des KRL devient utile avec de nombreuses clés ou des certificats d'hôte, car elles peuvent révoquer des clés simples, des numéros de série, des identifiants de certificat ou des clés signées par une CA. Choisissez le format le plus simple que vos processus de distribution et d'inspection savent gérer, puis testez le format réellement déployé.

## Un marqueur limité au nom exige un test hostile

Conservez un cas volontairement faible dans le montage pour montrer pourquoi la KRL est nécessaire. Créez une seconde configuration cliente sans option `RevokedHostKeys`, qui s'appuie uniquement sur cette entrée known-hosts :

```text
@revoked revoked-lab ssh-ed25519 AAAA...fixture-public-key...
```

Connectez-vous sous le nom `revoked-lab` et confirmez qu'OpenSSH refuse l'entrée correspondante. Connectez-vous ensuite au même écouteur sous le nom `127.0.0.1`, avec une entrée known-host fiable séparée pour `[127.0.0.1]:2222`. Si cette forme d'adresse réussit, le montage a reproduit le défaut de couverture : la clé n'a pas changé, mais le nom recherché ne correspond plus au marqueur révoqué. Gardez cette démonstration isolée de la production, car son objectif est de prouver qu'un contrôle ne suffit pas.

Ne collez pas la valeur abrégée `AAAA...` de l'exemple. Construisez le marqueur depuis le vrai fichier de clé publique afin que l'algorithme et les données base64 soient exacts. Une commande sûre peut lire les champs d'algorithme et de clé du fichier public, puis leur ajouter le marqueur et le motif d'hôte voulu. Vérifiez l'entrée avec `ssh-keygen -F revoked-lab -f known_hosts` ; répétez la recherche pour l'adresse littérale afin de montrer que l'entrée y est absente.

Cet échec explique pourquoi ajouter chaque alias connu à une ligne `@revoked` est fragile. L'inventaire change dès que quelqu'un ajoute un nom court, un enregistrement DNS, une entrée hosts locale, un port non standard, un alias de tunnel ou un `HostKeyAlias`. Les noms known-host hachés compliquent la revue manuelle, même si `ssh-keygen -F` peut encore les rechercher. Un motif générique élargit la correspondance, mais ne révoque la clé que si la destination reste dans ce motif et rend la portée voulue plus difficile à contrôler.

Le cas KRL doit employer le même serveur, la même clé utilisateur, le même chemin réseau et les mêmes entrées known-host fiables. Modifiez uniquement le mécanisme de révocation. Avec `RevokedHostKeys`, `revoked-lab` et `127.0.0.1` doivent tous deux échouer après présentation de la clé du montage. Cette expérience appariée transforme un avertissement abstrait sur les alias en échec visible et reproductible.

Testez aussi la priorité. OpenSSH conserve la première valeur obtenue pour chaque option ; un réglage spécifique placé tôt peut donc neutraliser le défaut prévu plus loin. Exécutez `ssh -G` pour chaque destination et comparez octet par octet le chemin `revokedhostkeys` résolu. Une revue qui trouve simplement le mot `RevokedHostKeys` quelque part dans un fichier ne prouve pas que l'agent l'utilise.

Les configurations système et utilisateur créent une autre séparation. Un ingénieur peut avoir `/etc/ssh/ssh_config` pointant vers la KRL de l'organisation, tandis que l'agent démarre avec `ssh -F private-config`, ce qui demande à OpenSSH d'utiliser un autre fichier. À l'inverse, un compte CI propre peut réussir sans représenter un exécuteur de production qui injecte des options en ligne de commande. Capturez l'invocation complète à la frontière d'action de l'agent et rendez-y explicite le chemin de révocation.

Les permissions appartiennent aux critères d'acceptation. D'après le manuel OpenSSH, une erreur de lecture de `RevokedHostKeys` refuse l'authentification de tous les hôtes. Vérifiez le fichier sous l'utilisateur système de l'agent avant la connexion et interrogez la clé visée. Cela distingue trois résultats qui ressemblent tous à une commande SSH en échec : une révocation valide, un fichier absent ou illisible et une KRL mal formée.

La distribution présente aussi un décalage temporel. Si plusieurs machines peuvent lancer l'agent, publier la KRL sur une seule ne termine pas la révocation. Enregistrez un condensat du contenu et exigez que chaque exécuteur le fournisse avant d'accepter de nouvelles tâches SSH. Remplacez le fichier de façon atomique pour qu'aucun lecteur n'en voie une version partielle. Après distribution, lancez le test négatif depuis chaque image cliente ou classe de configuration distincte, pas seulement depuis la machine qui a créé la KRL.

Le retour arrière doit avoir un sens testable. Retirer une empreinte de la KRL parce qu'un ticket est clos peut restaurer la confiance alors que la clé privée compromise existe toujours. Préférez remplacer l'identité du serveur, distribuer la nouvelle confiance et conserver l'ancienne identité dans la révocation. Si la politique autorise un retrait ultérieur, exigez la preuve que l'ancienne clé privée ne peut pas revenir et conservez un test de régression qui la présente.

Le dossier d'acceptation d'une identité révoquée doit donc contenir l'empreinte, l'algorithme de clé publique, le condensat KRL, les formes de destination testées, la configuration effective de chacune et le résultat d'un nouvel échange. Ajoutez séparément le résultat de la session multiplexée, car il répond à une autre question. Les réviseurs peuvent alors isoler la correspondance d'identité, la couverture des chemins, la configuration, la distribution ou le nettoyage du transport.

## Une nouvelle connexion doit échouer avant le témoin

Forcez le premier cas négatif à établir un nouveau transport. Désactivez le partage en ligne de commande même si la configuration SSH de l'utilisateur l'active, gardez le client non interactif et placez dans la commande distante un témoin impossible à manquer s'il s'exécute.

```bash
work="$PWD/ssh-revocation-fixture"
config="$work/client/config"
log="$work/client/direct.stderr"

set +e
ssh -F "$config" \
  -o ControlMaster=no -o ControlPath=none \
  -i "$work/client/id_ed25519" \
  -p 2222 testuser@127.0.0.1 \
  'printf REVOKED_KEY_EXECUTED' \
  >"$work/client/direct.stdout" 2>"$log"
rc=$?
set -e

if [ "$rc" -eq 0 ]; then
  printf '%s\n' 'FAIL: SSH accepted a revoked host identity'
  exit 1
fi
if grep -q REVOKED_KEY_EXECUTED "$work/client/direct.stdout"; then
  printf '%s\n' 'FAIL: remote sentinel ran'
  exit 1
fi
printf 'PASS rc=%s\n' "$rc"
```

Vérifiez le résultat, pas une phrase d'erreur anglaise exacte. Les versions d'OpenSSH et les systèmes peuvent formuler les diagnostics différemment. Lorsqu'un cas échoue, conservez la sortie détaillée d'une seconde exécution avec `-vv` et recherchez l'empreinte présentée ainsi que le diagnostic de révocation. Un délai TCP, un port fermé, un hôte inconnu, une clé utilisateur absente ou un compte refusé renvoient aussi une valeur non nulle, mais aucun ne prouve que la révocation a arrêté la connexion.

Le journal du serveur fournit l'autre moitié de l'assertion. Le client doit se déconnecter pendant l'échange de clés, avant que le serveur ne consigne une authentification utilisateur réussie et avant le démarrage d'une session. Si le montage ne permet pas de distinguer ces phases, il est trop opaque pour ce test.

Exécutez un cas témoin avec une KRL vide et lisible ou une autre clé serveur non révoquée. Cette connexion doit atteindre `BASELINE_OK`. Un test négatif sans témoin positif réussit souvent parce que le DNS, le routage, les permissions ou le compte étaient déjà cassés.

## Chaque alias et forme d'adresse exige son cas

Une KRL doit refuser la clé sous différents noms, mais la résolution de configuration peut encore faire passer une orthographe autour de l'option. Testez la configuration effective et le résultat réseau pour chaque forme de destination que l'agent peut produire.

Commencez par une petite matrice liée au montage :

1. L'alias configuré, comme `revoked-lab`, dont `HostName` pointe vers l'adresse de test.
2. Le nom pleinement qualifié et tout nom court accepté par les règles locales de résolution.
3. L'adresse IPv4 littérale et, si l'écouteur en dispose, l'adresse IPv6 littérale.
4. Le jeton known-host d'un port non standard, généralement écrit `[host]:port` dans les outils known-hosts.
5. Un alias qui définit `HostKeyAlias`, car cette option remplace le nom réel lors de la recherche de clés et de la validation de certificats.

Placez les variantes dans un fichier de données ou une fonction plutôt que de dupliquer un bloc shell. Pour chaque nom visible, inspectez `ssh -G destination` et conservez `hostname`, `port`, `hostkeyalias`, `userknownhostsfile`, `revokedhostkeys`, `proxycommand`, `proxyjump`, `controlmaster` et `controlpath`. `ssh -G` développe la configuration sans se connecter et détecte donc une section `Host` qui remplace discrètement le chemin KRL.

`Hostname` et `HostKeyAlias` ont des rôles différents. `Hostname` choisit la destination réseau. `HostKeyAlias` choisit le nom employé par OpenSSH pour lire ou enregistrer les clés et valider les certificats. Aucun ne devrait affaiblir un contrôle global `RevokedHostKeys`, mais tous deux peuvent changer l'entrée known-host fiable considérée. Une ligne `@revoked` limitée à un nom est donc un mauvais contrôle d'incident.

La canonicalisation mérite un cas lorsqu'elle est activée. `CanonicalizeHostname yes` peut ajouter des domaines configurés et demande à OpenSSH de relire la configuration avec la cible réécrite. Une section correspondante ultérieure peut sélectionner un autre fichier known-hosts ou omettre la révocation. Testez l'entrée courte et le nom canonique obtenu, puis confirmez que les deux configurations indiquent la même KRL.

Ne considérez pas `CheckHostIP=yes` comme une couverture des alias. Le manuel OpenSSH précise qu'il contrôle aussi l'IP dans known-hosts et qu'il n'est pas disponible avec une commande proxy. Il peut détecter une association modifiée, mais ne remplace pas un fichier centré sur la clé. Les chemins proxy et de saut nécessitent toujours un test complet de la cible finale, avec une confiance distincte pour chaque hôte de saut.

## Les connexions en cache délimitent la réponse à incident

Une connexion maîtresse SSH multiplexée et active a déjà authentifié le serveur. Ouvrir une autre session via son socket ne crée pas de connexion TCP ni d'échange de clé, donc une KRL nouvellement installée ne peut pas refuser la clé rétroactivement. Parler de contournement brouille le modèle. Il s'agit de réutiliser un transport déjà authentifié qui existe encore.

Prouvez ce comportement dans le montage au lieu de supposer qu'un redémarrage nettoiera tout. Établissez d'abord un maître multiplexé quand la clé est autorisée. Gardez-le actif avec `ControlPersist`, ajoutez la clé à la KRL et montrez que `ssh -O check` le trouve toujours. Une commande envoyée via ce socket peut encore s'exécuter. Consignez ce résultat comme témoin attendu avant correction, pas comme réussite de la révocation.

Appliquez ensuite la réponse : empêchez l'agent d'ouvrir de nouvelles tâches, terminez les maîtres concernés et révoquez ou arrêtez la session qui les possède. Pour un socket dédié au montage, la commande locale prend cette forme :

```bash
socket="$PWD/ssh-revocation-fixture/client/cm-testuser-127.0.0.1-2222"
ssh -S "$socket" -O exit testuser@127.0.0.1
```

Une fois le socket disparu, répétez la connexion avec `ControlMaster=no` et `ControlPath=none` ; elle doit échouer sur la clé révoquée. Testez aussi la configuration de multiplexage habituelle après nettoyage. Les modes opportunistes comme `ControlMaster auto` retombent sur une nouvelle connexion quand aucun maître n'écoute, et cette tentative doit consulter la KRL.

Un fichier de socket périmé n'est pas une connexion authentifiée. OpenSSH l'essaie, découvre qu'aucun maître n'écoute et peut revenir à une connexion normale. Conservez ce cas, car les arrêts brutaux laissent des fichiers. Le résultat sûr reste un refus de révocation pendant le nouvel échange.

Révoquer une identité pendant un incident actif exige donc deux contrôles : refuser les futurs échanges et terminer les transports authentifiés avant la révocation. Un test qui n'en couvre qu'un laisse soit une nouvelle route, soit une ancienne route jamais fermée.

## Un serveur peut présenter plusieurs identités

Les serveurs chargent souvent plusieurs clés d'hôte ou un certificat avec sa clé sous-jacente. Révoquer une empreinte ne rend pas nécessairement le point d'accès inaccessible. Pendant la négociation, le client et le serveur choisissent un algorithme commun ; une autre clé fiable et non révoquée peut authentifier le même serveur.

Décidez du sens de l'incident. Si une clé privée d'hôte a fui, le client doit la refuser, tandis qu'une autre clé protégée indépendamment peut rester acceptable après examen. Si la machine a perdu son intégrité, révoquez toutes les identités qu'elle peut présenter, certificats compris, et retirez la confiance jusqu'à sa reconstruction. Écrire « hôte révoqué » dans un ticket sans lister les identités laisse la négociation choisir.

Inventoriez le montage depuis la configuration du démon et les registres fiables, pas avec un seul scan. Testez chaque algorithme actif en limitant `HostKeyAlgorithms` à celui étudié. La clé révoquée doit échouer. Chaque identité qui doit survivre exige son propre cas positif et son empreinte documentée.

Les certificats ajoutent une distinction. Vous pouvez révoquer le certificat comme objet public, révoquer son numéro ou son ID dans une KRL, ou révoquer la CA qui autorise une classe d'hôtes. Ces choix ont des portées différentes. Le manuel `ssh-keygen` documente les directives KRL pour numéros, IDs, clés publiques et empreintes ; interrogez la KRL finale avec le certificat exact présenté.

`UpdateHostKeys` mérite aussi votre attention. OpenSSH peut apprendre des clés supplémentaires après authentification avec une clé simple déjà fiable. Cela facilite les rotations prévues, mais les alternatives apprises restent candidates si la décision de révocation ne les couvre pas. Extrayez les entrées du client avec `ssh-keygen -F` pour chaque nom et forme `[name]:port`, puis comparez chaque clé au périmètre de l'incident.

## Exécutez le test sur le vrai chemin de l'agent

Un test de terminal sous le compte d'un ingénieur ne prouve pas qu'un agent autonome utilise le même binaire SSH, la même configuration, le même répertoire personnel, le même résolveur, le même proxy ou le même socket. La suite finale doit invoquer la frontière d'action exacte de l'agent et démarrer avec son environnement de production.

Faites renvoyer des preuves structurées pour chaque variante : libellé de destination, nom et port résolus, empreinte présentée, condensat KRL, état du partage, code de sortie, présence du témoin et phase de fermeture par le serveur. N'y placez aucun secret. L'assertion utile est simple : l'identité révoquée a été présentée, le client l'a reconnue et aucune authentification ni commande n'a suivi.

L'isolation révèle les dépendances accidentelles. Définissez explicitement le chemin de configuration SSH, le fichier known-hosts, la KRL, le fichier d'identité et le chemin de contrôle. Effacez ou remplacez `SSH_AUTH_SOCK` si l'agent ne doit pas emprunter des clés étrangères. Limitez la durée pour ne pas bloquer CI. Conservez stderr et les logs serveur en cas d'échec ; le rapport réussi peut garder leurs hachages et les lignes décisives.

Si les agents passent par Sallyport pour SSH, empruntez ce chemin dans le test négatif : son assistant sans état `sp-ssh` exécute les actions SSH, tandis que les journaux Sessions et Activity enregistrent l'exécution et chaque appel. Vérifiez la chaîne hors ligne avec `sp audit verify` si le test couvre aussi l'intégrité des preuves ; le refus de clé doit toujours venir de la configuration de confiance SSH réellement exercée.

N'affaiblissez pas le client pour simplifier l'automatisation. `StrictHostKeyChecking=no`, une cible known-hosts vide ou l'envoi des diagnostics vers `/dev/null` transforment un test de sécurité en test de connectivité. `BatchMode=yes` supprime les invites ; il ne compense pas une confiance absente.

## Le test ne doit échouer que pour une raison

Placez la matrice dans CI, mais gardez un montage assez petit pour être diagnostiqué. Exécutez un témoin positif avec une identité autorisée, contrôlez la KRL, démarrez l'écouteur, puis lancez les variantes de connexion neuve. Testez le multiplexage dans une phase distincte, car sa préparation et son résultat attendu diffèrent. Enfin, arrêtez l'écouteur et vérifiez qu'aucun maître ni socket ne reste.

Refusez la construction si une destination atteint le témoin, si une configuration effective n'a pas le fichier requis ou si le serveur présente une identité non classée. Refusez aussi une exécution sans conclusion. Un délai ou une KRL illisible signifie que le test est cassé, même si SSH renvoie un code non nul.

Conservez l'empreinte attendue et le condensat KRL dans le rapport. Quand une rotation change l'identité du montage, la revue doit montrer les deux valeurs changer ensemble. Cette petite contrainte évite que le serveur reçoive une nouvelle clé tandis que le test révoque toujours un ancien fichier public.

Exécutez la suite avec un processus d'agent incapable d'afficher une invite. Une demande d'approbation, de mot de passe ou de confirmation d'hôte peut attendre jusqu'à ce qu'un délai générique masque la cause. `BatchMode=yes` doit faire échouer ces chemins immédiatement, tandis que le témoin positif prouve qu'aucune interaction n'est requise. Placez une limite dure autour de la tâche, mais ne la comptez jamais comme preuve de révocation.

Conservez une trace détaillée et nettoyée pour chaque version cliente prise en charge. Elle donne une référence sur l'ordre d'expansion de la configuration, de réutilisation, d'échange de clés, de sélection et de refus. Quand une mise à jour change le comportement ou le texte d'OpenSSH, comparez la nouvelle trace et n'adaptez les assertions qu'après confirmation de l'empreinte et de la phase. Les tests de sécurité pourrissent quand chaque nouvel échec est classé comme simple variation de sortie.

Conservez le résultat gênant du maître encore actif. Il rappelle que distribuer une KRL ne révoque pas une session. Fermez les transports existants, prouvez que la tentative suivante échange une clé et observez le client refuser l'empreinte exacte marquée. Alors seulement, vous aurez montré que les alias, le cache et l'écriture de l'adresse ne peuvent pas rendre l'accès à l'agent.