Accueil/Chiffrer ses DM

Chiffrer ses messages privés sur IRC : OTR et ses limites

TLS protège le trajet, le cloak masque l'adresse, mais aucun des deux ne cache le contenu d'un message privé aux yeux de l'opérateur du serveur qui l'achemine. Combler ce dernier maillon exige une couche supplémentaire, appliquée au niveau du contenu lui-même plutôt qu'au transport : le chiffrement de bout en bout, dont OTR constitue l'implémentation la plus répandue sur les clients IRC classiques.

Ce que « bout en bout » signifie concrètement

Un chiffrement de bout en bout garantit que seuls l'expéditeur et le destinataire d'un message disposent des clés nécessaires pour le déchiffrer, à l'exclusion de tout intermédiaire technique situé sur le trajet — y compris le serveur qui relaie le message. C'est une différence fondamentale avec TLS, qui chiffre uniquement le trajet entre le client et le serveur : avec TLS seul, le serveur déchiffre le message à son arrivée avant de le rechiffrer pour le retransmettre ; avec un chiffrement de bout en bout, le serveur ne dispose jamais de la clé nécessaire pour lire le contenu, quelle que soit la configuration de sa propre politique de journalisation.

OTR, un protocole conçu spécifiquement pour le chat

OTR (Off-the-Record Messaging) a été conçu dès l'origine pour les échanges de messagerie instantanée, avec des propriétés spécifiques à cet usage plutôt qu'empruntées telles quelles à d'autres contextes de chiffrement. Le protocole négocie une clé de session distincte pour chaque conversation, régulièrement renouvelée, ce qui garantit qu'une compromission ultérieure d'une clé ne permet pas de déchiffrer rétroactivement des échanges antérieurs — une propriété appelée confidentialité persistante (forward secrecy).

OTR intègre également une propriété moins connue mais tout aussi significative : la répudiabilité. Contrairement à une signature cryptographique classique, un message OTR ne peut pas être prouvé de façon irréfutable comme provenant d'un expéditeur donné auprès d'un tiers, une fois la conversation terminée — une caractéristique délibérément recherchée pour préserver la nature informelle et non engageante d'une conversation orale transposée au chat, par opposition à un document signé numériquement.

Ce qu'OTR exige concrètement pour fonctionner

OTR nécessite que les deux interlocuteurs utilisent un client compatible avec le protocole, l'ajout se faisant nativement dans certains clients ou via une extension tierce dans d'autres. La première mise en relation entre deux interlocuteurs implique une vérification d'identité, généralement via l'échange d'une empreinte cryptographique (fingerprint) par un canal indépendant du chat lui-même — en personne, par téléphone, ou via un autre canal déjà considéré comme fiable — pour s'assurer qu'aucun intercepteur ne s'est substitué à l'un des deux interlocuteurs lors de cet échange initial.

Ce qu'OTR ne protège pas

OTR chiffre le contenu du message échangé, mais ne masque en rien le fait qu'une conversation a lieu, ni son horodatage, ni l'identité des deux interlocuteurs telle que visible par le serveur qui achemine les paquets chiffrés. Cette métadonnée résiduelle — qui parle à qui, quand, à quelle fréquence — reste entièrement visible pour l'opérateur du réseau, même si le contenu échangé lui demeure inaccessible. Pour un usage qui exige également de masquer l'existence même de la conversation, OTR seul ne suffit pas et doit être combiné aux protections réseau développées ailleurs sur ce site.

OTR et l'historique local du client

Le chiffrement de bout en bout protège le contenu pendant son trajet, pas nécessairement après réception : un client qui conserve un journal en clair des conversations déchiffrées sur le disque local de l'appareil réintroduit une vulnérabilité qu'OTR avait justement pour objectif d'éliminer, cette fois au niveau du stockage plutôt que du transport. Vérifier les paramètres de journalisation locale du client utilisé, et les désactiver pour les conversations les plus sensibles, complète la protection apportée par le protocole lui-même.

OTR face à PGP : deux logiques de chiffrement différentes

PGP, souvent cité en comparaison, répond à un besoin structurellement différent de celui d'OTR : conçu à l'origine pour le courrier électronique asynchrone, PGP chiffre un message avec la clé publique du destinataire, message qui peut ensuite rester stocké, chiffré, en attendant sa lecture — un modèle adapté à une communication qui n'exige pas d'échange immédiat. OTR, à l'inverse, exige que les deux interlocuteurs soient connectés simultanément pour négocier une session chiffrée, ce qui correspond naturellement à la nature synchrone d'une conversation en temps réel sur IRC.

