Bagaimana Protonmail disensor oleh FSB di Rusia

Tiket dukungan teknis yang sepenuhnya rutin telah menemukan larangan alamat IP Protonmail yang tak terduga - layanan yang sangat berguna bagi orang-orang yang menghargai kebebasan Internet mereka - di beberapa wilayah Rusia. Aku benar-benar tidak ingin membuat berita utama menjadi sensasional, tetapi ceritanya sangat aneh dan tidak bisa dijelaskan sehingga aku tidak bisa menolak.


TL; DR


Penafian: situasi masih berkembang. Mungkin tidak ada sesuatu yang berbahaya, tetapi kemungkinan besar ada. Saya akan memperbarui posting setelah informasi baru masuk.


MTS dan Rostelecom - dua dari ISP Rusia terbesar - mulai memblokir lalu lintas ke server SMTP dari layanan email terenkripsi Protonmail menurut permintaan FSB, tanpa memperhatikan registrasi resmi pemerintah dari situs web terbatas. Sepertinya itu sudah terjadi untuk sementara waktu, tetapi tidak ada yang memberikan perhatian khusus padanya. Sampai sekarang.


Semua pihak yang terlibat telah menerima permintaan informasi yang relevan yang harus mereka balas.


UPD: MTS telah menyediakan pemindaian surat FSB, yang merupakan dasar untuk membatasi akses. Pembenaran: Universiade yang sedang berlangsung di Krasnoyarsk dan "terorisme telepon". Ini seharusnya mencegah email ProtonMail pergi ke alamat darurat layanan keamanan dan sekolah.


UPD: Protonmail terkejut oleh "orang-orang Rusia yang aneh ini" dan metode mereka untuk memerangi penyalahgunaan penipuan, serta menyarankan cara yang lebih efektif untuk melakukannya - melalui kotak surat penyalahgunaan .


UPD: Pembenaran FSB tampaknya tidak benar: larangan melanggar surat masuk ProtonMail, bukan keluar.


UPD: Protonmail mengangkat bahu dan mengubah alamat IP dari MX mereka mengeluarkan mereka dari pemblokiran setelah surat FSB tertentu. Apa yang akan terjadi selanjutnya adalah pertanyaan terbuka.


UPD: Rupanya, surat semacam itu bukan satu-satunya dan masih ada satu set alamat IP dari layanan VOIP yang diblokir tanpa catatan yang sesuai dalam daftar resmi situs web terbatas.


Kami menyukai pengguna Habr kami karena mereka sangat mengerti teknologi. Mereka mengerti apa artinya "kebersihan komputer". Beberapa pengguna kami telah menggunakan Protonmail - layanan "email terenkripsi". Kami hanya akan membahas masalah teknologi hari ini, meninggalkan diskusi tentang layanan itu sendiri dan model bisnisnya.


Setiap hari kami mengirimkan banyak email kepada pengguna kami, dan karena kami peduli dengan independensi dan privasi mereka, kami tidak menggunakan layanan surat eksternal (ESP). Alih-alih, kami menggunakan sumber daya kami sendiri, dari server bare-metal dan server MX yang dikelola sendiri hingga mengenkripsi koneksi dan memiliki alamat IP independen kami.


Minggu lalu tim dukungan kami dipenuhi oleh pesan dari pengguna Protonmail, mengeluh bahwa surat kami tidak sampai kepada mereka:


Halo Sejak sekitar minggu pertama Maret 2019, ketika saya mencoba masuk, saya mendapat spanduk merah yang mengatakan bahwa mereka tidak dapat mengirim email ke alamat saya. Saya mencoba mengirim pesan pengujian secara manual, tetapi tidak berhasil. Kotak surat itu sendiri, yang dihosting oleh Protomail, berfungsi dengan baik (email lain datang dengan baik). Intisari terakhir dari Habr adalah dari 28 Februari.

Saya tidak mengubah pengaturan apa pun baik di sana maupun di Protomail, tetapi sekitar saat masalah muncul pertama kali saya keluar dari aplikasi Android.

Saya tidak berpikir akun telah disusupi, tetapi saya tidak dapat menemukan daftar IP yang digunakan untuk mengaksesnya sehingga saya tidak yakin. Saya berharap bantuan Anda, karena tanpa email yang berfungsi saya tidak dapat memberikan suara pada komentar / posting

Mengubah alamat email dari Gmail ke Protomail. Email konfirmasi tidak sampai ke alamat baru.

Tentu saja, dukungan teknis kami menyarankan hal-hal sederhana seperti memeriksa folder spam, tetapi banyaknya keluhan serupa memaksa kami untuk menggali lebih dalam.


