Ein völlig routinemäßiges Ticket für den technischen Support hat unerwartete Verbote von IP-Adressen von Protonmail - einem sehr nützlichen Dienst für Menschen, die ihre Internetfreiheiten schätzen - in mehreren Regionen Russlands aufgedeckt. Ich wollte die Überschrift ernsthaft nicht sensationell machen, aber die Geschichte ist so seltsam und unerklärlich, dass ich nicht widerstehen konnte.
TL; DR
Haftungsausschluss: Die Situation entwickelt sich weiter. Es gibt vielleicht nichts Bösartiges, aber höchstwahrscheinlich. Ich werde den Beitrag aktualisieren, sobald neue Informationen eingehen.
MTS und Rostelecom - zwei der größten russischen ISPs - haben laut einer FSB-Anfrage begonnen, den Datenverkehr zu SMTP-Servern des verschlüsselten E-Mail-Dienstes Protonmail zu blockieren, ohne Rücksicht auf das offizielle Regierungsregister für eingeschränkte Websites. Es scheint, als ob es schon eine Weile passiert ist, aber niemand hat besonders darauf geachtet. Bis jetzt.
Alle Beteiligten haben relevante Auskunftsersuchen erhalten, zu deren Beantwortung sie verpflichtet sind.
UPD: MTS hat einen Scan des FSB-Briefes bereitgestellt, der die Grundlage für die Einschränkung des Zugriffs darstellt. Begründung: die laufende Universiade in Krasnojarsk und der „Telefoterrorismus“. Es soll verhindern, dass ProtonMail-E-Mails an Notfalladressen von Sicherheitsdiensten und Schulen gesendet werden.
UPD: Protonmail war überrascht von „diesen seltsamen Russen“ und ihren Methoden zur Bekämpfung von Betrugsmissbrauch und schlug einen effektiveren Weg vor - über das Missbrauchspostfach .
UPD: Die Rechtfertigung von FSB scheint nicht wahr zu sein: Die Verbote haben die eingehenden E-Mails von ProtonMail gebrochen und nicht die ausgehenden.
UPD: Protonmail zuckte die Achseln und änderte die IP-Adressen ihrer MXs, um sie nach diesem bestimmten FSB-Brief aus der Blockierung zu entfernen. Was als nächstes passieren wird, ist eine offene Frage.
UPD: Anscheinend war ein solcher Brief nicht der einzige und es gibt immer noch eine Reihe von IP-Adressen von VOIP-Diensten, die ohne entsprechende Aufzeichnungen in der offiziellen Registrierung von eingeschränkten Websites blockiert sind.
Wir lieben unsere Habr-Benutzer, weil sie sehr technisch versiert sind. Sie verstehen, was „Computerhygiene“ bedeutet. Einige unserer Benutzer haben Protonmail verwendet - einen "verschlüsselten E-Mail" -Dienst. Wir werden heute nur die technologische Angelegenheit diskutieren und die Diskussion über den Service selbst und sein Geschäftsmodell beiseite lassen.
Jeden Tag senden wir viele E-Mails an unsere Benutzer. Da wir uns um unsere Unabhängigkeit und deren Privatsphäre kümmern, verwenden wir keine externen Mail-Dienste (ESPs). Stattdessen verwenden wir unsere eigenen Ressourcen, von Bare-Metal-Servern und selbstverwalteten MX-Servern bis hin zur Verschlüsselung von Verbindungen und dem Besitz unserer unabhängigen IP-Adressen.
Letzte Woche war unser Support-Team mit Nachrichten von Protonmail-Benutzern überlastet und beschwerte sich, dass unsere E-Mails nicht zu ihnen gelangen:
Hallo Seit ungefähr der ersten Märzwoche 2019, wenn ich versuche, mich anzumelden, wird ein rotes Banner angezeigt, das besagt, dass keine E-Mail an meine Adresse gesendet werden konnte. Ich habe versucht, eine Testnachricht manuell zu senden, ohne Erfolg. Die Mailbox selbst, die von Protomail gehostet wird, funktioniert einwandfrei (andere E-Mails kommen gut durch). Die letzte Zusammenfassung von Habr ist vom 28. Februar.
Ich habe weder dort noch in Protomail eine der Einstellungen geändert, aber als das Problem zum ersten Mal auftrat, wurde ich von der Android-App abgemeldet.
Ich glaube nicht, dass das Konto kompromittiert wurde, aber ich konnte die Liste der IPs, die für den Zugriff verwendet wurden, nicht finden, sodass ich nicht sicher sein kann. Ich hoffe auf Ihre Hilfe, da ich ohne eine funktionierende E-Mail nicht über Kommentare / Beiträge abstimmen kann.
Die E-Mail-Adresse wurde von Google Mail in Protomail geändert. Die Bestätigungs-E-Mail kommt nicht an die neue Adresse.
Natürlich schlug unser technischer Support einfache Dinge wie das Überprüfen von Spam-Ordnern vor, aber die schiere Menge ähnlicher Beschwerden zwang uns, tiefer zu graben.
Kurz darüber, wie E-Mail funktioniertFür die meisten modernen Internetnutzer bedeutet die Verwendung von E-Mail, dass sie sich im „persönlichen Posteingang“ auf der Website des E-Mail-Dienstanbieters anmelden und dann Briefe über dieselbe Weboberfläche senden. Dann passiert etwas Magie und ein paar Momente später kommt der Brief auf der Empfangsseite auf der Weboberfläche an.
Diese "Magie" heißt SMTP (oder esmtp, um genau zu sein). Der sendende Server extrahiert den Domänenteil (nach dem @) aus der empfangenden Adresse und sendet eine DNS-Anfrage für MX-Server der Domäne des Empfängers. Für support@habr.team sieht es so aus:
MX steht für "Mail Exchange". Es zeigt den vom Empfänger verwendeten E-Mail-Dienst an oder genauer gesagt, welche E-Mail-Server das Hosting der empfangenden Domain neue E-Mails sammelt. Das obige Beispiel zeigt, dass unsere Domain habr.team von Google (G.Suite) gehostet wird.
Nach dem Auffinden der MX-Server wird über das esmtp-Protokoll eine Anforderung an den Server mit der höchsten Priorität gestellt, die E-Mail an den Benutzer zuzustellen. Aus Redundanzgründen werden mehrere Server aufgelistet, da „Interkonnektivität“ des Internets ein sehr relativer Begriff ist.
So sieht das Versenden eines Briefes aus:
Hinweis: E-Mails von einer bestimmten Domäne müssen nicht unbedingt an Benutzer auf MX-Servern gesendet werden, die im DNS aufgeführt sind. Dies wird nur für eingehende E-Mails verwendet. Ausgehende E-Mails können über andere Server weitergeleitet werden, die normalerweise in einem SPF-Datensatz aufgeführt sind.
Wir haben unsere E-Mail-Protokolle durchsucht und festgestellt, dass die Verbindungsversuche von unseren Servern zu den MX-Servern von Protomail (185.70.40.101, 185.70.40.102) immer abgelaufen sind. Dies sah aus mehreren Gründen seltsam aus und ähnelte dem Mechanismus der Internet-Zensur in Russland.
Es tut mir schrecklich leid, aber ich muss abschweifen und Ihnen sagen, wie Internet, autonome Systeme und Routing funktionierenIm Allgemeinen besteht der Begriff „Internet“ aus zwei Wörtern: „Inter-Net“ und kann als „Netzwerk von Netzwerken“ oder „Vereinigte Netzwerke“ interpretiert werden. Das Internet hat kein „technisches Zentrum“ (obwohl es ein „Organisationszentrum“ hat): Es verbindet einfach verschiedene Netzwerke, die theoretisch gleich sind (obwohl einige Netzwerke gleich sind wie andere, aber das ist es eine Geschichte für einen anderen Tag). Netzwerke werden als "Autonome Systeme" (AS) bezeichnet und sind über Gates oder "Peers" miteinander verbunden. Jeder AS hat eine eindeutige Nummer, mit der er von anderen AS identifiziert wird. Wie IP-Adressen, aber allgemeiner. Jedes Netzwerk erhält von seinen „Nachbarn“ die Topologie seiner Verbindungen zu nahe gelegenen Netzwerken, wie diese nahe gelegenen Netzwerke mit ihren nahe gelegenen Netzwerken verbunden sind usw. Im Wesentlichen verfügt jedes Netzwerk über eine Karte, wie alle AS aus der Perspektive dieses Netzwerks miteinander verbunden sind. Eine Route von einem AS zu einem anderen gemäß dieser Karte wird einfach als "AS-Pfad" bezeichnet.
Unsere autonome Systemnummer (ASN) lautet beispielsweise 204671, Protonmail-Server werden im Netzwerk eines großen amerikanischen Unternehmens Neustar gehostet und der ASN lautet 19905. Wir haben zwei Gates mit ISPs, dh zwei mögliche AS-Pfade von uns zum Neustar Netzwerk. Aus einer Reihe von Gründen ist eines der Gates (über MGTS) vorzuziehen, daher sieht unser AS-Pfad folgendermaßen aus: 204671 (us) - 57681 (MGTS, ISP), 8359 (MTS, der größere ISP) - 22822 (Limelight) ) - 19905 (Neustar).
Und hier ist die Routing-Tabelle:
Jede Traceroute zu einem der beiden MX-Server von Protonmail wurde im MTS-Netzwerk abgeschnitten und sah folgendermaßen 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 *
Wir haben einen alternativen Host im Neustar-Netzwerk gefunden und ihn als Referenz verwendet, um mögliche Störungen zwischen MTS und Limelight zu beseitigen:
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
In der Zwischenzeit haben wir eine weitere Ablaufverfolgung über einen anderen ISP zu den MX-Servern von Protonmail erfolgreich abgeschlossen (bei Neustar wird die Verbindung unterbrochen, aber das wird erwartet - die Verbindung funktioniert immer noch):
$ 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
Da Traceroute kein sehr zuverlässiges Tool ist, haben wir einige weitere Experimente durchgeführt, beispielsweise mit dem Looking Glass-Service von MTS:
Es wurde klar, dass es sich wahrscheinlich um eine absichtliche Einschränkung des Dienstes auf MTS-Ebene handelt. Die Konsultation der offiziellen Registrierung von Roskomnadzor ergab jedoch, dass beide Adressen (weder Domainname noch IP) dort nicht aufgeführt sind:
Auf Ihrer Anfrage konnte nichts gefunden werden
Abgesehen von den Besonderheiten der Internet-Zensur in Russland gibt es nur eine gültige Rechtfertigung für einen ISP, eine Ressource zu blockieren - den sogenannten „Registrierungs-Dump“, der die dort mehr oder weniger legal platzierte Ressource enthält. Manchmal werden Ressourcen ohne einen relevanten Registrierungseintrag blockiert (sie werden umgangssprachlich als "registrierungsloses Blockieren" bezeichnet), und normalerweise hat die Rechtfertigung für diese in keinem Rechtsfall eine Chance.
Zu diesem Zeitpunkt vermuteten wir ein einfaches technisches Missverständnis oder ein verpfuschtes Entsperren einer anderen nicht verwandten Site. Ja, wir schlagen keinen Alarm, ohne vorher alles sorgfältig zu überprüfen.
Wir haben eine E-Mail mit unseren Ergebnissen an den technischen Support von MGTS gesendet und um Klärung gebeten. Etwas später erhielten wir eine Nichtantwort: "Wir sind es nicht, es ist MTS, frag sie." Natürlich haben wir das nicht getan, sondern MGTS gezwungen, ihre Arbeit zu erledigen und sie ordnungsgemäß zu untersuchen. Die Antwort war sehr interessant: Laut einem MTS-Mitarbeiter der zuständigen Abteilung wurden sie vom FSB über ein offizielles Schreiben Nr. 12 / T / 3 / 1-94 vom 25. Februar 2019 kontaktiert und aufgefordert, dringend zu blockieren diese Gastgeber:
Zu diesem Zeitpunkt haben unsere Bullshit-Detektoren die Waage verlassen und wir haben noch tiefer gegraben. Und schneller.
Wir haben eine Anfrage an den FSB gesendet und gefragt, ob der Brief existiert und wenn ja, welche Rechtfertigung haben sie:
Wir haben MGTS gebeten, ebenfalls eine Begründung zu liefern:
Danach gingen wir zu einigen aktuellen Chatrooms in einem bestimmten illegalen Instant Messaging-Dienst in Russland. Die Telekommunikationsgemeinschaft reagierte ziemlich widerstrebend:
- „Ich hatte Erfahrung mit der Lösung dieser Probleme und niemand möchte die Tools von RKN verwenden. Erstens ist es kompliziert. Zweitens löst die Übertragung des Problems auf eine andere Abteilung das Problem nicht. "
- "Sie müssen so viel Dokumentation bereitstellen und durch so viele bürokratische Probleme springen (und es gibt eine Geldstrafe, wenn Sie das alles nicht tun), dass niemand stört."
Nun, es ist schwer, sie wirklich zu beurteilen, da diejenigen, die in der Telekommunikation arbeiten, mit so viel Mist zu tun haben (wenn man bedenkt, dass „SORM“, „Netzwerkknoten“ oder „Registrierungsspeicherauszug“ nicht nur Worte für sie sind, sondern ein täglicher Ärger). .
Trotzdem nahm der Chatroom der russischen Internet Defense Community den Fall mit Begeisterung auf und führte selbst eine ordnungsgemäße Untersuchung durch.
Sie schlugen eine interessante Idee vor - zu überprüfen, welche ISPs (in Russland und anderswo) den Zugriff auf die MX-Server über RIPE Atlas blockieren. Die Ergebnisse waren vorhersehbar, aber immer noch sehr merkwürdig: In Russland werden die Server von MTS und Rostelecom sowie von Netzwerken blockiert, die über diese beiden ISPs arbeiten ( Ergebnisse auf dem primären MX-Server und dem Backup- Server ). Bei der weltweiten Überprüfung wurden Probleme in Russland, der Ukraine und im Iran festgestellt ( weltweite Ergebnisse für den Primärserver und das Backup ).
Eine umfassendere Untersuchung ergab, dass Rostelecom auf ähnliche Weise handelt:
Nach dem Wochenende lieferte MTS endlich einen Scan des FSB-Briefes, in dem die Blöcke bestellt wurden. Natürlich beschuldigten sie „Telefonterroristen“ und banden alles an die Winterspiele der XXIX. Weltuniversität - Universiade 2019:
Dann reagierten Protomail-Vertreter auf reddit , Twitter und TechCrunch . Wie erwartet waren sie von der Stumpfheit der FSB-Methoden überrascht und boten an, bei der Suche nach echten Kriminellen zusammenzuarbeiten:
Hmm. Protomail selbst vermutete, dass dies alles eine versteckte Agenda hat. Nun, es scheint der Fall zu sein. Wie ich bereits bei avobe erklärt habe, sind MX-Datensätze ein Mechanismus für die Verarbeitung eingehender E-Mails. FSB hat die eingehende Post eindeutig absichtlich und nicht ausgehend gebrochen, so dass ihre ähm, „Rechtfertigung“, Schulleiter vor Ärger zu bewahren, sehr klar erfunden ist. Wir haben also drei Möglichkeiten:
- Sie haben einfach blockiert, was sie zuerst gefunden haben (eine faule Erklärung, aber die wahrscheinlichste laut Occam Razor: Jemand muss gerade „nslookup for dummies“ gelesen haben);
- Sie haben versucht, die Möglichkeit einzuschränken, anonyme und nicht nachverfolgbare Protonenadressen einzurichten, die schädliche Informationen über sich selbst sammeln (funktioniert in den allermeisten Fällen nicht).
- Die flüchtige UFO-Erklärung.
Hier ist der Beweis: Eine von Proton an einen anderen Dienst gesendete E-Mail hat verschiedene IPs durchlaufen, die nicht blockiert sind. Denken Sie daran, FSB hat 185.70.40.101 und 185.70.40.102 verboten. Sehen Sie diese hier?
Der Leiter von ProtonMail bestätigte TechCrunch die Ergebnisse und schlug vor, die terroristischen Aktivitäten in Zusammenarbeit mit ausländischen Strafverfolgungsbehörden zu bekämpfen, anstatt das Problem einfach von Hand wegzuwinken:
Andy Yen, CEO von ProtonMail, nannte den Block in einer E-Mail an TechCrunch „besonders hinterhältig“.
"ProtonMail ist nicht auf normale Weise blockiert, sondern etwas subtiler", sagte Yen. „Sie blockieren den Zugriff auf ProtonMail-Mailserver. So können beispielsweise Mail.ru - und die meisten anderen russischen Mailserver - keine E-Mails mehr an ProtonMail senden, aber ein russischer Benutzer hat kein Problem damit, in seinen Posteingang zu gelangen “, sagte er.
"Die umfassende Sperrung von ProtonMail in einer Weise, die allen russischen Bürgern schadet, die mehr Online-Sicherheit wünschen, scheint ein schlechter Ansatz zu sein", sagte Yen. Er sagte, sein Service biete überlegene Sicherheit und Verschlüsselung für andere E-Mails, die Rivalen im Land liefern.
"Wir haben auch technische Maßnahmen ergriffen, um den kontinuierlichen Service für unsere Benutzer in Russland sicherzustellen, und wir haben in dieser Hinsicht gute Fortschritte erzielt", erklärte er. "Wenn es tatsächlich eine legitime rechtliche Beschwerde gibt, ermutigen wir die russische Regierung, ihre Position zu überdenken und Probleme zu lösen, indem sie etablierte internationale Gesetze und rechtliche Verfahren befolgen."
- ProtonMail-Geschäftsführer Andy Yen @ TechCrunch
Es sieht auch so aus, als ob dieser FSB-Brief nur zum Blockieren von SMTP-Servern für eingehende E-Mails bestellt wurde. Webzugriff und ausgehende SMTP-Server funktionieren immer noch, was bedeutet, dass der FSB, was auch immer er versuchte, nicht sehr gut darin war.
Wir werden noch einmal sagen: Selbst wenn man die gesamte rechtliche Seite der Frage der Regulierung des Internets auf dem ganz besonderen Achtel des Erdlandes außer Acht lässt, gibt es Spielregeln. Die Regeln sind nicht besonders klar, sehr vieldeutig und ändern sich ständig, aber sie sind immer noch Regeln, auch wenn sie eindeutig so konzipiert sind, dass sie den Betreuern dieser Regeln zugute kommen. Und selbst dann gibt es Leute, die versuchen, sie zu umgehen. Dies war sehr kafka-artig, ohne ein ordnungsgemäßes Verfahren. Zumindest in jedem Gerichtsverfahren können Sie einen Branchenexperten zur Beratung hinzuziehen, aber dort beruhte die Entscheidung ausschließlich auf der persönlichen Weltanschauung einer bestimmten Person.
Hier sind alle Fakten, die wir bis zu diesem Punkt gesammelt haben. Alle Anfragen wurden gesendet, aber nicht alle wurden beantwortet. Natürlich hofften wir, dass dies nur eine Folge eines verpfuschten Jobs von jemandem bei MTS war, aber um ehrlich zu sein, sah es von Anfang an nicht besonders wahrscheinlich aus.
Unsere Benutzer, die auch Protomail verwenden, können ihre Proton-Postfächer sicher weiterhin mit Habr verwenden, da wir den Datenverkehr von uns über einen anderen russischen ISP, der diese Art von Spielen nicht spielt, zum Protomail-Dienst umgeleitet haben. Und MGTS wird wahrscheinlich einen weiteren Kunden verlieren.