Cette différence structurelle a une conséquence directe sur la confidentialité persistante évoquée plus haut : une clé PGP compromise expose potentiellement l'ensemble des messages chiffrés avec cette même clé, passés comme futurs, tant qu'elle reste en usage ; une session OTR compromise n'expose que les échanges de cette session précise, grâce au renouvellement systématique des clés à chaque nouvelle conversation. Ce compromis explique pourquoi OTR reste préféré pour un usage synchrone où la confidentialité persistante importe particulièrement, tandis que PGP conserve sa pertinence pour un usage asynchrone que la nature même d'OTR ne permet pas de couvrir.

Le renouvellement des clés, une fenêtre d'exposition réduite mais non nulle

Le renouvellement régulier des clés de session pendant une conversation OTR réduit la quantité de données exposée en cas de compromission, mais ne l'élimine pas complètement : les messages échangés pendant l'intervalle précis où une clé compromise reste active demeurent vulnérables, même si les échanges antérieurs et postérieurs à cet intervalle restent protégés par le mécanisme de renouvellement. Cette nuance technique, souvent simplifiée à l'excès dans les présentations grand public du concept de confidentialité persistante, mérite d'être comprise avec précision plutôt que traitée comme une garantie absolue et sans limite temporelle.

Vérifier concrètement qu'une session OTR est active

La plupart des clients compatibles OTR affichent un indicateur visuel explicite — changement de couleur, icône dédiée, mention textuelle dans la fenêtre de conversation — confirmant qu'une session chiffrée est effectivement active, distincte d'une simple tentative de négociation restée sans réponse de l'autre côté. Vérifier cet indicateur avant d'échanger une information sensible, plutôt que de supposer que le chiffrement s'est activé automatiquement, évite l'erreur fréquente consistant à croire une conversation protégée alors que la négociation a en réalité échoué silencieusement, laissant les échanges suivants transiter en clair à travers le protocole standard.

Les alternatives et successeurs d'OTR

Des protocoles plus récents, comme OMEMO (utilisé notamment sur certains clients XMPP) ou le protocole Signal désormais largement adopté au-delà de son application d'origine, reprennent et étendent les principes d'OTR pour des contextes qui incluent la messagerie asynchrone et la synchronisation multi-appareils, des cas d'usage qu'OTR, conçu pour une communication synchrone en temps réel, ne couvre pas nativement. Pour un usage centré spécifiquement sur IRC, OTR reste néanmoins l'option la plus directement intégrable aux clients existants, sans nécessiter de migrer vers un écosystème de communication entièrement différent.

Une protection à intégrer dans l'ensemble de la démarche

Le chiffrement de bout en bout complète, sans les remplacer, les protections décrites ailleurs sur ce site : le cloak et le VPN masquent l'identité de connexion, TLS protège le trajet vers le serveur, OTR protège le contenu du message lui-même vis-à-vis de ce même serveur. C'est la superposition cohérente de ces quatre couches, chacune répondant à une menace distincte, qui rapproche le plus une communication en temps réel d'une conversation réellement confidentielle.

Aucune de ces couches, prise séparément, ne suffit à elle seule : omettre le VPN laisse l'adresse réelle exposée au serveur malgré un contenu chiffré par OTR ; omettre OTR laisse le contenu lisible par ce même serveur malgré une adresse masquée. C'est précisément cette complémentarité, plutôt qu'une hiérarchie où une protection dominerait les autres, qui structure l'ensemble de l'approche développée sur ce site : chaque mécanisme comble une lacune que les autres, par construction, laissent nécessairement ouverte.

Adopter cette discipline sans en faire un fardeau permanent

Appliquer systématiquement l'ensemble de ces protections à chaque conversation, y compris les plus anodines, représenterait une charge disproportionnée par rapport au besoin réel de la plupart des échanges quotidiens. La discipline la plus soutenable consiste à réserver le chiffrement de bout en bout et la vérification rigoureuse d'identité aux échanges dont le contenu justifie objectivement cet effort, tout en maintenant les protections de base — TLS, cloak, VPN pour un usage régulier — comme un socle appliqué de façon constante, indépendamment de la sensibilité perçue de chaque conversation prise individuellement.