Secara singkat tentang cara kerja email

Untuk sebagian besar pengguna Internet modern menggunakan email berarti masuk ke "Kotak Masuk pribadi" pada situs web penyedia layanan email dan kemudian mengirim surat melalui antarmuka web yang sama. Kemudian beberapa keajaiban terjadi dan beberapa saat kemudian surat itu tiba ke antarmuka web di sisi penerima.


"Ajaib" ini disebut SMTP (atau esmtp, tepatnya). Server pengirim mengekstrak bagian domain (setelah @) dari alamat penerima dan membuat permintaan DNS untuk server MX dari domain penerima. Untuk support@habr.team, tampilannya seperti ini:



MX adalah singkatan dari "pertukaran email". Ini menunjukkan layanan email yang digunakan oleh penerima atau, tepatnya, server email apa yang menerima hosting domain penerima mengumpulkan email baru. Contoh di atas menunjukkan bahwa domain kami, habr.team, dihosting oleh Google (G.Suite).


Setelah menemukan server MX, permintaan dilakukan melalui protokol esmtp ke server dengan prioritas tertinggi, untuk mengirimkan email kepada pengguna. Beberapa server terdaftar untuk redundansi, karena "interkonektivitas" Internet adalah istilah yang sangat relatif.


Seperti itulah bentuk pengiriman surat:



NB: surat dari domain tertentu tidak harus dikirim ke pengguna di server MX yang tercantum dalam DNS; ini hanya digunakan untuk surat masuk. Surat keluar dapat diteruskan melalui server lain, biasanya terdaftar dalam catatan SPF.


Kami menggali log surat kami dan menemukan bahwa upaya koneksi dari server kami ke server MX Protomail (185.70.40.101, 185.70.40.102) selalu kehabisan waktu. Ini terlihat aneh karena sejumlah alasan dan menyerupai mekanisme penyensoran Internet di Rusia.


Saya sangat menyesal, tetapi saya harus ngelantur dan memberi tahu Anda bagaimana Internet, sistem otonom, dan perutean bekerja

Secara umum, istilah "Internet" dibuat dari dua kata: "Inter-Net", dan dapat diartikan sebagai "jaringan jaringan" atau "jaringan bersatu". Internet tidak memiliki "pusat teknis" (meskipun memiliki "pusat pengorganisasian"): Internet hanya menghubungkan jaringan yang berbeda, secara teori, sama satu sama lain (meskipun beberapa jaringan lebih sama daripada yang lain, tapi itu cerita untuk hari lain). Jaringan disebut "Sistem otonom" (AS) dan terhubung satu sama lain melalui gerbang, atau "rekan". Setiap AS memiliki nomor unik yang digunakan untuk mengidentifikasinya oleh AS lain. Suka alamat IP, tetapi dengan cara yang lebih umum. Setiap jaringan menerima dari "tetangganya" topologi koneksi ke jaringan terdekat, bagaimana jaringan terdekat terhubung ke jaringan terdekat mereka, dll. Pada dasarnya, setiap jaringan memiliki peta tentang bagaimana semua AS terhubung satu sama lain dari perspektif jaringan itu. Rute dari satu AS ke yang lain sesuai dengan peta itu hanya disebut "jalur AS".


Misalnya, nomor sistem otonom kami (ASN) adalah 204671, server Protonmail di-host di jaringan perusahaan besar Amerika Neustar, dan ASN-nya adalah 19905. Kami memiliki dua gerbang dengan ISP, yang berarti dua kemungkinan jalur AS dari kami ke Neustar jaringan. Untuk beberapa alasan, salah satu gerbang (melalui MGTS) lebih disukai, jadi jalur AS kami terlihat seperti ini: 204671 (kami) - 57681 (MGTS, ISP), 8359 (MTS, ISP lebih besar) - 22822 (Limelight) ) - 19905 (Neustar).


Dan inilah tabel peruteannya:



Setiap traceroute ke salah satu dari dua server MX Protonmail terputus di jaringan MTS dan tampak seperti ini:


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 * 

Kami menemukan host alternatif dalam jaringan Neustar dan menggunakannya sebagai referensi untuk menghilangkan kemungkinan gangguan antara MTS dan 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 

Sementara itu, kami berhasil menyelesaikan jejak lain melalui ISP lain ke server MX Protonmail (terputus di Neustar, tapi itu diharapkan - koneksi masih berfungsi):


 $ 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 

Mengingat bahwa traceroute bukan alat yang sangat andal, kami melakukan eksperimen pasangan lain, misalnya, dengan layanan Looking Glass MTS:



