Un boleto de soporte técnico completamente rutinario ha descubierto prohibiciones inesperadas de direcciones IP de Protonmail, un servicio muy útil para las personas que valoran sus libertades en Internet, en varias regiones de Rusia. En serio, no quería sensacionalizar el titular, pero la historia es tan extraña e inexplicable que no pude resistirme.
TL; DR
Descargo de responsabilidad: la situación aún se está desarrollando. Puede que no haya nada malicioso, pero lo más probable es que lo haya. Actualizaré la publicación una vez que llegue nueva información.
MTS y Rostelecom, dos de los ISP rusos más grandes, comenzaron a bloquear el tráfico a los servidores SMTP del servicio de correo electrónico encriptado Protonmail de acuerdo con una solicitud del FSB, sin tener en cuenta el registro oficial del gobierno de sitios web restringidos. Parece que ha estado sucediendo por un tiempo, pero nadie le prestó especial atención. Hasta ahora
Todas las partes involucradas han recibido solicitudes relevantes de información que están obligadas a responder.
UPD: MTS ha proporcionado un escaneo de la carta FSB, que es la base para restringir el acceso. Justificación: la Universiada en curso en Krasnoyarsk y el "terrorismo telefónico". Se supone que evita que los correos electrónicos de ProtonMail vayan a direcciones de emergencia de servicios de seguridad y escuelas.
UPD: Protonmail estaba sorprendido por "estos extraños rusos" y sus métodos para combatir el abuso de fraude, y también sugirió una forma más efectiva de hacerlo: a través del buzón de abuso .
UPD: la justificación de FSB no parece ser cierta: las prohibiciones rompieron el correo entrante de ProtonMail, en lugar de saliente.
UPD: Protonmail se encogió de hombros y cambió las direcciones IP de sus MX, sacándolos del bloqueo después de esa carta particular de FSB. Lo que sucederá después es una pregunta abierta.
UPD: Aparentemente, dicha carta no fue la única y todavía hay un conjunto de direcciones IP de servicios VOIP que están bloqueadas sin los registros apropiados en el registro oficial de sitios web restringidos.
Amamos a nuestros usuarios de Habr porque son muy conocedores de la tecnología. Entienden lo que significa "higiene informática". Algunos de nuestros usuarios han estado utilizando Protonmail , un servicio de "correo electrónico cifrado". Discutiremos solo el asunto tecnológico hoy, dejando a un lado la discusión del servicio en sí y su modelo de negocio.
Todos los días enviamos muchos correos electrónicos a nuestros usuarios, y dado que nos preocupamos por nuestra independencia y su privacidad, no utilizamos servicios de correo externo (ESP). En su lugar, usamos nuestros propios recursos, desde servidores básicos y servidores MX autosuficientes hasta encriptar conexiones y poseer nuestras direcciones IP independientes.
La semana pasada, nuestro equipo de soporte fue sobrecargado por mensajes de usuarios de Protonmail, quejándose de que nuestro correo no llega a ellos:
Hola Desde la primera semana de marzo de 2019, cuando intento iniciar sesión, recibo una pancarta roja que dice que no podían enviar un correo electrónico a mi dirección. Traté de enviar un mensaje de prueba manualmente, sin resultado. El buzón en sí, alojado por Protomail, es perfectamente funcional (otros correos electrónicos funcionan bien). El último resumen de Habr es del 28 de febrero.
No cambié ninguna de las configuraciones ni allí ni en Protomail, pero cuando surgió el problema por primera vez, cerré la sesión de la aplicación de Android.
No creo que la cuenta haya sido comprometida, pero no pude encontrar la lista de direcciones IP utilizadas para acceder a ella, así que no puedo estar seguro. Espero su ayuda, ya que sin un correo electrónico que funcione no puedo votar comentarios / publicaciones.
Cambió la dirección de correo electrónico de Gmail a Protomail. El correo electrónico de confirmación no llega a la nueva dirección.
Por supuesto, nuestro soporte técnico sugirió cosas simples como verificar carpetas de spam, pero el gran volumen de quejas similares nos obligó a profundizar.
Brevemente sobre cómo funciona el correo electrónicoPara la mayoría de los usuarios modernos de Internet, usar el correo electrónico significa iniciar sesión en la "Bandeja de entrada personal" en el sitio web del proveedor de servicios de correo electrónico y luego enviar cartas a través de la misma interfaz web. Luego ocurre algo de magia y un par de momentos después la carta llega a la interfaz web en el extremo receptor.
Esta "magia" se llama SMTP (o esmtp, para ser precisos). El servidor emisor extrae la parte del dominio (después de la @) de la dirección de recepción y realiza una solicitud de DNS para los servidores MX del dominio del receptor. Para support@habr.team, se ve así:
MX significa "intercambio de correo". Indica el servicio de correo electrónico utilizado por el receptor o, para ser precisos, qué servidores de correo electrónico el alojamiento del dominio receptor recoge el correo nuevo. El ejemplo anterior muestra que nuestro dominio, habr.team, está alojado por Google (G.Suite).
Después de encontrar los servidores MX, se realiza una solicitud a través del protocolo esmtp al servidor con la más alta prioridad, para entregar el correo al usuario. Se enumeran varios servidores para la redundancia, ya que "interconectividad" de Internet es un término muy relativo.
Así es como se ve el envío de una carta:
NB: el correo de un determinado dominio no necesariamente tiene que enviarse a los usuarios en los servidores MX enumerados en el DNS; esto solo se usa para el correo entrante. El correo saliente se puede reenviar a través de otros servidores, generalmente listados en un registro SPF.
Revisamos nuestros registros de correo y descubrimos que los intentos de conexión desde nuestros servidores a los servidores MX de Protomail (185.70.40.101, 185.70.40.102) siempre se agotaban. Esto parecía extraño por varias razones y se parecía al mecanismo de censura de Internet en Rusia.
Lo siento mucho, pero tengo que desviarme y decirte cómo funcionan Internet, los sistemas autónomos y el enrutamientoEn general, el término "Internet" se compone de dos palabras: "Inter-Net", y puede interpretarse como "red de redes" o "redes unidas". Internet no tiene un "centro técnico" (aunque sí tiene un "centro organizador"): simplemente conecta diferentes redes que son, en teoría, iguales entre sí (aunque algunas redes son más iguales que otras, pero eso es Una historia para otro día). Las redes se denominan "sistemas autónomos" (AS) y están conectadas entre sí a través de puertas o "pares". Cada AS tiene un número único utilizado para identificarlo por otros AS. Al igual que las direcciones IP, pero de una manera más general. Cada red recibe de sus "vecinos" la topología de sus conexiones a redes cercanas, cómo estas redes cercanas se conectan a sus redes cercanas, etc. Esencialmente, cada red tiene un mapa de cómo todos los AS se conectan entre sí desde la perspectiva de esa red. Una ruta de un AS a otro de acuerdo con ese mapa simplemente se llama "ruta AS".
Por ejemplo, nuestro número de sistema autónomo (ASN) es 204671, los servidores de Protonmail están alojados en la red de una gran corporación estadounidense Neustar, y su ASN es 19905. Tenemos dos puertas con ISP, lo que significa dos posibles rutas AS desde nosotros hacia Neustar red Por varias razones, una de las puertas (a través de MGTS) es preferible, por lo que nuestra ruta AS se ve así: 204671 (us) - 57681 (MGTS, el ISP), 8359 (MTS, el ISP más grande) - 22822 (Limelight ) - 19905 (Neustar).
Y aquí está la tabla de enrutamiento:
Cada traceroute a cualquiera de los dos servidores MX de Protonmail se cortó en la red MTS y se veía así:
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 *
Encontramos un host alternativo dentro de la red Neustar y lo usamos como referencia para eliminar posibles interrupciones entre MTS y 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
Mientras tanto, completamos con éxito otro rastreo a través de otro ISP a los servidores MX de Protonmail (se corta en Neustar, pero eso es de esperar; la conexión aún funciona):
$ 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
Dado que traceroute no es una herramienta muy confiable, realizamos otro par de experimentos, por ejemplo, con el servicio Looking Glass de MTS:
Quedó claro que probablemente es una restricción intencional del servicio a nivel MTS. Sin embargo, consultar con el registro oficial de Roskomnadzor reveló que ambas direcciones (ni el nombre de dominio ni la IP) no se enumeran allí:
No se puede encontrar nada en su solicitud
Dejando a un lado los detalles de la censura de Internet en Rusia, solo hay una justificación válida para que un ISP bloquee un recurso: el llamado "volcado del registro" que contiene el recurso puesto allí más o menos legalmente. A veces, los recursos se bloquean sin una entrada de registro relevante (se denominan coloquialmente "bloqueo sin registro") y, por lo general, la justificación de estos no tiene ninguna posibilidad en ningún caso legal.
En este punto, sospechábamos un simple malentendido técnico o un desbloqueo fallido de otro sitio no relacionado. Sí, no hacemos sonar las alarmas sin verificar minuciosamente todo primero.
Enviamos un correo electrónico detallando nuestros hallazgos al soporte técnico de MGTS y solicitamos una aclaración. Un poco más tarde recibimos una no respuesta: "no somos nosotros, es MTS, pregúntales". Por supuesto, no lo hicimos, sino que forzamos a MGTS a hacer su trabajo e investigarlo adecuadamente. La respuesta que obtuvimos fue muy interesante: según un empleado de MTS del departamento correspondiente, el FSB los contactó mediante una carta oficial No. 12 / T / 3 / 1-94 del 25 de febrero de 2019, exigiéndoles que bloqueen urgentemente estos anfitriones:
En este punto, nuestros detectores de mierda se han salido de la escala y hemos cavado aún más profundo. Y mas rapido.
Enviamos una solicitud al FSB preguntando si la carta existe y si es así, qué justificación tienen:
Le pedimos a MGTS que también proporcionara una justificación:
Después de eso, fuimos a algunas salas de chat de actualidad en un servicio de mensajería instantánea ilegal en Rusia. La comunidad de telecomunicaciones reaccionó de mala gana:
- “Tenía experiencia resolviendo estos problemas y nadie quiere usar las herramientas de RKN. Primero, es complicado. Segundo, transferir el problema a otro departamento no resuelve el problema ".
- "Debe proporcionar tanta documentación y pasar por tantos aros burocráticos (y hay un castigo monetario por no hacer todo eso) que nadie se molesta".
Bueno, es difícil juzgarlos realmente, ya que aquellos que trabajan en telecomunicaciones tienen que lidiar con tanta basura (teniendo en cuenta que "SORM", "nodo de red" o "volcado de registro" no son solo palabras para ellos, sino una molestia diaria) .
Sin embargo, la sala de chat de la Comunidad Rusa de Defensa de Internet tomó el caso con entusiasmo y realizó una investigación propia.
Sugirieron una idea interesante: verificar qué ISP (en Rusia y otros) bloquean el acceso a los servidores MX a través de RIPE Atlas . Los resultados fueron predecibles, pero aún muy curiosos: en Rusia, los servidores están bloqueados por MTS y Rostelecom, así como las redes que trabajan a través de estos dos ISP ( resultados en el servidor MX primario y el de respaldo ). La verificación mundial detectó problemas en Rusia, Ucrania e Irán ( resultados mundiales para el servidor primario y la copia de seguridad ).
Una investigación más complicada mostró que Rostelecom actúa de manera similar:
Después del fin de semana, MTS finalmente proporcionó un escaneo de la carta del FSB que ordenó los bloques. Por supuesto, culparon a los "terroristas telefónicos" y lo vincularon con los XXIX Juegos de Invierno de la Universidad Mundial - Universiada 2019:
Luego, los representantes de Protomail reaccionaron en reddit , Twitter y TechCrunch . Como se esperaba, se sorprendieron por la brusquedad de los métodos de FSB y se ofrecieron a cooperar para encontrar criminales reales:
Hmm Protomail sospecharon que hay una agenda oculta para todo esto. Bueno, parece ser el caso. Entonces, como ya he explicado avobe, los registros MX son un mecanismo para manejar correos electrónicos entrantes. El FSB claramente rompió deliberadamente el correo entrante en lugar del saliente, por lo que su "justificación" de salvar a los directores de las escuelas de los problemas está muy claramente fabricada. Entonces, tenemos tres opciones:
- Simplemente bloquearon lo que encontraron por primera vez (una explicación perezosa, pero la más probable de acuerdo con la Navaja de Occam: alguien debe haber leído "nslookup for dummies");
- Intentaron limitar la posibilidad de configurar direcciones de protones anónimas y no rastreables que recopilan información dañina sobre sí mismos (no funciona en la gran mayoría de los casos)
- La explicación superficial del ovni.
Aquí está la prueba: un correo electrónico enviado desde Proton a otro servicio pasó por diferentes IP que no están bloqueadas. Recuerde, FSB prohibió 185.70.40.101 y 185.70.40.102. ¿Ves esto aquí?
El jefe de ProtonMail confirmó los hallazgos a TechCrunch y sugirió luchar contra la actividad terrorista en cooperación con la policía extranjera, en lugar de simplemente descartar el problema:
El director ejecutivo de ProtonMail, Andy Yen, calificó el bloqueo de "particularmente astuto" en un correo electrónico a TechCrunch.
"ProtonMail no está bloqueado de la manera normal, en realidad es un poco más sutil", dijo Yen. “Están bloqueando el acceso a los servidores de correo de ProtonMail. Entonces, Mail.ru, y la mayoría de los otros servidores de correo rusos, por ejemplo, ya no pueden enviar correos electrónicos a ProtonMail, pero un usuario ruso no tiene problemas para llegar a su bandeja de entrada ”, dijo.
"El bloqueo total de ProtonMail de una manera que perjudica a todos los ciudadanos rusos que desean una mayor seguridad en línea parece un enfoque pobre", dijo Yen. Dijo que su servicio ofrece seguridad superior y encriptación a otros correos que proporcionan rivales en el país.
"También hemos implementado medidas técnicas para garantizar un servicio continuo para nuestros usuarios en Rusia y hemos avanzado mucho en este sentido", explicó. "Si efectivamente existe una queja legal legítima, alentamos al gobierno ruso a que reconsidere su posición y resuelva los problemas siguiendo el derecho internacional establecido y los procedimientos legales".
- Andy Yen, director ejecutivo de ProtonMail @ TechCrunch
Además, parece que esta carta FSB solo ordenó bloquear servidores SMTP para el correo entrante. El acceso web y los servidores SMTP salientes aún funcionan, lo que significa que, independientemente de lo que el FSB haya intentado hacer, no fueron muy buenos en eso.
Diremos nuevamente: incluso sin tener en cuenta todo el aspecto legal del problema de la regulación de Internet en el 1/8 de la tierra terrestre, hay reglas del juego. Las reglas no son terriblemente claras, muy ambiguas y cambian todo el tiempo, pero siguen siendo reglas, incluso si están claramente diseñadas para beneficiar a los mantenedores de estas reglas. E incluso entonces, hay personas que intentan evitarlos. Esto fue muy Kafka-esque, sin el debido proceso en absoluto. Al menos en cualquier caso judicial puede recurrir a un experto de la industria para su consulta, pero allí la decisión se basó exclusivamente en la visión personal del mundo de una persona en particular.
Entonces, aquí están todos los hechos que hemos reunido hasta este punto. Todas las solicitudes han sido enviadas, pero no todas han sido respondidas. Por supuesto, esperábamos que fuera solo una consecuencia del trabajo fallido de alguien en MTS, pero, para ser honesto, no parecía terriblemente probable desde el principio.
En cuanto a nuestros usuarios que también usan Protomail, pueden continuar usando sus buzones de Proton con seguridad con Habr, ya que redirigimos el tráfico de nosotros al servicio de Protomail a través de otro ISP ruso que no juega este tipo de juegos. Y MGTS probablemente esté a punto de perder otro cliente.