How Protonmail is blocked in Russia

Russian version of the post

A completely routine troubleshooter to our tech support opened another strange blocking of quite significant for the Protonmail service community that respects its Internet freedom in some networks in Russia. I would not want to exploit the "yellow header", but the story is strange and somewhat outrageous.

TL; DR

Important note: the analysis continues and while everything is in the process. Maybe "boy and not", but most likely there. It will be supplemented as new information appears.

The largest Russian telecom operators MTS and Rostelecom block traffic to the SMTP server of the Protonmail secure e-mail service out-of-place according to a letter from the FSB. Apparently, for quite a long time, but no one has paid much attention so far. And here we are.

WTF and burning continues, all participants received relevant inquiries and must provide motivated answers.

UPD: MTS provided a scan letter to the FSB, which is blocking. Motivation: Universiade and "telephone terrorism". So that letters with ProtonMail do not get to the disturbing addresses of special services and schools.

UPD: Protonmail was surprised at the methods of dealing with fraud among "these strange Russians" and advised a more effective way of fighting through abuse mailbox.

UPD: The gallant concept of fighting the FSB with false claims did not hold water: a letter broke incoming mail to ProtonMail, not outgoing.

UPD: Protonmail shrugged and changed the IP addresses of their MXs, thus taking them out of the lock on this particular letter. The question of what will be further open.

UPD: Apparently, such a letter is not one, and there is another set of IP addresses of VOIP services that are blocked out of place.

UPD: Since the story began to spread beyond the Runet, we prepared a translation into English, the link above.

We love our users for being technically savvy. Technically savvy users know what “computer hygiene” is. Some of our users have decided to use the Protonmail “secure email” service . Let us leave aside the discussion of the service itself, their product and business model, we will discuss only significant technical issues.

We send a lot of e-mail to our users every day, and since we worry about our independence and their privacy, we don’t use third-party email (ESP) services to send most types of messages. To do this, we use our power, starting from bare-metal servers and MX-servers controlled by us, ending with encryption of connections and ownership of our independent IP addresses.

Last week, we received quite a lot of calls from Protonmail users that our emails didn’t reach us.

Of course, the basic answer of our technical support was the suggestion to look in spam and other typical solutions for typical problems, but the volume of requests prompted to sort out the question in more detail. And then wrap it all ...

A brief description of how email works

For most modern Internet users, using e-mail consists of a browser entering the “personal box” on the website of the email service provider, composing and sending a letter to the recipient through the same web interface. With the help of some magic in an instant, the letter appears in the web interface of the recipient's email service.

So: the magic is called SMTP (esmtp, to be more precise). The server of the sender selects the domain part (after @) from the address of the recipient's box and makes a DNS request to get the list of MX servers of the recipient domain. It looks like this for the address support@habr.team:

MX server, literally "mail exchange server" (mail exchange). It indicates which email service the recipient's domain email is on. To be more precise, through which servers the email hosting of the recipient's domain receives mail. That is, the example above shows that the mail servers for our domain habr.team are located on Google servers (g. Suite).

After establishing the list of recipient's MX servers, the esmtp (s) protocol is accessed to the server with the lowest priority to send mail to the user. More than one, the number of servers in the list is done to ensure fault tolerance, since connectivity on the Internet is often a conditional phenomenon.

The transfer of the letter looks something like this:

Important note: mail from a specific domain is not at all required to leave recipients from the MX servers specified in the DNS, this mechanism is used only for incoming mail. Outgoing mail from the domain can be transmitted through other servers, an approximate list of which is specified, as a rule, in another SPF record.

We began to rake out the mail logs and found that the connections of our servers to Protonmail MX servers (185.70.40.101, 185.70.40.102) end with network timeouts. It looked strange for a number of reasons and was similar to the use of the locking mechanism practiced in Russia.

I, of course, wildly apologize, but here is another spoiler: briefly about how the Internet, autonomous systems and global routing work

In general, the term “Internet” translates literally roughly as “Between the Network”, it can be translated as “Network of networks” and “Association of networks”, as who likes more. In fact, the Internet does not have a “technical center” (unlike the “organizational center”), this is the union of various networks that are equal to each other, although there are networks that are “more equal” than others, but this is another story. Networks are called “Autonomous Systems” (AS) and are interconnected by joints (feasts). Each autonomous system has a unique number by which it is identified by another autonomous system on the Internet. It looks like IP-addresses, but more "large strokes." Each network receives from the neighboring data about the topology of its connections with its neighbors, the connection of its neighbors with their neighbors, and so on. That is, a map of the connections of autonomous systems with each other in terms of this interface. The path on this map from one autonomous system to another is called the AS path.

For example, we have the autonomous system number (ASN) 204671 , Protonmail servers are located in the network of one of the largest American network corporation Neustar, which has ASN 19905 . We have two interfaces with various Internet service providers, that is, two possible AS paths from us to the Neustar network. For a number of reasons, the interface with one of the MGTS operators is our priority, therefore the AS-path is: 204671 (We) - 57681 (MGTS) - 8359 (MTS) - 22822 (Limelight) - 19905 (Neustar)

The map looks like this:

Traceroute to any of the two Protonmail MX servers ended up on the MTS network and looked like this:

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 .