Enkripsi Lalu Lintas dalam Sambungan Langsung, Bagian 1

Dia mengatakan kepada mereka: raja-raja mendominasi bangsa-bangsa, dan para dermawan yang memiliki mereka dipanggil, dan kamu tidak demikian: tetapi siapa di antara kamu yang lebih besar, jadilah yang lebih rendah, dan penguasalah seperti hamba. Lx 22: 25.26

Ceritanya

Saya mulai berbuat dosa di Internet pada tahun 2004, dan jaringan lokal pada awalnya adalah godaan. Lebih tepatnya, sebuah program yang disebut DC ++ 0.401, yang secara ajaib memberikan akses ke file yang dibagikan oleh pelanggan lain dari LAN yang sama. Untuk melakukan ini, Anda harus terhubung ke satu atau lebih node dari jaringan file-sharing, yang disebut hub. Hub itu sendiri disimpan di komputer mereka oleh penggemar lokal.

" DC ++ " adalah nama klien. Protokol ini disebut " D irect Direct Connect". Hub DC . Pelanggan DC .

Ini pesona tersendiri. Di sini Anda offline, dan sekarang di dalam, di antara orang-orang yang telah melakukan tindakan yang kira-kira sama seperti sebelumnya. Luar biasa bukan?

Segera menjadi jelas bahwa hal yang sama dapat, pada prinsipnya, dilakukan tidak hanya dalam jaringan lokal, tetapi juga melalui Internet ... Berkomunikasi, berteman, bersumpah, bernegosiasi, membuat sumber daya Anda sendiri, mempromosikannya, meningkatkan, mencoba klien lain, mencari lubang dan kerentanan , terlibat dalam spionase industri, pengembang kontak, dll. dll.


Tabung Hangat DC ++ v. 0,401

Secara umum, DC, dengan fungsi komunikasi dan berbagi file yang sederhana, telah berhasil berfungsi sebagai jejaring sosial pada masa itu. Dan wajah manusia di sisi lain layar tampak sejauh yang Anda sendiri ingin melihatnya.

Tahun-tahun berlalu. Hub lokal hancur dan mati. Di bawah serangan Facebook, VKontakte dan torrent DC, hingga kurang dari lima ratus hub publik pada protokol NMDC lama dan sepuluh (sic!) Pada protokol Advanced Advanced Connect Connect Langsung merangkak.

Mulai

Seperti yang sudah diketahui pembaca, semua lalu lintas Rusia dipertahankan untuk saat ini. Memberi itu secara jelas tidak higienis, tetapi itulah yang dilakukan pengguna Direct Connect.

Jadi apa yang dibutuhkan? Pertama, enkripsi komunikasi klien DC dengan hub. Kedua, mengenkripsi komunikasi antar pelanggan.

Dan di sini masalahnya dimulai pada semua tingkatan hirarki digital yang sederhana dan sangat hierarkis ini.

Hub

Tiba-tiba, tidak ada hub yang cocok terdeteksi. Pada protokol NMDC lama, mereka tidak ada secara fisik. Namun, ADC sudah ada sejak 2008, tetapi mereka tidak melakukan cuaca, karena mereka tetap kecil. Oleh karena itu, sumber daya semacam itu harus digunakan secara independen dari hub ADC yang ada.

Pelanggan

Sudah ada dukungan perangkat lunak untuk TLS di klien DC untuk waktu yang lama, tetapi karena tidak ada kasus aplikasi, tidak ada yang benar-benar melihat ke bagian pengaturan ini juga. Tapi sia-sia!

Konversi hub ADC yang ada ke enkripsi mudah. Buat sertifikat yang ditandatangani sendiri, berikan ke mesin, pilih "kebijakan" TLS.

Tetapi kenyataannya adalah bahwa koneksi aman ke hub dibuat ketika menggunakan tautan dari formulir adc: //hub.address.com: port

