Um tíquete de suporte técnico completamente rotineiro descobriu proibições inesperadas de endereços IP do Protonmail - um serviço muito útil para pessoas que valorizam suas liberdades na Internet - em várias regiões da Rússia. Eu realmente não queria sensacionalizar a manchete, mas a história é tão estranha e inexplicável que não pude resistir.
TL; DR
Disclaimer: a situação ainda está se desenvolvendo. Pode não haver nada malicioso, mas provavelmente existe. Atualizarei a postagem assim que novas informações surgirem.
O MTS e o Rostelecom - dois dos maiores ISPs da Rússia - começaram a bloquear o tráfego para servidores SMTP do serviço de e-mail criptografado Protonmail, de acordo com uma solicitação do FSB, sem levar em consideração o registro oficial do governo de sites restritos. Parece que isso vem acontecendo há um tempo, mas ninguém prestou atenção especial a isso. Até agora.
Todas as partes envolvidas receberam solicitações de informações relevantes às quais são obrigadas a responder.
UPD: O MTS forneceu uma digitalização da carta FSB, que é a base para restringir o acesso. Justificação: a Universiade em curso em Krasnoyarsk e o "terrorismo telefónico". Ele deve impedir que os emails do ProtonMail cheguem a endereços de emergência de serviços de segurança e escolas.
UPD: O Protonmail ficou surpreso com “esses estranhos russos” e seus métodos para combater o abuso de fraude, além de sugerir uma maneira mais eficaz de fazê-lo - via caixa de correio de abuso .
UPD: A justificativa do FSB não parece ser verdadeira: as proibições interromperam as mensagens de entrada do ProtonMail, em vez de as de saída.
UPD: O Protonmail encolheu os ombros e alterou os endereços IP de seus MXs, retirando-os do bloqueio após aquela carta específica do FSB. O que acontecerá a seguir é uma questão em aberto.
UPD: Aparentemente, essa carta não foi a única e ainda existe um conjunto de endereços IP de serviços VOIP bloqueados sem registros apropriados no registro oficial de sites restritos.
Adoramos nossos usuários Habr porque eles são muito entendidos em tecnologia. Eles entendem o que significa "higiene do computador". Alguns de nossos usuários usam o Protonmail - um serviço de "email criptografado". Hoje discutiremos apenas a questão tecnológica, deixando de lado a discussão sobre o serviço em si e seu modelo de negócios.
Todos os dias enviamos muitos e-mails para nossos usuários e, como nos preocupamos com nossa independência e sua privacidade, não usamos serviços de correio externos (ESPs). Em vez disso, usamos nossos próprios recursos, desde servidores bare-metal e servidores MX de manutenção automática até conexões criptografadas e proprietários de nossos endereços IP independentes.
Na semana passada, nossa equipe de suporte foi sobrecarregada por mensagens dos usuários do Protonmail, reclamando que nossos emails não chegam até eles:
Olá Desde a primeira semana de março de 2019, quando tento fazer login, recebo uma faixa vermelha dizendo que eles não podiam enviar um e-mail para o meu endereço. Tentei enviar uma mensagem de teste manualmente, sem sucesso.A caixa de correio em si, hospedada pelo Protomail, é perfeitamente funcional (outros emails são enviados corretamente). O último resumo de Habr é de 28 de fevereiro.
Não alterei nenhuma das configurações nem no Protomail, nem na Protomail, mas quando o problema surgiu, eu estava desconectado do aplicativo Android.
Não acho que a conta tenha sido comprometida, mas não consegui encontrar a lista de IPs usados para acessá-la, por isso não tenho certeza. Espero sua ajuda, pois, sem um email de trabalho, não posso votar em comentários / postagens.
O endereço de e-mail foi alterado do Gmail para o Protomail. O email de confirmação não chega ao novo endereço.
Obviamente, nosso suporte técnico sugeriu coisas simples, como verificar pastas de spam, mas o grande volume de reclamações semelhantes nos forçou a aprofundar.
Brevemente sobre como o email funcionaPara a maioria dos usuários modernos da Internet, usar email significa fazer login na "Caixa de entrada pessoal" no site do provedor de serviços de email e enviar cartas pela mesma interface da web. Então, um pouco de mágica acontece e, alguns momentos depois, a carta chega à interface da Web no lado receptor.
Essa "mágica" é chamada SMTP (ou esmtp, para ser mais preciso). O servidor de envio extrai a parte do domínio (após o @) do endereço de recebimento e faz uma solicitação de DNS para servidores MX do domínio do destinatário. Para support@habr.team, é assim:
MX significa "troca de correio". Indica o serviço de email usado pelo destinatário ou, para ser mais preciso, quais servidores de email a hospedagem do domínio de recebimento coleta novos emails. O exemplo acima mostra que nosso domínio, habr.team, é hospedado pelo Google (G.Suite).
Após localizar os servidores MX, é feita uma solicitação por meio do protocolo esmtp ao servidor com a mais alta prioridade, para entregar o correio ao usuário. Vários servidores são listados para redundância, pois "interconectividade" da Internet é um termo muito relativo.
É assim que o envio de uma carta se parece:
Nota: o correio de um determinado domínio não precisa necessariamente ser enviado aos usuários nos servidores MX listados no DNS; isso é usado apenas para mensagens recebidas. Os emails de saída podem ser encaminhados por outros servidores, geralmente listados em um registro SPF.
Examinamos nossos logs de correio e descobrimos que as tentativas de conexão de nossos servidores com os servidores MX da Protomail (185.70.40.101, 185.70.40.102) sempre atingiam o tempo limite. Isso parecia estranho por vários motivos e se assemelhava ao mecanismo de censura da Internet na Rússia.
Sinto muito, mas tenho que discordar e dizer como a Internet, sistemas autônomos e roteamento funcionamEm geral, o termo “Internet” é composto de duas palavras: “Inter-Net” e pode ser interpretado como “rede de redes” ou “redes unidas”. A Internet não possui um "centro técnico" (embora tenha um "centro organizador"): simplesmente conecta redes diferentes que são, em teoria, iguais umas às outras (embora algumas redes sejam mais iguais que outras, mas é isso uma história para outro dia). As redes são chamadas de "sistemas autônomos" (AS) e são conectadas entre si por portas ou "pares". Cada AS possui um número único usado para identificá-lo por outros ASes. Como endereços IP, mas de uma maneira mais geral. Cada rede recebe de seus “vizinhos” a topologia de suas conexões com redes próximas, como essas redes próximas se conectam às redes próximas etc. Basicamente, cada rede tem um mapa de como todos os AS se conectam da perspectiva dessa rede. Uma rota de um AS para outro de acordo com esse mapa é simplesmente chamada de “caminho AS”.
Por exemplo, nosso número de sistema autônomo (ASN) é 204671, servidores Protonmail estão hospedados na rede de uma grande corporação americana Neustar e seu ASN é 19905. Temos dois portões com ISPs, o que significa dois caminhos AS possíveis para o Neustar rede. Por várias razões, um dos portões (através do MGTS) é preferível, portanto nosso caminho AS se parece com: 204671 (us) - 57681 (MGTS, ISP), 8359 (MTS, ISP maior) - 22822 (Limelight ) - 19905 (Neustar).
E aqui está a tabela de roteamento:
Cada traceroute para qualquer um dos dois servidores MX do Protonmail cortados na rede MTS e fica assim:
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 um host alternativo na rede Neustar e o usamos como referência para eliminar possíveis interrupções entre o MTS e o 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
Enquanto isso, concluímos com êxito outro rastreamento através de outro ISP para os servidores MX do Protonmail (ele é interrompido no Neustar, mas isso é esperado - a conexão ainda 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
Como o traceroute não é uma ferramenta muito confiável, realizamos mais algumas experiências, por exemplo, com o serviço Looking Glass da MTS:
Ficou claro que provavelmente é uma restrição intencional de serviço no nível do MTS. No entanto, a consulta ao registro oficial de Roskomnadzor revelou que os dois endereços (nem nome de domínio sem IP) não estão listados lá:
Não foi possível encontrar nada em sua solicitação
Deixando de lado as especificidades da censura na Internet na Rússia, há apenas uma justificativa válida para um provedor de serviços de Internet bloquear um recurso - o chamado “despejo de registro” que contém o recurso colocado lá de forma mais ou menos legal. Às vezes, os recursos são bloqueados sem uma entrada de registro relevante (eles são chamados coloquialmente de "bloqueio sem registro") e, geralmente, a justificativa para isso não tem chance em nenhum caso legal.
Nesse ponto, suspeitávamos de um simples mal-entendido técnico ou um desbloqueio mal feito de outro site não relacionado. Sim, não soamos os alarmes sem verificar meticulosamente tudo primeiro.
Enviamos um e-mail detalhando nossas descobertas ao suporte técnico do MGTS e solicitamos esclarecimentos. Um pouco mais tarde, recebemos uma não resposta: "não somos nós, somos o MTS, pergunte a eles". É claro que não, mas forçamos o MGTS a fazer seu trabalho e investigá-lo adequadamente. A resposta que obtivemos foi muito interessante: de acordo com um funcionário da MTS do departamento relevante, eles foram contatados pelo FSB por meio de uma carta oficial nº 12 / T / 3 / 1-94 de 25 de fevereiro de 2019, exigindo que eles bloqueiem urgentemente estes hosts:
Nesse ponto, nossos detectores de besteira caíram da balança e cavamos ainda mais fundo. E mais rápido.
Enviamos uma solicitação ao FSB perguntando se a carta existe e se existe, que justificativa elas têm:
Também solicitamos ao MGTS uma justificativa:
Depois disso, fomos a algumas salas de bate-papo de um determinado serviço ilegal de mensagens instantâneas na Rússia. A comunidade de telecomunicações reagiu com muita relutância:
- “Tive experiência em solucionar esses problemas e ninguém quer usar as ferramentas da RKN. Primeiro, é complicado. Segundo, transferir o problema para outro departamento não resolve o problema ".
- "Você precisa fornecer tanta documentação e passar por tantos obstáculos burocráticos (e há punição monetária por não fazer tudo isso) que ninguém se incomoda."
Bem, é difícil realmente julgá-los, visto que aqueles que trabalham com telecomunicações precisam lidar com tanta porcaria (considerando "SORM", "nó de rede" ou "despejo de registro" não são apenas palavras para eles, mas um aborrecimento diário) .
No entanto, a sala de bate-papo da Comunidade Russa de Defesa da Internet levou o caso com entusiasmo e conduziu uma investigação própria.
Eles sugeriram uma idéia interessante - verificar o que os ISPs (na Rússia e outros) bloqueiam o acesso aos servidores MX através do RIPE Atlas . Os resultados foram previsíveis, mas ainda muito curiosos: na Rússia, os servidores são bloqueados pelo MTS e pelo Rostelecom, bem como pelas redes que trabalham nesses dois ISPs ( resultados no servidor MX principal e no servidor de backup ). A verificação mundial detectou problemas na Rússia, Ucrânia e Irã ( resultados mundiais para o servidor principal e o backup ).
Uma pesquisa mais envolvida mostrou que a Rostelecom age de maneira semelhante:
Após o fim de semana, a MTS finalmente forneceu uma digitalização da carta do FSB que ordenou os blocos. É claro que eles culparam "terroristas por telefone" e amarraram tudo aos XXIX Jogos Mundiais da Universidade Mundial - Universiade 2019:
Os representantes da Protomail reagiram ao reddit , Twitter e TechCrunch . Como esperado, eles ficaram surpresos com a franqueza dos métodos da FSB e se ofereceram para cooperar para encontrar criminosos reais:
Hmm. A própria Protomail suspeita que haja uma agenda oculta para tudo isso. Bem, parece ser o caso. Portanto, como já expliquei a avobe, os registros MX são um mecanismo para lidar com os e-mails recebidos. O FSB claramente deliberadamente interrompeu o correio recebido em vez de enviar, de modo que sua, ahem, "justificativa" de salvar os diretores das escolas de problemas é claramente fabricada. Então, temos três opções:
- Eles simplesmente bloquearam o que encontraram pela primeira vez (uma explicação preguiçosa, mas a mais provável de acordo com o Occam Razor: alguém deve ter acabado de ler “nslookup for dummies”);
- Eles tentaram limitar a possibilidade de configurar endereços Proton anônimos e não rastreáveis, coletando informações prejudiciais sobre eles mesmos (não funciona na grande maioria dos casos)
- A explicação superficial do UFO.
Aqui está a prova: um email enviado do Proton para outro serviço passou por diferentes IPs que não são bloqueados. Lembre-se, o FSB baniu 185.70.40.101 e 185.70.40.102. Você vê isso aqui?
O chefe do ProtonMail confirmou as descobertas ao TechCrunch e sugeriu combater a atividade terrorista em cooperação com a aplicação da lei estrangeira, em vez de apenas desviar a questão:
Andy Yen, executivo-chefe da ProtonMail, chamou o bloco de "particularmente furtivo", em um email para o TechCrunch.
"O ProtonMail não é bloqueado da maneira normal, na verdade é um pouco mais sutil", disse Yen. “Eles estão bloqueando o acesso aos servidores de correio ProtonMail. Portanto, o Mail.ru - e a maioria dos outros servidores de correio russos - por exemplo, não pode mais enviar e-mails ao ProtonMail, mas um usuário russo não tem problemas para acessar sua caixa de entrada ”, disse ele.
"O bloqueio por atacado do ProtonMail de uma maneira que prejudica todos os cidadãos russos que desejam maior segurança online parece uma abordagem ruim", disse Yen. Ele disse que seu serviço oferece segurança e criptografia superiores a outros e-mails que fornecem rivais no país.
"Também implementamos medidas técnicas para garantir um serviço contínuo para nossos usuários na Rússia e temos feito bons progressos nesse sentido", explicou. "Se realmente houver uma queixa legal legítima, encorajamos o governo russo a reconsiderar sua posição e resolver problemas, seguindo a lei internacional estabelecida e os procedimentos legais".
- Andy Yen, CEO da ProtonMail, @ TechCrunch
Além disso, parece que esta carta do FSB foi solicitada apenas para bloquear servidores SMTP para mensagens recebidas. O acesso à Web e os servidores SMTP de saída ainda funcionam, o que significa que, o que quer que o FSB tentasse fazer, eles não eram muito bons nisso.
Diremos novamente: mesmo desconsiderando todo o lado legal da questão da regulamentação da Internet em 1/8 da terra da Terra, existem regras do jogo. As regras não são muito claras, são muito ambíguas e mudam o tempo todo, mas ainda são regras, mesmo que sejam claramente projetadas para beneficiar os mantenedores dessas regras. E mesmo assim, há pessoas tentando ignorá-las. Isso foi muito kafka-esque, sem o devido processo. Pelo menos em qualquer caso judicial, você pode consultar um especialista do setor para consulta, mas a decisão foi puramente baseada na visão de mundo pessoal de uma pessoa em particular.
Então, aqui estão todos os fatos que reunimos até esse ponto. Todas as solicitações foram enviadas, mas nem todas foram respondidas. Obviamente, esperávamos que fosse apenas uma conseqüência de um trabalho mal feito por alguém da MTS, mas, para ser sincero, não parecia muito provável desde o início.
Quanto aos usuários que também usam o Protomail, eles podem continuar usando suas caixas de correio do Proton com Habr, pois redirecionamos o tráfego para o serviço Protomail por outro ISP russo que não joga esse tipo de jogo. E o MGTS provavelmente está prestes a perder outro cliente.