Soupe à l’.onion

La réputation sulfureuse des services cachés (dits Hidden Services) n’est malheureusement plus à faire. Places de vente de drogue ou de trafic d’armes, le grand public en a entendu parler grâce à l’affaire Silk Road [SKROAD]. Mais les .onion du projet Tor sont en fait utilisés pour bien d’autres choses. Qu’il s’agisse de permettre de discuter anonymement avec Ricochet [RICO] ou de contourner la censure et d’échapper à la surveillance d’État, les usages de ces Hidden Services sont les mêmes que ceux d’Internet.

Nous détaillerons d’abord rapidement le fonctionnement de ces Hidden Services et du protocole « Rendezvous » développé par le projet Tor. Nous verrons ensuite concrètement  comment il est possible d’héberger de tels services et les intégrer au sein de l’infrastructure d’une organisation. Enfin, nous verrons rapidement comment ces Hidden Services sont intégrés à SecureDrop et comment cette suite d’outils permet d’héberger une plateforme recevant des sources, de les analyser et de les exploiter.

1. Ingrédients

Cet article se destine avant tout aux administrateurs d’une organisation publiant du contenu d’investigation et dépendant de sources pour ce faire. Les techniques détaillées peuvent bien entendu être utilisées dans d’autres contextes.

1.1 Analyse des risques

La protection de l’identité de votre source, préserver le secret de l’investigation en cours et protéger l’infrastructure de votre organisation sont donc des priorités. Dans le cas qui nous intéresse, des précautions supplémentaires sont nécessaires.

L’adversaire est une entreprise ou un opérateur étatique disposant de moyens d’interception et d’analyse de trafic d’une part ; il peut cibler et infecter une infrastructure ou des documents confidentiels dans le but de révéler une éventuelle fuite de données d’autre part.

La source prend un risque fort et est motivée pour vous faire parvenir des documents. Elle est partiellement consciente des risques et cherche à transmettre des documents sous forme numérique à votre organisation. Son identité doit être protégée, car si elle est connue, elle pourra faire l’objet de harcèlement judiciaire ou de licenciements [LUXL].

Votre organisation est connue pour son travail d’investigation, il n’est pas nécessaire de dissimuler l’existence de l’organisation ni l’existence de la plateforme de recueil de données. Il est cependant important de dissimuler le lien entre la source et cette plateforme ; c’est ce que nous ferons au cours de cet article.

1.2 Comment fonctionnent les .onions

Les .onion sont des Hidden Services développés par le projet Tor [TOR]. Ils permettent de publier un service sans révéler ni l’entité l’hébergeant, ni l’identité de la personne désirant y accéder.

La création de tels services au sein du réseau Tor se fait via le protocole Rendezvous [RDV]. Ce dernier permet aux serveurs et aux clients de se trouver, sans jamais entrer en contact directement les uns avec les autres. Cette mise en contact se fait en plusieurs étapes.

Tout d’abord, le serveur établit un circuit vers plusieurs nœuds du réseau, qu’il choisit aléatoirement, et qui sont appelés Points d’Introduction. Une fois ces nœuds contactés, le serveur envoie dans une table de hash distribuée un descripteur composé de sa clef publique et de ces nœuds ; celui-ci est signé par sa clef secrète. Cette table associe l’adresse du service (16 caractères suivis de .onion) au descripteur.

Le client désirant accéder au service demande ensuite à la base de données le descripteur associé et crée également un circuit vers un point de rendez-vous. Une fois le descripteur obtenu, le client initie une demande de rendez-vous en utilisant un jeton unique et l’adresse du point de rendez-vous. Le tout est signé avec la clef publique du serveur, puis ce message est envoyé à un des points d’introduction choisi au hasard dans la liste.

Le point d’introduction contacte ensuite le serveur et lui passe le message. Le serveur peut déchiffrer ce message grâce à sa clef privée et trouver le point de rendez-vous. Il envoie ensuite le même secret au point de rendez-vous et peut alors notifier le client de l’état des connexions.

Cet ensemble, décrit en détail à [ONION], permet au client d’établir un chemin, chiffré de bout en bout, entre le client et le serveur, tout en préservant l’identité du serveur et du client.

2. Faire revenir les .onion

Installer un Hidden Service nécessite d’abord d’installer Tor. Il est déconseillé d’être à la fois relais et Hidden Service. Il est cependant possible de faire fonctionner plusieurs daemon Tor sur une même machine.

2.1 Prérequis