Menyiapkan "kebijakan" TLS adalah untuk menyetujui koneksi normal (yaitu, ikuti tautan dari formulir adc: //hub.address.com: port), atau mengarahkan ulang pengguna tersebut di suatu tempat (misalnya, ke alamat "yang benar" )

tls_private_key="/etc/uhub/babylon.aab21pro.org.key" tls_certificate="/etc/uhub/babylon.aab21pro.org.crt" tls_enable=yes tls_require=yes tls_require_redirect_addr=adcs://babylon.aab21pro.org:412 

Contoh konfigurasi TLS untuk uHub

Opsi pertama meninggalkan kemungkinan menghubungkan pengguna dengan klien ke hub yang tidak tahu versi TLS lebih tinggi dari 1.0 (atau tidak tahu bagaimana), yang akan menimbulkan masalah ; dan yang kedua menjanjikan penurunan tajam kehadiran.

*** Menghubungkan ke adcs: //babylon.aab21pro.org: 412 ...
*** Kesalahan SSL 1: versi protokol peringatan tlsv1

Pesan seperti itu ketika mencoba terhubung ke hub ADC menampilkan klien yang hanya dapat TLS v.1.0

Ya, ternyata hub dalam kasus ini bertindak sebagai semacam sensor dan penjamin kemungkinan nominal koneksi aman.

Admin

Protokol lama memiliki satu kelemahan global: ketidakmampuan jaringan untuk bekerja sebagai unit dengan jumlah hub lebih dari satu. Ya, untuk jaringan lokal, satu hub besar adalah norma, tetapi de facto satu pengguna pada dua hub berbeda adalah dua pengguna yang sama sekali berbeda dari semua sudut pandang yang memungkinkan (kecuali untuk pengguna sendiri, tetapi ini tidak akurat). Dan jika Anda berhasil terhubung ke hub lebih dari sekali, maka isian lengkap dimulai.

Saat ini, administrator dan pemilik hub DC besar hanya tertarik pada jumlah pengguna online dan apa yang dapat dilakukan tentang hal itu. Pengguna dibeli dan dijual; tidak ada budaya interaksi antara administrator dan pengguna, tidak ada komunitas. Jika Anda mau, tidak ada moralitas, bersama dengan itu etika dan konsep norma, dan masalah yang muncul diselesaikan sesuai dengan konsep. Apakah Anda ingat terjemahan harfiah dari server kata? ..

Jadi fragmentasi feodal diperoleh. Lebih menguntungkan (untuk siapa?) Untuk memungkinkan segalanya bagi semua orang (misalnya, untuk menggunakan klien dengan kerentanan diketahui yang sudah usang 10 atau lebih tahun yang lalu) daripada bertindak sebagai penjamin apa pun.

Pengguna

Apa yang pasti dilakukan oleh pemilik hub adalah bahwa mereka menyiksa pengguna dengan spam yang menuntut untuk pergi ke suatu tempat atau mendaftar karena alasan tertentu alih-alih membagikan instruksi yang jelas jika terjadi situasi tertentu.

Pada saat itu, DC tidak menambah popularitas baik untuk kebutuhan untuk meneruskan port pada router dan untuk mengetahui "kualitas" dari alamat IP-nya. Prosedurnya tidak sulit, tetapi hingga hari ini menimbulkan masalah.

Akibatnya, bermasalah untuk menyampaikan informasi bermanfaat kepada pengguna hub di dalam hub itu sendiri. Jangan baca!

Ringkasan

Kami memeriksa teori dan masalah menerjemahkan file-sharing yang nyaman dalam Direct Connect ke penggunaan enkripsi modern, yang diperlukan saat ini. Seperti yang Anda lihat, untuk ini saya harus menunjukkan kekurangan dalam interaksi antara pengguna <=> program klien <=> hub <=> administrator dan datang dengan itu lagi .

Pada bagian kedua artikel, kami berencana untuk mempertimbangkan praktik memilih dan mengonfigurasi klien DC untuk bekerja pada hub ADC.