Outils

Outils qui tournent dans votre navigateur

Les vingt-quatre outils côté navigateur n’ont besoin d’aucun aller-retour serveur pour leur travail principal. Les plus récents sont deux outils pour traiter localement les secrets et les installateurs : la suite PGP génère des paires de clés, chiffre et déchiffre des messages et crée et vérifie des signatures dans votre navigateur, car les clés privées et les phrases secrètes ne doivent jamais être collées dans des chats ni téléversées, et l’analyseur APK lit les déclarations et les certificats de signature d’un installateur Android avant que vous ne l’installiez, le fichier étant analysé sur votre appareil et jamais téléversé. Avant eux est venu le triage de paquets : l’analyseur PCAP lit les captures .pcap et .pcapng — conversations, DNS, métadonnées TLS, alertes en clair — sous la même règle que tout le reste de cette liste, car un fichier de capture est une preuve et n’est jamais téléversé pour être lu. Avant lui, un duo d’outils d’investigation d’e-mails : l’analyseur de rapports DMARC ouvre les rapports agrégés envoyés par les destinataires (XML, gzipés ou zippés) et les fusionne en un tableau par source, et l’analyseur d’en-têtes d’e-mail dissèque un message suspect — chaîne Received, résultats d’authentification, domaines discordants, liens neutralisés — parce que ces deux tâches commencent par un fichier plein de détails de votre infrastructure, et que de tels fichiers ne devraient pas être téléversés pour être lus. Le calculateur de sous-réseau est de l’arithmétique pure ; l’analyseur de journaux et le générateur de données de test tournent entièrement sur votre machine, et c’est pourquoi un journal de production ou une base de préproduction peut y passer en sécurité. Les cinq plus récents existent pour les tâches que les gens tentent dans les chats d’IA et regrettent : hacher (un chat invente les empreintes), identifier des hachages, décoder et vérifier des JWT, convertir du Base64 et générer des mots de passe — des tâches dont les entrées sont des identifiants et dont les réponses doivent être calculées, donc les cinq tournent localement et ne transmettent rien. Le lot planification travaille sur des entrées qui ne devraient jamais être collées sur le serveur d’un inconnu : le planificateur d’astreintes travaille sur la liste de votre équipe, le générateur de certificats crée des clés privées — localement, jamais téléversées — et les calculateurs de rétention de sauvegarde et de budget d’erreur travaillent sur vos politiques internes et vos chiffres d’incidents. Les trois plus récents étendent la même règle : le validateur .env analyse le fichier le plus chargé de secrets de votre pile sans en transmettre un octet, le planificateur de réunions fait son arithmétique de fuseaux horaires à partir des données Intl de votre propre navigateur, et l’estimateur de capacité transforme vos chiffres de trafic internes en plan de flotte sur-le-champ. La recherche DNS, l’analyseur de certificats et la recherche de domaine appellent bel et bien des services publics — Google ou Cloudflare pour le DNS, crt.sh pour l’historique des certificats, les registres RDAP pour les données de domaine — et chacune de ces pages nomme le service qu’elle interroge, pour que vous sachiez toujours où un domaine saisi est réellement allé. Quand une tâche existe sous forme navigateur et sous forme serveur, les pages se lient entre elles : l’analyseur de certificats pointe vers le vérificateur SSL en direct, la recherche de domaine vers le vérificateur d’expiration, et la recherche DNS vers le bilan de santé pour le tableau complet.

Comment fonctionnent les vérificateurs

Chaque vérificateur prend un nom de domaine nu, rien d’autre. Il n’y a ni URL, ni chemin, ni port à fournir, et le service ne se connecte qu’aux ports web standard du domaine que vous nommez. Il parcourt ensuite ses vérifications indépendamment : une sonde HTTP pour la joignabilité et le temps de réponse, une poignée de main TLS pour le certificat, une interrogation du registre (RDAP) pour l’enregistrement du domaine, et des requêtes DNS pour les enregistrements qui routent le trafic et le courrier. Comme les sections sont indépendantes, une partie en échec ne masque jamais le reste — un site au serveur web cassé montre toujours son certificat et ses dates d’expiration, ce qui est le plus souvent exactement ce qu’il faut pour le réparer. Deux vérifications plus récentes brisent délibérément la règle du domaine nu : la chaîne de statut HTTP prend une URL complète, car une chaîne est une propriété d’une adresse, pas d’un domaine ; et la vérification de propagation DNS pose la même question à quatre résolveurs publics, car la propagation est une propriété des caches, pas du seul domaine. Le bureau de triage de CVE la brise d’une troisième façon : il prend une liste d’identifiants de vulnérabilités, car sa question porte sur une file de correctifs, pas sur un hôte — et ses réponses viennent d’ensembles de données que le serveur actualise chaque jour, plutôt que de sondages.

Les résultats sont mis en cache brièvement, de sorte qu’un rapport partagé avec un collègue montre le même instantané que celui que vous avez vu, étiqueté de l’heure de sa prise. Quand un certificat ou un domaine est à moins de quatre-vingt-dix jours de son expiration, le rapport le dit haut et fort et propose une surveillance continue gratuite via myeventwatch, car un compte à rebours qu’il faut se souvenir de revérifier n’est que la moitié d’une solution.