Commençons donc par installer Tor. Le projet Tor fournit des guides d’installation pour les distributions de type Debian ou assimilées, voir [DEB]. Par la suite, nous considérons qu’on utilise une distribution Debian Stretch. Si ce n’est pas le cas, adaptez les chemins de fichiers à ceux de votre distribution.

2.2 Installation des Hidden Services

Il est maintenant temps de créer les Hidden Services. Nous partons du principe que le service que vous voulez rendre disponible dans le réseau Tor existe déjà et est fonctionnel, par exemple vous disposez d’un serveur Apache en écoute sur le port 80 de votre interface publique.

La déclaration des Hidden Services se fait en modifiant le fichier de configuration du daemon tor (/etc/tor/torrc). Il est possible d’avoir plusieurs ports associés à un seul Hidden Service.

Les lignes 10 et 14 définissent les répertoires où seront stockées les clefs privées et publiques de chaque service. Les lignes 11 et 12 définissent ensuite comment rediriger les ports publiés pour le premier service. La ligne 15 fournit un exemple de Hidden Service lié à un socket Unix, alors que la ligne 16 montre un Hidden Service publié sur une adresse IP publique.

Il faut ensuite redémarrer le daemon tor afin qu’il crée les répertoires des Hidden Services et génère le contenu nécessaire au fonctionnement de ceux-ci. Ces opérations doivent être faites avec l’opérateur privilégié (via sudopar exemple).

La dernière commande tapée permet de connaître le nom de votre Hidden Service (celui-ci correspond au blog personnel de l’auteur). Ce nom de domaine permet aux personnes utilisant Tor de se connecter à votre Hidden Service.

Voilà, vous êtes désormais l’heureux administrateur d’un Hidden Services, et pouvez dès à présent commencer à donner des sueurs froides à différents chefs d’État.

2.3 Hidden Service authentifié

Dans le cas où vous voudriez restreindre l’accès à votre Hidden Service, il est possible de mettre en œuvre un Hidden Service authentifié. Cela peut être utilisé pour mettre en place des interfaces de supervision ou fournir un service réservé à certains utilisateurs tout en dissimulant l’identité des visiteurs.

Il y a actuellement deux façons de faire, toutes les deux implémentées dans le protocole Tor. La première publie le Hidden Service, mais conditionne son accès a la connaissance d’un secret. La seconde dissimule l’existence du Hidden Service et nécessite de maintenir une liste des clients autorisés. Ces deux méthodes sont explicitées dans la spécification du protocole de Rendezvous [HSAUTH]. Nous utiliserons le cas décrit à la section 2.1 de [HSAUTH] et ne nécessitant pas de dissimuler l’existence du service.

Nous commencerons par configurer le serveur, il faudra ensuite configurer les clients pour leur permettre l’accès au service.

2.3.1 Configuration serveur

Il faut pour cela modifier votre fichier /etc/tor/torrc et ajouter une ligne de configuration dans le Hidden Service :

La ligne 11 permet de définir le type d’authentification (basic ou stealth selon que vous voulez avoir l’auth du type de la section 2.1 ou 2.2 de [HSAUTH], respectivement) suivi d’une liste de types de clients, séparés par des virgules. Chaque type de client se verra assigner un jeton différent, permettant ainsi de révoquer partiellement les accès.

Après redémarrage du service Tor, un nouveau fichier est visible dans le HiddenServiceDir :

Le descriptor-cookie est la chaîne qu’il vous faut transmettre aux clients afin qu’ils puissent se connecter à votre service. C’est en quelque sorte un jeton d’accès au service, qu’il faut avoir pour pouvoir utiliser le service.

2.3.2 Configuration du client

En attendant que le navigateur fourni par le Tor Project [TBB] permette d’accéder facilement aux Hidden Services authentifiés, il faut modifier la configuration côté client. Transmettre le jeton au client est hors du spectre de cet article, mais il faut considérer le descriptor-cookie comme un secret, et donc éviter de les diffuser publiquement (ceux utilisés pour cet article sont générés à titre d’exemple).

Le fichier du client se situe, dans le cas du navigateur Tor, dans le répertoire ./tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc. Il faut ajouter la ligne suivante à ce fichier pour authentifier le client sur le serveur :

L’accès au service depuis ce client est maintenant possible, tant que le descriptor-cookie est valide.

2.4 .onion certifiés TLS ou pas ?

L’obtention d’un certificat TLS valide pour les .onion est quelque chose de complexe. Let’s Encrypt, par exemple, ne le permet pas.