Menjadi jelas bahwa itu mungkin pembatasan layanan yang disengaja di tingkat MTS. Namun, berkonsultasi dengan registri resmi Roskomnadzor mengungkapkan bahwa kedua alamat (bukan nama domain, tidak ada IP) tidak terdaftar di sana:






Tidak dapat menemukan apa pun atas permintaan Anda


Mengesampingkan sensor internet di Rusia, hanya ada satu pembenaran yang sah bagi ISP untuk memblokir sumber daya - yang disebut "tempat pembuangan registri" yang berisi sumber daya tersebut menempatkan di sana lebih atau kurang secara hukum. Kadang-kadang sumber daya diblokir tanpa entri registri yang relevan (mereka biasa disebut "pemblokiran kurang-registri"), dan biasanya pembenaran untuk ini tidak memiliki peluang dalam kasus hukum apa pun.


Pada titik ini, kami menduga ada kesalahpahaman teknis sederhana atau pembukaan kunci yang rusak dari situs lain yang tidak terkait. Ya, kami tidak membunyikan alarm tanpa teliti memeriksa semuanya terlebih dahulu.


Kami mengirim email yang merinci temuan kami ke dukungan teknis MGTS dan meminta klarifikasi. Beberapa saat kemudian kami menerima jawaban: "bukan kita, ini MTS, tanya mereka." Tentu saja, kami tidak melakukannya, tetapi sebaliknya memaksa MGTS untuk melakukan pekerjaan mereka dan menyelidikinya dengan benar. Tanggapan yang kami dapatkan sangat menarik: menurut seorang karyawan MTS dari departemen terkait, mereka telah dihubungi oleh FSB melalui surat resmi No. 12 / T / 3 / 1-94 dari 25 Februari 2019, menuntut mereka untuk segera memblokir tuan rumah ini:



Pada titik ini, pendeteksi omong kosong kami telah keluar dari skala dan kami menggali lebih dalam lagi. Dan lebih cepat.


Kami mengirim permintaan ke FSB menanyakan apakah surat itu ada dan jika ada, pembenaran apa yang mereka miliki:



Kami meminta MGTS untuk memberikan pembenaran juga:



Setelah itu, kami pergi ke beberapa ruang obrolan topikal di layanan pesan instan Rusia ilegal tertentu. Komunitas telekomunikasi bereaksi dengan enggan:


  • “Saya punya pengalaman menyelesaikan masalah ini dan tidak ada yang mau menggunakan alat RKN. Pertama, ini rumit. Kedua, mentransfer masalah ke departemen lain tidak menyelesaikan masalah. "
  • "Anda perlu menyediakan begitu banyak dokumentasi dan melompati begitu banyak rintangan birokrasi (dan ada hukuman moneter karena tidak melakukan semua itu) sehingga tidak ada yang mengganggu."

Yah, sulit untuk benar-benar menilai mereka, mengingat mereka yang bekerja di telekomunikasi harus berurusan dengan begitu banyak omong kosong (mempertimbangkan "SORM", "node jaringan" atau "dump registri" bukan hanya kata-kata bagi mereka, tetapi gangguan sehari-hari) .


Namun demikian, ruang obrolan Komunitas Pertahanan Internet Rusia mengambil kasus itu dengan antusias dan melakukan penyelidikan sendiri.




Mereka menyarankan ide yang menarik - untuk memeriksa apa ISP (di Rusia dan lainnya) memblokir akses ke server MX melalui RIPE Atlas . Hasilnya dapat diprediksi, tetapi masih sangat aneh: di Rusia, server diblokir oleh MTS dan Rostelecom, serta jaringan yang bekerja melalui dua ISP ini ( hasil pada server MX primer , dan cadangan ). Pemeriksaan di seluruh dunia mendeteksi masalah di Rusia, Ukraina dan Iran ( hasil di seluruh dunia untuk server utama , dan cadangan ).


Penelitian yang lebih terlibat menunjukkan bahwa Rostelecom bertindak dengan cara yang sama:



Setelah akhir pekan, MTS akhirnya memberikan pemindaian surat FSB yang memerintahkan blok. Tentu saja, mereka menyalahkan "teroris telepon" dan mengikat semuanya ke Games Musim Dingin Universitas Dunia XXIX - Universiade 2019:




Kemudian perwakilan Protomail bereaksi pada reddit , Twitter , dan TechCrunch . Seperti yang diharapkan, mereka dikejutkan oleh kejujuran metode FSB dan menawarkan untuk bekerja sama dalam menemukan penjahat sejati:



