🤚🏻 📟 🧛🏿 Wie Protonmail in Russland blockiert wird 🙏🏽 🛤️ 👨🏿‍🎤

Englische Version des Beitrags

Ein völlig routinemäßiges Trouble Ticket für unseren technischen Support enthüllte eine weitere seltsame Blockierung der Protonmail-Service-Community, die ihre Internet-Freiheiten respektiert, in einigen russischen Netzwerken. Ich würde die „gelbe Überschrift“ nicht ausnutzen wollen, aber die Geschichte ist seltsam und etwas empörend.

TL; DR

Wichtiger Hinweis: Das Parsen wird fortgesetzt und bis jetzt ist alles in Bearbeitung. Vielleicht gibt es keinen Jungen, aber höchstwahrscheinlich. Wird ergänzt, sobald neue Informationen verfügbar sind.

Die größten russischen Telekommunikationsbetreiber MTS und Rostelecom blockieren den Datenverkehr zu den SMTP-Servern des sicheren Protonmail-E-Mail-Dienstes per Brief des FSB. Anscheinend ist es lange genug her, aber bisher hat niemand viel Aufmerksamkeit geschenkt. Und hier sind wir.

WTF und Brennen gehen weiter, alle Teilnehmer haben relevante Anfragen erhalten und müssen begründete Antworten geben.

UPD: MTS lieferte einen Scan des FSB-Briefes, der zum Blockieren verwendet wird. Motivation: Universiade und „Telefoterrorismus“. Damit Briefe von ProtonMail nicht in die störenden Adressen von Wellnessangeboten und Schulen fallen.

UPD: Protonmail war überrascht über die Methoden des Betrugs mit "diesen seltsamen Russen" und empfahl eine effektivere Art des Kampfes durch Missbrauchspostfach.

UPD: Das galante Konzept des Kampfes des FSB gegen falsche Adressen hat der Kritik nicht standgehalten: Sie haben eingehende E-Mails an ProtonMail und keine ausgehenden E-Mails mit einem Brief gebrochen.

UPD: Protonmail zuckte mit den Schultern und änderte die IP-Adressen ihrer MXs, sodass sie nicht durch diese bestimmte E-Mail blockiert wurden. Die Frage ist, was weiter offen sein wird.

UPD: Anscheinend ist ein solcher Brief keiner und es gibt immer noch eine Reihe von IP-Adressen von VOIP-Diensten, die nicht registriert blockiert sind.

UPD: Als sich die Geschichte außerhalb des Runet zu verbreiten begann, haben wir eine Übersetzung ins Englische vorbereitet, den Link oben.

Wir lieben unsere Habra-Benutzer für die Tatsache, dass sie technisch versiert sind. Technisch versierte Benutzer wissen, was „Computerhygiene“ ist. Einige unserer Benutzer haben sich für den "sicheren E-Mail" -Dienst von Protonmail entschieden. Abgesehen von der Diskussion über den Service selbst, sein Produkt und sein Geschäftsmodell werden wir nur wichtige technische Punkte diskutieren.

Jeden Tag senden wir viele E-Mails an unsere Benutzer. Da wir uns um unsere Unabhängigkeit und deren Privatsphäre sorgen, verwenden wir keine E-Mail-Verteilungsdienste (ESP) von Drittanbietern, um die meisten Arten von Nachrichten zu senden. Zu diesem Zweck nutzen wir unsere Kapazitäten, von von uns kontrollierten Bare-Metal-Servern und MX-Servern bis hin zur Verschlüsselung von Verbindungen und dem Besitz unserer unabhängigen IP-Adressen.

Letzte Woche haben wir viele Anrufe von Protonmail-Benutzern an unser Ticket-Support-System erhalten, dass unsere Briefe sie nicht erreicht haben.

Die grundlegende Antwort unseres technischen Supports war natürlich der Vorschlag, nach anderen typischen Lösungen für typische Spam-Probleme zu suchen, aber das Volumen der Anfragen veranlasste uns, das Problem genauer zu verstehen. Und dann alles einpacken ...

Kurze Beschreibung der Funktionsweise von E-Mails

Für die meisten modernen Internetnutzer besteht die Verwendung von E-Mail darin, dass ein Browser die „persönliche Box“ auf der Website des E-Mail-Dienstanbieters eingibt und über dieselbe Weboberfläche einen Brief verfasst und an den Empfänger sendet. Mit Hilfe von etwas Magie erscheint der Brief nach einem Moment in der Weboberfläche des E-Mail-Dienstes des Empfängers.

Also: Die Magie heißt SMTP (esmtp, um genau zu sein). Der Server des Absenders extrahiert den Domänenteil (nach @) aus der Postfachadresse des Empfängers und führt eine DNS-Abfrage durch, um eine Liste der MX-Server der Domäne des Empfängers zu erhalten. Für support@habr.team sieht es ungefähr so aus:

MX-Server, wörtlich "Mail Exchange Server" (Mail Exchange). Es gibt an, auf welchem E-Mail-Dienst sich die Domain-E-Mail des Empfängers befindet. Genauer gesagt, über welche E-Mail-Server die Hosting-Domain des Empfängers E-Mails empfängt . Das obige Beispiel zeigt, dass sich die Mailserver für unsere habr.team-Domain auf Google-Servern befinden (g. Suite).

Nach dem Erstellen der Liste der Empfänger-MX-Server wird auf esmtp (s) auf den Server mit der niedrigsten Prioritätsnummer zugegriffen, um E-Mails an den Benutzer zu übertragen. Bei mehreren Servern wird die Anzahl der Server in der Liste festgelegt, um die Fehlertoleranz zu gewährleisten, da die Internetverbindung häufig an Bedingungen geknüpft ist.