La validation par l’IETF du .onion comme extension valide [RFC7686] permet de faciliter la mise en place de ces certificats. Mais pour l’instant, à moins de vouloir faire de la validation d’entité, il n’est possible que de créer des certificats auto-signés. De plus, le protocole Tor chiffrant la communication de bout en bout, la pertinence du TLS pour les Hidden Services n’est pas évidente.

Il est cependant important de proposer du TLS – même via un certificat auto-signé – notamment si le nœud Tor fournissant le Hidden Service et le service hébergé ne sont pas sur les mêmes machines. Après tout, les mots « SSL added and removed here ;-) » [NSA] doivent vous dire quelque chose et sont une justification suffisante pour activer TLS. Cela permet de protéger les communications de vos utilisateurs entre le Hidden Service et le service réel.

Nous conseillons donc de mettre en place un certificat TLS auto-signé, ou associé au nom du site en clair, quitte à générer un avertissement de sécurité, lorsqu’un utilisateur viendra sur votre Hidden Service.

Le Forum CA/B – en charge de définir les règles des autorités de certifications – a imposé une validation de type EV (Entity Validation) pour les certificats .onion [CAB144]. Cela empêche la génération de tels certificats par Let’s Encrypt, mais permet à d’autres organisations d’émettre des certificats valides. Par exemple, DigiCert fournit des certificats pour les .onion (e.g., celui de Facebook) [DCERT].

Allez lire ce qui a été écrit par le projet Tor à ce sujet pour plus de réflexion sur les tenants et aboutissants du TLS avec les .onions [TORTLS].

2.5 Sauce à l’échalote

Facebook a été une des premières grosses organisations à fournir un Hidden Service pour le grand public, permettant aux utilisateurs de facebook.com d’y accéder depuis facebookcorewwwi.onion. Cette suite de caractères est beaucoup plus simple à mémoriser (Facebook Core WWW Infrastructure) que la suite aléatoire proposée par défaut.

Pour cela, on utilise un outil permettant de générer de nombreuses paires de clefs pour des Hidden Services partageant un préfixe commun. Plus on veut de caractères identiques, plus le temps sera long pour que ces outils génèrent l’adresse.

Shallot (pour échalote en français) [SHAL] est un des outils disponibles pour effectuer cette opération.

Même avec la puissance de calcul de Facebook, générer un nom de Hidden Service de 16 caractères prend un temps supérieur à l’âge de l’humanité. D’après l’auteur du logiciel, il faut 2,6 millions d’années pour générer une telle adresse sur un processeur cadencé à 1.5 Ghz. Dans le cas de Facebook – comme pour les nombreux autres services – plusieurs adresses commençant par facebook ont été générées, probablement plusieurs centaines. Il a suffi ensuite à Facebook de choisir une adresse facile à mémoriser parmi celles-ci.

Il est beaucoup plus raisonnable de trouver un préfixe intéressant et de générer plusieurs adresses en  essayant d’en trouver une facile à mémoriser. Par exemple, en quelques heures, la Quadrature du Net a pu générer une adresse de Hidden Service relativement simple à mémoriser : lqdnwwwmaouokzmg.onion (LQDN, WWW, Maou, Ok, ZMG !!!!!!).

Shallot génère donc une clef RSA pour chaque Hidden Service trouvé correspondant au préfixe voulu :

Il suffit ensuite de copier/coller la clef privée RSA dans un fichier private_key dans le HiddenServiceDir correspondant à votre configuration et de redémarrer le daemon Tor pour que celui-ci génère le fichier hostname correspondant.

3. Faire mijoter à feu doux

Héberger un Hidden Service, plus encore que pour héberger n’importe quel type de service, nécessite de se poser la question de l’intégration dans l’infrastructure d’une organisation. RiseUp fournit quelques bonnes pratiques [RISE], mais quelques points spécifiques méritent de s’y attarder.

3.1 Boucle locale et supervision

Utiliser l'interface 127.0.0.1 comme interface du Hidden Service peut poser quelques problèmes. Les pages de statut des serveurs web par exemple sont généralement disponibles sur ces adresses ; il peut être judicieux de ne pas exposer ces informations à l’extérieur puisqu’elles révèlent énormément de choses sur l’activité du service. Dans le cas d’Apache, il est possible d’utiliser un port spécifique pour les hôtes virtuels des Hidden Services.

En raison de la nature parfois particulière des Hidden Service, les superviser est important. D’autant plus si vous hébergez un service populaire ou qui a pour but de recevoir des documents provenant de lanceurs d’alerte. De nombreux acteurs voudront s’intéresser à votre nœud. Il est donc important de pouvoir superviser ces services, sans révéler votre activité d’administration.