Hmm. Protomail sendiri menduga ada agenda tersembunyi untuk semua ini. Ya, sepertinya memang begitu. Jadi, seperti yang sudah saya jelaskan pada avobe, data MX adalah mekanisme untuk menangani email yang masuk. FSB jelas sengaja mematahkan surat masuk daripada keluar, jadi, ahem, "pembenaran" penyelamatan kepala sekolahnya dari masalah sangat jelas dibuat-buat. Jadi, kami memiliki tiga opsi:


  • Mereka hanya memblokir apa yang pertama kali mereka temukan (penjelasan yang malas, tetapi yang paling mungkin menurut Occam Razor: seseorang pasti baru saja membaca "nslookup for dummies");
  • Mereka mencoba membatasi kemungkinan pengaturan alamat Proton yang anonim dan tidak dapat dilacak untuk mengumpulkan informasi yang merusak diri mereka sendiri (tidak berfungsi dalam sebagian besar kasus)
  • Penjelasan UFO sepintas.

Inilah buktinya: email yang dikirim dari Proton ke layanan lain melalui IP berbeda yang tidak diblokir. Ingat, FSB melarang 185.70.40.101 dan 185.70.40.102. Apakah Anda melihat ini di sini?



Kepala ProtonMail mengkonfirmasi temuan itu kepada TechCrunch dan menyarankan untuk memerangi aktivitas teroris bekerja sama dengan penegak hukum asing, daripada hanya menyerahkan masalah itu begitu saja:


Kepala eksekutif ProtonMail Andy Yen menyebut blok itu "sangat licik," dalam email ke TechCrunch.

"ProtonMail tidak diblokir dengan cara normal, itu sebenarnya sedikit lebih halus," kata Yen. “Mereka memblokir akses ke server surat ProtonMail. Jadi Mail.ru - dan kebanyakan server surat Rusia lainnya - misalnya, tidak lagi dapat mengirim email ke ProtonMail, tetapi pengguna Rusia tidak memiliki masalah untuk masuk ke kotak masuk mereka, "katanya.

"Pemblokiran grosir ProtonMail dengan cara yang menyakiti semua warga Rusia yang menginginkan keamanan online yang lebih besar sepertinya pendekatan yang buruk," kata Yen. Dia mengatakan layanannya menawarkan keamanan yang unggul dan enkripsi untuk email lain yang menyediakan saingan di negara ini.

"Kami juga telah menerapkan langkah-langkah teknis untuk memastikan layanan yang berkelanjutan bagi pengguna kami di Rusia dan kami telah membuat kemajuan yang baik dalam hal ini," jelasnya. "Jika memang ada keluhan hukum yang sah, kami mendorong pemerintah Rusia untuk mempertimbangkan kembali posisi mereka dan menyelesaikan masalah dengan mengikuti hukum internasional dan prosedur hukum yang berlaku."
- Kepala eksekutif ProtonMail Andy Yen @ TechCrunch

Selain itu, sepertinya surat FSB ini hanya diperintahkan untuk memblokir server SMTP untuk surat masuk. Akses web dan server SMTP keluar masih berfungsi, yang berarti bahwa apa pun yang FSB coba lakukan, mereka tidak pandai melakukannya.


Kami akan mengatakan lagi: bahkan mengabaikan seluruh sisi hukum masalah mengatur Internet pada 1/8 dari tanah Bumi, ada aturan mainnya. Aturannya tidak terlalu jelas, sangat ambigu dan berubah sepanjang waktu, tetapi masih aturan, bahkan jika aturan tersebut dirancang dengan jelas untuk memberi manfaat bagi pemelihara aturan ini. Dan bahkan kemudian, ada orang yang mencoba untuk memotongnya. Ini sangat Kafka-esque, tanpa proses hukum sama sekali. Setidaknya dalam kasus pengadilan apa pun Anda dapat memanggil ahli industri untuk berkonsultasi, tetapi keputusan itu murni didasarkan pada pandangan pribadi pribadi seseorang.


Jadi, inilah semua fakta yang telah kami kumpulkan hingga saat ini. Semua permintaan telah dikirim, tetapi tidak semua telah ditanggapi. Tentu saja, kami berharap itu hanya konsekuensi dari pekerjaan yang gagal oleh seseorang di MTS, tetapi, jujur ​​saja, itu tidak terlihat sangat mungkin dari awal.


Sedangkan bagi pengguna kami yang juga menggunakan Protomail, maka mereka dapat dengan aman terus menggunakan kotak surat Proton mereka dengan Habr, karena kami mengalihkan rute lalu lintas dari kami ke layanan Protomail melalui ISP Rusia lain yang tidak memainkan permainan seperti ini. Dan MGTS mungkin akan kehilangan pelanggan lain.

Source: https://habr.com/ru/post/id443638/


All Articles