Die Nachrichtenübertragung sieht ungefähr so aus:

Ein wichtiger Hinweis: E-Mails von einer bestimmten Domain sind nicht verpflichtet, Empfänger von in DNS angegebenen MX-Servern zu verlassen. Dieser Mechanismus wird nur für eingehende E-Mails verwendet. Ausgehende E-Mails von einer Domäne können über andere Server übertragen werden, von denen eine ungefähre Liste in der Regel in einem anderen SPF-Datensatz angegeben ist.

Wir begannen, E-Mail-Protokolle zu durchsuchen und stellten fest, dass die Verbindungen unserer Server mit Protonmail MX-Servern (185.70.40.40.101, 185.70.40.40.102) mit Netzwerk-Timeouts endeten. Dies sah aus mehreren Gründen seltsam aus und ähnelte der Verwendung des in Russland praktizierten Blockierungsmechanismus.

Natürlich entschuldige ich mich wild, aber hier ist ein weiterer Spoiler: kurz darüber, wie das Internet, autonome Systeme und globales Routing funktionieren

Im Allgemeinen wird der Begriff „Internet“ wörtlich übersetzt als „Inter-Network“, er kann nach Belieben als „Network of Networks“ und „Networking“ übersetzt werden. Tatsächlich hat das Internet kein „technisches Zentrum“ (im Gegensatz zu einem „Organisationszentrum“), sondern eine Vereinigung verschiedener Netzwerke, die einander gleich sind, obwohl es Netzwerke gibt, die „gleicher“ sind als andere, aber dies ist eine andere Geschichte. Netzwerke werden als "Autonome Systeme" (AS) bezeichnet und sind durch Verbindungen (Peers) miteinander verbunden. Jedes autonome System hat eine eindeutige Nummer, anhand derer es von einem anderen autonomen System im Internet identifiziert wird. Es sieht aus wie IP-Adressen, aber mit mehr "großen Pinselstrichen". Jedes Netzwerk empfängt vom Nachbarn Daten über die Topologie seiner Verbindungen mit seinen Nachbarn, die Verbindung seiner Nachbarn mit ihren Nachbarn und so weiter. Das heißt, eine Karte der Verbindungen autonomer Systeme untereinander in Bezug auf diesen Übergang. Der Pfad auf dieser Karte von einem autonomen System zu einem anderen wird als AS-Pfad bezeichnet.

Zum Beispiel haben wir eine Autonomous System Number (ASN) 204671 , Protonmail- Server befinden sich im Netzwerk eines der größten amerikanischen Netzwerkkonzerne Neustar mit ASN 19905 . Wir haben zwei Schnittstellen mit verschiedenen Internetdienstanbietern, dh zwei mögliche AS-Pfade von uns zum Neustar-Netzwerk. Aus mehreren Gründen hat die Verbindung mit einem der MGTS-Betreiber für uns eine höhere Priorität, daher lautet der AS-Pfad wie folgt: 204671 (We) - 57681 (MGTS) - 8359 (MTS) - 22822 (Limelight) - 19905 (Neustar)

Die Karte sieht ungefähr so aus:

Die Traceroute zu einem der beiden Protonmail MX-Server landete im MTS-Netzwerk und sah ungefähr so aus:

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  *

Neustar 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

MX- Protonmail ( Neustar, , ):

$ 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

, traceroute , , , looking glass :

, . , , IP-:

, « », - . « », .

. , , .

. : « , , ». , , . : , 12/T/3/1-94 25.02.2019, -, .

- .

. - « . -, , -, » « , , , , … , , , . " " = ), , )». , , , «», « », « » , .

, , .

— , MX- RIPE Atlas, , : , , , , ( MX- Protonmail , MX- Protonmail ). , ( MX- Protonmail , MX- Protonmail )

, :

, . « », — 2019:

Protonmail reddit, TechCrunch, , :

We have a dedicated team at abuse@protonmail.ch that helps to combat illegal activities. We were never contacted. Blocking MX like this does not make sense for the given "explanation" so we suspect something else is going on.
— ProtonMail (@ProtonMail) March 11, 2019

, , . , , . , , SMTP- , MX- — . , , , . :

, ( , , - «nslookup »);
( );
, .

: ProtonMail , IP-, . 185.70.40.101 185.70.40.102, :

ProtonMail TechCrunch , , , , :

ProtonMail chief executive Andy Yen called the block “particularly sneaky,” in an email to TechCrunch.

“ProtonMail is not blocked in the normal way, it’s actually a bit more subtle,” said Yen. “They are blocking access to ProtonMail mail servers. So Mail.ru — and most other Russian mail servers — for example, is no longer able to deliver email to ProtonMail, but a Russian user has no problem getting to their inbox,” he said.

“The wholesale blocking of ProtonMail in a way that hurts all Russian citizens who want greater online security seems like a poor approach,” said Yen. He said his service offers superior security and encryption to other mail providing rivals in the country.

“We have also implemented technical measures to ensure continued service for our users in Russia and we have been making good progress in this regard,” he explained. “If there is indeed a legitimate legal complaint, we encourage the Russian government to reconsider their position and solve problems by following established international law and legal procedures.”
— ProtonMail chief executive Andy Yen @ TechCrunch

, Protonmail IP- MX 185.70.40.101 185.70.40.103, . — .

, , email- IP-. .

, ? , ZaTelecom :

, , , , : AS Neustar , /32 .