Un Hidden Service authentifié (cf. sous-section 2.3 supra) peut servir à annoncer un service de supervision tel que Munin ou exposer un shell SSH. C’est d’ailleurs ce que propose SecureDrop pour l’administration technique du service.

Si vous voulez publier un Hidden Service qui est un relais vers un site public, rien ne vous empêche de le diriger sur votre adresse publique dans la configuration du service, ce qui vous laisse libre de conserver la boucle locale pour vos besoins internes de supervision.

3.2 Réduire les empreintes serveur

De nombreux serveurs (Apache, Nginx, Postfix, etc.) annoncent des signatures à différents niveaux, permettant à un attaquant de déterminer de nombreux détails concernant vos services. Dans le cas d’Apache, cela peut se modifier dans la configuration du serveur [APA24].

3.3 Publier les .onion

Tout le monde n’hébergeant pas s5q54hfww56ov2xc.onion, il peut-être intéressant de publier ses Hidden Services. En particulier, si vous voulez que des sources vous transmettent des documents.

Une façon de faire est de publier un enregistrement de type TXT ou SRV dans votre zone DNS. C’est par exemple ce qui est fait par le projet OnionMX [OMX]. Cela peut permettre une découverte de service .onion par des applications. Si cette publication est en plus faite via DNSSEC, vous garantissez d’être en charge de ces services.

Vous pouvez aussi publier une liste des Hidden Services et signer cette liste avec une clef OpenPGP, permettant ainsi de prouver que c’est bien vous qui publiez ces services. C’est par exemple ce que fait RiseUp [RUPHS].

Enfin, il peut être possible de rediriger les visiteurs utilisant Tor depuis un site classique vers un Hidden Service. Cela peut par exemple se faire avec du JavaScript, en déterminant si le visiteur est capable de résoudre les noms de domaine en .onion. Si tel est le cas, alors ils peuvent utiliser le service et être redirigés vers celui-ci.

En intégrant ce script dans les <header> de votre page, cela permettra de rediriger au plus tôt les utilisateurs.

4. Faire gratiner les .onion avec SecureDrop

SecureDrop est une suite de logiciels permettant à une organisation de recevoir des documents d’une source en protégeant la source d’une part ainsi que le travail et l’infrastructure de l’organisation d’autre part.

Nous n’avons pas pour but de détailler l’intégralité de la configuration de cette suite, il existe une documentation exhaustive [SECD] et cela pourrait faire l’objet d’un dossier MISC à part entière.

4.1 Architecture de SecureDrop

SecureDrop est architecturé autour de trois machines principales, adjointes des stations de travail des investigateurs :

- La Secure Viewing Station qui est une machine ne disposant d’aucun moyen de connexion physique à un réseau – machine dite air-gapped – et fonctionnant avec [TAILS] et permettant aux investigateurs de lire et traiter les documents reçus sans compromettre l’organisation. [SECD] détaille le matériel pouvant être utilisé et comment réaliser une telle machine.

- L’Application Server, qui fonctionne sous Ubuntu, est le cœur du système. Le serveur héberge deux Hidden Services en plus du code applicatif. Le premier est un Hidden Service classique, appelé « interface source », le second est un Hidden Service authentifié, appelé « interface documents », qui est destiné aux journalistes.

- Le Monitor Server est un serveur Ubuntu qui supervise l’Application Server et envoie des alertes mails aux administrateurs.

La circulation de l’information entre les différentes machines et les stations de travail des investigateurs nécessite de nombreuses clefs Tails, ou des DVD non réinscriptibles. La complexité de l’infrastructure nécessite de former régulièrement les personnes devant utiliser ce système.

4.2 Les Hidden Services de SecureDrop

SecureDrop propose donc deux Hidden Service : l’interface source et l’interface documents. L’interface source est l’interface accessible depuis l’extérieur du périmètre de l’organisation et qui doit faire l’objet de diffusion au public. L’interface source est également utilisée par les administrateurs pour se connecter à distance – via SSH – à l’Application Server pour y faire les opérations de maintenance et de mise à jour.

Le second Hidden Service, l’interface documents, n’est accédée que depuis l’intérieur de l’organisation et est destinée aux investigateurs. Ils doivent s’y connecter régulièrement en utilisant [TAILS] pour vérifier la disponibilité de nouveaux documents ou recontacter la source.

4.3 Publier l’instance

