Un ticket de support technique complètement routinier a révélé des interdictions inattendues d'adresses IP de Protonmail - un service très utile pour les personnes qui valorisent leurs libertés Internet - dans plusieurs régions de Russie. Je ne voulais vraiment pas sensationnaliser le titre, mais l'histoire est si étrange et inexplicable que je n'ai pas pu résister.
TL; DR
Avertissement: la situation évolue encore. Il n'y a peut-être rien de malveillant, mais très probablement. Je mettrai à jour le message une fois que de nouvelles informations seront transmises.
MTS et Rostelecom - deux des plus grands FAI russes - ont commencé à bloquer le trafic vers les serveurs SMTP du service de messagerie crypté Protonmail conformément à une demande du FSB, sans tenir compte du registre officiel du gouvernement des sites Web restreints. Il semble que cela se produise depuis un certain temps, mais personne n'y a prêté une attention particulière. Jusqu'à maintenant.
Toutes les parties concernées ont reçu des demandes d'informations pertinentes auxquelles elles sont tenues de répondre.
UPD: MTS a fourni une numérisation de la lettre FSB, qui est la base pour restreindre l'accès. Justification: l'Universiade en cours à Krasnoïarsk et le "terrorisme téléphonique". Il est censé empêcher les e-mails ProtonMail d'aller aux adresses d'urgence des services de sécurité et des écoles.
UPD: Protonmail a été surpris par «ces étranges Russes» et leurs méthodes de lutte contre les abus de fraude, et a suggéré un moyen plus efficace de le faire - via la boîte aux lettres des abus .
UPD: La justification du FSB ne semble pas être vraie: les interdictions ont cassé le courrier entrant de ProtonMail, plutôt que le courrier sortant.
UPD: Protonmail haussa les épaules et changea les adresses IP de leurs MX en les retirant du blocage après cette lettre FSB particulière. Ce qui se passera ensuite est une question ouverte.
UPD: Apparemment, cette lettre n'était pas la seule et il existe encore un ensemble d'adresses IP de services VOIP qui sont bloquées sans enregistrements appropriés dans le registre officiel des sites Web restreints.
Nous aimons nos utilisateurs Habr car ils sont très avertis en technologie. Ils comprennent ce que signifie «hygiène informatique». Certains de nos utilisateurs utilisent Protonmail - un service de «messagerie cryptée». Nous ne discuterons que de la question technologique aujourd'hui, laissant de côté la discussion sur le service lui-même et son modèle commercial.
Chaque jour, nous envoyons de nombreux e-mails à nos utilisateurs, et comme nous nous soucions de notre indépendance et de leur confidentialité, nous n'utilisons pas de services de messagerie externes (ESP). Au lieu de cela, nous utilisons nos propres ressources, des serveurs sans système d'exploitation et des serveurs MX auto-entretenus au chiffrement des connexions et à la propriété de nos adresses IP indépendantes.
La semaine dernière, notre équipe d'assistance a été surchargée par les messages des utilisateurs de Protonmail, se plaignant que notre courrier ne leur parvient pas:
Bonjour Depuis la première semaine de mars 2019 environ, lorsque j'essaie de me connecter, je reçois une bannière rouge indiquant qu'ils ne pouvaient pas envoyer d'e-mail à mon adresse. J'ai essayé d'envoyer un message de test manuellement, en vain. La boîte aux lettres elle-même, hébergée par Protomail, est parfaitement fonctionnelle (les autres courriels passent bien). Le dernier condensé de Habr date du 28 février.
Je n'ai modifié aucun des paramètres ni là ni sur Protomail, mais au moment où le problème est apparu pour la première fois, j'étais déconnecté de l'application Android.
Je ne pense pas que le compte a été compromis, mais je n'ai pas pu trouver la liste des IP utilisées pour y accéder, donc je ne peux pas en être sûr. J'espère pour votre aide, car sans e-mail fonctionnel, je ne peux pas voter sur les commentaires / messages.
Modification de l'adresse e-mail de Gmail en Protomail. L'e-mail de confirmation n'arrive pas à la nouvelle adresse.
Bien sûr, notre support technique a suggéré des trucs simples comme la vérification des dossiers de spam, mais le volume de plaintes similaires nous a obligés à creuser plus profondément.
En bref sur le fonctionnement du courrier électroniquePour la plupart des utilisateurs d'Internet modernes, utiliser le courrier électronique signifie se connecter à la «boîte de réception personnelle» sur le site Web du fournisseur de services de messagerie, puis envoyer des lettres via la même interface Web. Ensuite, un peu de magie se produit et quelques instants plus tard, la lettre arrive sur l'interface Web du côté destinataire.
Cette «magie» est appelée SMTP (ou esmtp, pour être précis). Le serveur d'envoi extrait la partie de domaine (après le @) de l'adresse de réception et effectue une demande DNS pour les serveurs MX du domaine du récepteur. Pour support@habr.team, cela ressemble à ceci:
MX signifie «échange de courrier». Il indique le service de messagerie utilisé par le destinataire ou, pour être précis, les serveurs de messagerie hébergés par le domaine destinataire qui collectent les nouveaux messages. L'exemple ci-dessus montre que notre domaine, habr.team, est hébergé par Google (G.Suite).
Après avoir trouvé les serveurs MX, une demande est faite via le protocole esmtp au serveur avec la priorité la plus élevée, pour remettre le courrier à l'utilisateur. Plusieurs serveurs sont répertoriés pour la redondance, car «l'interconnectivité» d'Internet est un terme très relatif.
Voilà à quoi ressemble l'envoi d'une lettre:
NB: le courrier d'un certain domaine ne doit pas nécessairement être envoyé aux utilisateurs sur les serveurs MX répertoriés dans le DNS; ceci n'est utilisé que pour le courrier entrant. Le courrier sortant peut être transféré via d'autres serveurs, généralement répertoriés dans un enregistrement SPF.
Nous avons fouillé dans nos journaux de messagerie et découvert que les tentatives de connexion de nos serveurs aux serveurs MX de Protomail (185.70.40.101, 185.70.40.102) expiraient toujours. Cela semblait étrange pour un certain nombre de raisons et ressemblait au mécanisme de censure d'Internet en Russie.
Je suis vraiment désolé, mais je dois m'éloigner et vous dire comment fonctionnent Internet, les systèmes autonomes et le routageEn général, le terme «Internet» est composé de deux mots: «Internet» et peut être interprété comme «réseau de réseaux» ou «réseaux unis». Internet n'a pas de «centre technique» (bien qu'il ait un «centre d'organisation»): il relie simplement différents réseaux qui sont, en théorie, égaux entre eux (bien que certains réseaux soient plus égaux que d'autres, mais c'est une histoire pour un autre jour). Les réseaux sont appelés «systèmes autonomes» (AS) et sont connectés les uns aux autres via des portes, ou «pairs». Chaque AS a un numéro unique utilisé pour l'identifier par d'autres AS. Comme les adresses IP, mais d'une manière plus générale. Chaque réseau reçoit de ses «voisins» la topologie de ses connexions aux réseaux proches, comment ces réseaux proches se connectent à leurs réseaux proches, etc. Essentiellement, chaque réseau a une carte de la façon dont tous les AS se connectent les uns aux autres du point de vue de ce réseau. Un itinéraire d'un AS à un autre selon cette carte est simplement appelé «chemin AS».
Par exemple, notre numéro de système autonome (ASN) est 204671, les serveurs Protonmail sont hébergés sur le réseau d'une grande société américaine Neustar, et son ASN est 19905. Nous avons deux portes avec des FAI, ce qui signifie deux chemins AS possibles de nous à Neustar réseau. Pour un certain nombre de raisons, l'une des portes (via MGTS) est préférable, donc notre chemin AS ressemble à ceci: 204671 (us) - 57681 (MGTS, le FAI), 8359 (MTS, le plus grand FAI) - 22822 (Limelight ) - 19905 (Neustar).
Et voici la table de routage:
Chaque traceroute vers l'un des deux serveurs MX de Protonmail coupé sur le réseau MTS et ressemblait à ceci:
GW-Core-R3#traceroute ip 185.70.40.101 probe 1 timeout 3 Type escape sequence to abort. Tracing the route to 185.70.40.101 VRF info: (vrf in name/id, vrf out name/id) 1 185.2.126.73 [AS 57681] 2 msec 2 212.188.12.73 [AS 8359] 2 msec 3 195.34.50.73 [AS 8359] 3 msec 4 212.188.55.2 [AS 8359] 3 msec 5 * 6 * 7 * 8 *
Nous avons trouvé un hôte alternatif au sein du réseau Neustar et l'avons utilisé comme référence pour éliminer les éventuelles perturbations entre MTS et Limelight:
GW-Core-R3#traceroute ip 156.154.208.234 probe 1 timeout 3 Type escape sequence to abort. Tracing the route to 156.154.208.234 VRF info: (vrf in name/id, vrf out name/id) 1 185.2.126.73 [AS 57681] 2 msec 2 212.188.12.73 [AS 8359] 2 msec 3 212.188.2.37 [AS 8359] 14 msec 4 212.188.54.2 [AS 8359] 20 msec 5 195.34.50.146 [AS 8359] 27 msec 6 195.34.38.54 [AS 8359] 37 msec 7 68.142.82.159 [AS 22822] 26 msec 8 * 9 156.154.208.234 [AS 19905] 26 msec
Pendant ce temps, nous avons terminé avec succès une autre trace via un autre FAI vers les serveurs MX de Protonmail (il s'arrête chez Neustar, mais c'est prévu - la connexion fonctionne toujours):
$ traceroute -a 185.70.40.101 traceroute to 185.70.40.101 (185.70.40.101), 64 hops max, 52 byte packets 1 [AS49063] hidden (hidden) 5.149 ms 268.571 ms 6.707 ms 2 [AS49063] 185.99.11.146 (185.99.11.146) 5.161 ms 6.317 ms 5.476 ms 3 [AS0] 10.200.16.128 (10.200.16.128) 5.588 ms [AS0] 10.200.16.176 (10.200.16.176) 5.225 ms [AS0] 10.200.16.130 (10.200.16.130) 5.001 ms 4 [AS0] 10.200.16.49 (10.200.16.49) 6.480 ms [AS0] 10.200.16.156 (10.200.16.156) 5.439 ms 7.469 ms 5 [AS20764] 80-64-98-234.rascom.as20764.net (80.64.98.234) 6.208 ms 9.301 ms 6.348 ms 6 [AS20764] 80-64-100-102.rascom.as20764.net (80.64.100.102) 24.281 ms [AS20764] 80-64-100-86.rascom.as20764.net (80.64.100.86) 54.632 ms 23.936 ms 7 [AS20764] 81-27-254-223.rascom.as20764.net (81.27.254.223) 27.589 ms 116.438 ms 27.348 ms 8 [AS22822] siteprotect.security.neustar (68.142.82.153) 28.683 ms 25.376 ms 41.489 ms
Étant donné que traceroute n'est pas un outil très fiable, nous avons mené quelques autres expériences, par exemple, avec le service Looking Glass de MTS:
Il est devenu clair qu'il s'agit probablement d'une restriction intentionnelle du service au niveau MTS. Cependant, la consultation du registre officiel de Roskomnadzor a révélé que les deux adresses (ni nom de domaine ni adresse IP) n'y figurent pas:
Impossible de trouver quoi que ce soit sur votre demande
Laissant de côté les spécificités de la censure d'Internet en Russie, il n'y a qu'une seule justification valable pour qu'un FAI bloque une ressource - le soi-disant «vidage de registre» contenant la ressource qui y est placée plus ou moins légalement. Parfois, les ressources sont bloquées sans entrée de registre pertinente (elles sont communément appelées «blocage sans registre»), et généralement la justification de celles-ci n'a aucune chance dans aucun cas juridique.
À ce stade, nous soupçonnions un simple malentendu technique ou un déverrouillage bâclé d'un autre site non lié. Oui, nous ne sonnons pas les alarmes sans tout vérifier méticuleusement au préalable.
Nous avons envoyé un e-mail détaillant nos résultats au support technique MGTS et avons demandé des éclaircissements. Un peu plus tard, nous avons reçu une non-réponse: «ce n'est pas nous, c'est MTS, demandez-leur.» Bien sûr, nous ne l'avons pas fait, mais à la place, nous avons forcé MGTS à faire son travail et à enquêter correctement. La réponse que nous avons reçue était très intéressante: selon un employé de MTS du département concerné, le FSB les a contactés via une lettre officielle n ° 12 / T / 3 / 1-94 du 25 février 2019, leur demandant de bloquer d'urgence ces hôtes:
À ce stade, nos détecteurs de conneries ont dépassé l'échelle et nous avons creusé encore plus profondément. Et plus vite.
Nous avons envoyé une demande au FSB pour lui demander si la lettre existe et si oui, quelle justification ont-ils:
Nous avons également demandé à MGTS de fournir une justification:
Après cela, nous sommes allés dans des salles de discussion thématiques dans un certain service de messagerie instantanée illégal en Russie. La communauté des télécommunications a réagi à contrecœur:
- «J'avais de l'expérience dans la résolution de ces problèmes et personne ne veut utiliser les outils de RKN. Tout d'abord, c'est compliqué. Deuxièmement, le transfert du problème à un autre service ne résout pas le problème. "
- "Vous devez fournir tellement de documentation et sauter à travers tellement de cerceaux bureaucratiques (et il y a une sanction financière pour ne pas faire tout cela) que personne ne dérange."
Eh bien, il est difficile de vraiment les juger, étant donné que ceux qui travaillent dans les télécommunications doivent faire face à tant de conneries (considérant que «SORM», «nœud de réseau» ou «vidage de registre» ne sont pas seulement des mots pour eux, mais une gêne quotidienne) .
Néanmoins, le salon de discussion de la communauté russe de défense d'Internet a pris l'affaire avec enthousiasme et a mené une enquête appropriée.
Ils ont suggéré une idée intéressante - pour vérifier quels FAI (en Russie et ailleurs) bloquent l'accès aux serveurs MX via RIPE Atlas . Les résultats étaient prévisibles, mais toujours très curieux: en Russie, les serveurs sont bloqués par MTS et Rostelecom, ainsi que les réseaux fonctionnant via ces deux FAI ( résultats sur le serveur MX principal et celui de sauvegarde ). La vérification mondiale a détecté des problèmes en Russie, en Ukraine et en Iran ( résultats mondiaux pour le serveur principal et la sauvegarde ).
Une recherche plus approfondie a montré que Rostelecom agit de manière similaire:
Après le week-end, MTS a finalement fourni une numérisation de la lettre du FSB qui commandait les blocs. Bien sûr, ils ont blâmé les «terroristes téléphoniques» et ont tout lié aux XXIXes Jeux mondiaux universitaires d'hiver - Universiade 2019:
Les représentants de Protomail ont ensuite réagi sur reddit , Twitter et TechCrunch . Comme prévu, ils ont été surpris par la brutalité des méthodes du FSB et ont proposé de coopérer pour trouver de vrais criminels:
Hmm. Protomail eux-mêmes soupçonnait que tout cela était caché. Eh bien, cela semble être le cas. Ainsi, comme je l'ai déjà expliqué avobe, les enregistrements MX sont un mécanisme pour gérer les e-mails entrants. Le FSB a clairement délibérément cassé le courrier entrant plutôt que le courrier sortant, de sorte que leur, ahem, "justification" de sauver les directeurs d'école des ennuis est très clairement fabriquée. Nous avons donc trois options:
- Ils ont simplement bloqué ce qu'ils avaient trouvé en premier (une explication paresseuse, mais la plus probable selon l'Occam Razor: quelqu'un doit avoir lu "nslookup for dummies");
- Ils ont essayé de limiter la possibilité de créer des adresses Proton anonymes et non traçables collectant des informations dommageables sur eux-mêmes (ne fonctionne pas dans la grande majorité des cas)
- L'explication superficielle de l'OVNI.
Voici la preuve: un e-mail envoyé de Proton à un autre service est passé par différentes IP qui ne sont pas bloquées. Rappelez-vous, FSB a interdit les 185.70.40.101 et 185.70.40.102. Les voyez-vous ici?
Le chef de ProtonMail a confirmé les conclusions à TechCrunch et a suggéré de lutter contre les activités terroristes en coopération avec les forces de l'ordre étrangères, plutôt que de simplement résoudre le problème:
Le directeur général de ProtonMail, Andy Yen, a qualifié le blocage de "particulièrement sournois" dans un e-mail à TechCrunch.
"ProtonMail n'est pas bloqué de manière normale, c'est en fait un peu plus subtil", a déclaré Yen. «Ils bloquent l'accès aux serveurs de messagerie ProtonMail. Ainsi, Mail.ru - et la plupart des autres serveurs de messagerie russes - par exemple, ne peuvent plus envoyer de courrier électronique à ProtonMail, mais un utilisateur russe n'a aucun problème à se rendre dans sa boîte de réception », a-t-il déclaré.
"Le blocage en gros de ProtonMail d'une manière qui blesse tous les citoyens russes qui veulent une plus grande sécurité en ligne semble être une mauvaise approche", a déclaré Yen. Il a déclaré que son service offre une sécurité et un cryptage supérieurs à ceux des autres fournisseurs de courrier du pays.
«Nous avons également mis en œuvre des mesures techniques pour assurer un service continu à nos utilisateurs en Russie et nous avons bien progressé à cet égard», a-t-il expliqué. «S'il y a effectivement une plainte légale légitime, nous encourageons le gouvernement russe à reconsidérer sa position et à résoudre les problèmes en suivant le droit international et les procédures juridiques établis.»
- Andy Yen, PDG de ProtonMail @ TechCrunch
En outre, il semble que cette lettre FSB ne soit commandée que pour bloquer les serveurs SMTP pour le courrier entrant. L'accès au Web et les serveurs SMTP sortants fonctionnent toujours, ce qui signifie que quoi que le FSB ait essayé de faire, ils n'étaient pas très bons dans ce domaine.
Nous le redisons: même sans tenir compte de toute la dimension juridique de la question de la régulation d'Internet sur le très particulier 1/8 de la Terre, il existe des règles du jeu. Les règles ne sont pas terriblement claires, très ambiguës et elles changent tout le temps, mais ce sont toujours des règles, même si elles sont clairement conçues pour bénéficier aux responsables de ces règles. Et même alors, il y a des gens qui essaient de les contourner. C'était très Kafka-esque, sans aucune procédure régulière. Au moins dans toute affaire judiciaire, vous pouvez faire appel à un expert de l'industrie pour consultation, mais là, la décision était uniquement basée sur la vision personnelle du monde d'une personne en particulier.
Voici donc tous les faits que nous avons rassemblés jusqu'à présent. Toutes les demandes ont été envoyées, mais toutes n'ont pas reçu de réponse. Bien sûr, nous espérions que ce n'était qu'une conséquence d'un travail bâclé par quelqu'un chez MTS, mais, pour être honnête, cela ne semblait pas très probable dès le départ.
Quant à nos utilisateurs qui utilisent également Protomail, ils peuvent continuer à utiliser leurs boîtes aux lettres Proton avec Habr en toute sécurité, car nous avons redirigé le trafic de notre part vers le service Protomail via un autre FAI russe qui ne joue pas ce genre de jeux. Et MGTS est probablement sur le point de perdre un autre client.