Il est important que la source puisse trouver votre instance SecureDrop afin de pouvoir vous transmettre des documents. Dans notre cas, c’est une partie critique, car l’attaquant peut détecter le trafic de la source et voir si elle visite une plateforme de leak. Quelques précautions doivent être prises pour ce service.

Protégez cette page par TLS. Il ne doit pas être possible d’y accéder sans un certificat valide, pensez donc à configurer le serveur avec HSTS pour forcer une redirection vers https.

N’utilisez pas un sous-domaine spécifique, mais un chemin dédié tel que https://example.com/securedrop. En conjonction avec le TLS, quelqu’un qui intercepterait le trafic – et notamment en écoutant les requêtes DNS de la source – ne pourrait pas détecter que la source est allée visiter un site à risque, vu que seul le nom de domaine sera visible en clair.

N’embarquez pas de JavaScript ou de système de mesure d’audience ou d’analyse de comportement des visiteurs. Vous n’avez pas besoin d’avoir de statistiques de visites sur cette page, une page au contenu statique contenant quelques instructions pour installer [TBB] ou [TAILS] et se connecter au Hidden Service est suffisante.

Désactivez les logs sur cette partie de votre site. Vous ne voulez pas que quelqu’un qui a accès à vos fichiers de logs puisse identifier qui visite votre page publiant SecureDrop.

Enfin, [FPF] maintient une liste validée de plateformes SecureDrop. Il est possible de soumettre la vôtre afin de la faire connaître.

Conclusion

Nous en avons terminé avec cette présentation des Hidden Services et de leur utilisation. Nous espérons que vous n’hésiterez pas à en installer et en administrer et que vous vous intéresserez aux problématiques de protections des sources.

SecureDrop est cependant un outil complexe à mettre en place par une organisation, tâche qui ne doit pas être faite à la légère. Comme tout système critique, il est important de passer du temps à le maintenir. De plus une formation régulière des utilisateurs est plus que nécessaire.

Références

[SKROAD] Y. Eudes, « Comment le FBI a fait tomber Silk Road », https://www.lemonde.fr/pixels/article/2014/09/09/comment-le-fbi-a-fait-tomber-silk-road_4484272_4408996.html

[RICO] Ricochet.im, Anonymous instant messsageing for real privacy, https://ricochet.im

[LUXL] B.Cassel, « Procès LuxLeaks : Un lanceur d’alerte devant les juges » :https://www.leparisien.fr/economie/un-lanceur-d-alerte-devant-les-juges-12-12-2016-6444180.php

[TOR] Page officielle du Projet Tor : https://torproject.org/

[ONION] R. Dingledine, N. Matthewson et P. Syverson, « Tor : The second-generation onion router», https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf

[RDV] Tor : Hidden service protocol : https://www.torproject.org/docs/hidden-services.html.en

[DEB] Tor on Debian : https://www.torproject.org/docs/debian.html.en

[HSAUTH] Tor Project, « Rendezvous Specifications », https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt

[RFC7686] J. Applebaum et A. Muffet, « The .onion Special Use Domain Name », IETF, 2015 : https://tools.ietf.org/html/rfc7686

[NSA] SSL added and removed here ;-) : https://blog.getcloak.com/2013/11/05/ssl-added-and-removed-here-nsa-smiley/

[DCERT] .Onion Officially Recognized as Special-Use Domain : https://www.digicert.com/blog/onion-officially-recognized-special-use-domain/

[CAB144] Forum CA/B, « Ballot 144 – Validation rules for .onion names » : https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

[SHAL] GitHub pour Shallot : https://github.com/katmagic/Shallot

[RISE] Tor Hidden (Onions) services good practices : https://riseup.net/fr/security/network-security/tor/onionservices-best-practices

[APA24] Apache 2.4 Server-Wide Documentation : https://httpd.apache.org/docs/2.4/server-wide.html

[OMX] Le projet Onion MX : https://github.com/ehloonion/onionmx

[RUPHS] Hidden Services proposés par Riseup : https://riseup.net/fr/security/network-security/tor#riseups-tor-hidden-services

[TBB] Tor Browser Bundle : https://www.torproject.org/projects/torbrowser.html.en

[SECD] Documentation de SecureDrop : https://docs.securedrop.org/en/stable/

[TAILS] The Anonymous and Incognito Live System : https://tails.boum.org

[FPF] The Official SecureDrop Directory : https://securedrop.org/directory

[TORTLS] Facebook, Hidden Services and HTTPS : https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs