SS adalah yang asli, SSR adalah versi pihak ketiga yang berasal dari aslinya, kompatibel dengan protokol aslinya, dan memiliki beberapa fungsi kamuflase yang lebih banyak (protokol dan kebingungan) daripada aslinya.
Ada juga banyak diskusi tentang SSR di Internet, baik pro maupun menentang, tetapi untuk pengguna biasa. Apakah itu SS atau SSR, ini dapat membantu Anda memanjat dinding secara normal saat ini.
Adapun versi klien mana yang Anda unduh, semuanya tergantung pada apakah SS atau SSR diinstal di server akun SS yang Anda beli. Fungsi SS paling asli dapat digunakan tidak peduli klien mana yang diunduh, tetapi jika Anda ingin menggunakan fungsi SSR (protokol dan kebingungan), Anda harus mengunduh klien SSR.
Tapi jangan khawatir, semua node yang kami sediakan mendukung kompatibilitas SS dan SSR. Disarankan untuk menggunakan SSR. Lebih cepat untuk mencegah harmonisasi!
Ada banyak kebisingan tentang Shadowsocks beberapa waktu lalu, dan baru-baru ini jelas bahwa sejumlah besar pemula telah tertarik pada apa yang disebut "Shadowsocks Enhanced" (ShadowsocksR). Sebagai pengembang amatir penerapan Shadowsocks di C++/Qt, saya ingin mengungkapkan secara singkat pendapat saya tentang kedua ayam goreng ini.
Kaus kaki BayanganR
Saya tidak tahu apakah pengembang di belakangnya memiliki latar belakang atau tim, tetapi yang saya tahu adalah bahwa penulisnya memang menutup sumber klien Shadowsocks C# untuk pengembangan sekundernya yang melanggar GPL. Kami tidak akan berbicara tentang faktor lain di sini, faktanya GPL sangat jelas dalam warna hitam dan putih, melanggar adalah melanggar. Tetapi penulis kemudian membuka basis kode, yang dapat dianggap sebagai akhir dari sebuah insiden, dan tidak perlu mengejarnya lebih jauh.
Segalanya berubah setelah Clowwindy mengosongkan toko kode Shadowsocks-nya. Berikut ini hanyalah daftar fakta:
Penulis ShadowsocksR mengatakan bahwa dia ingin memulai dari awal untuk menulis alat proxy baru yang tidak terkait dengan shadowsocks, dan tidak akan lagi memperbarui ShadowsocksR
Dua atau tiga hari kemudian, ShadowSocks diperintahkan untuk dihapus, dan proyek Shadowsocks asli pada dasarnya menghilang
Penulis ShadowsocksR mengatakan bahwa protokol shadowsocks asli cacat (dibahas di bagian selanjutnya) dan kembali fokus
Penulis ShadowsocksR telah membuat Grup Google+ dan memperbarui kode terkait ShadowsocksR
Keamanan Shadowsocks
Sekarang, mari kita mulai dengan deskripsi klaim penulis ShadowsocksR bahwa cacat protokol Shadowsocks adalah bahwa panjang IV adalah 16 byte dalam banyak kasus. Paruh kedua benar, banyak algoritme enkripsi menggunakan IV yang panjangnya 16 byte (terutama AES dan RC4-MD5 yang populer), jadi bagaimana? Ini tidak memperkenalkan apa yang disebut "cacat" karena alasan berikut:
IV dari setiap koneksi TCP pada tahap jabat tangan dihasilkan secara acak, tidak dihitung dari kata sandi, sehingga IV tidak dapat diprediksi.
Tanpa kunci, bahkan jika bagian IV ini dicegat, teks sandi tidak dapat didekripsi. Dan setiap koneksi TCP baru menggunakan IV yang dihasilkan secara acak, yaitu, data yang dicegat dari koneksi TCP yang berbeda memiliki sedikit kesamaan. Dekripsi teks sandi memerlukan IV dan sandi yang benar, dan koneksi apa pun tidak memiliki karakteristik tentang sandi.
Sebagian besar IV memiliki panjang 16 byte, yang merupakan kemungkinan kombinasi dari 256 dengan pangkat 16, dan tidak mungkin untuk retak brute force ketika semua IV sama, apalagi menambahkan titik kedua.
Menurut pendekatan ShadowsocksR, tidak ada gunanya menambahkan apa yang disebut header obfuscation sebelum koneksi pertama, karakteristiknya sendiri jelas, dan itu tidak mengubah esensi IV selanjutnya atau panjang tetap sama sekali. Karena byte keempat memberi tahu Anda panjang data yang diisi secara acak, selama Anda melewatkan tumpukan sebelumnya saat melakukan apa yang disebut "probing", Anda masih dapat mencegat IV. Dan seperti yang saya katakan beberapa poin yang lalu, tidak ada gunanya jika Anda mendapatkan IV acak ini. Jika digunakan untuk deteksi, versi pertama logo tetap adalah fitur telanjang yang dikirim untuk identifikasi.
Penulis ShadowsocksR saat ini menyediakan skrip deteksi aktif yang dapat digunakan untuk mendeteksi apakah server menjalankan shadowsocks, dan menurut laporan pengujian online saat ini, tingkat keberhasilannya tidak rendah (tetapi tidak 100%). Dalam hal ini, Clowwindy telah memberikan solusi larangan otomatis dalam versi aslinya, secara otomatis memblokir IP berbahaya ini. Saya baru saja menambahkan tambalan ke libQtShadowsocks dan tambalan ini memblokir deteksi metode ini, yang mengembalikan string acak dengan panjang acak sesuai dengan probabilitas acak.
Namun, ini tidak berarti bahwa protokol Shadowsocks sempurna, tetapi "solusi" ShadowsocksR bengkok karena fokusnya bengkok. Ide pribadi saya adalah menggunakan kunci publik dan kunci pribadi untuk meningkatkan keamanan, meskipun tidak terlalu ramah bagi pemula, tetapi keamanannya akan ditingkatkan, dan karakteristiknya akan berkurang (tidak perlu mengirim IV pada tahap jabat tangan), dan protokol shadowsocks perlu berkembang ke arah keamanan CCA.
Diperbarui 05-Sep-2015
Setelah kesalahan header (tidak dapat diselesaikan) ditemukan, IV dan IP yang salah akan ditambahkan ke daftar IV dan IP yang gagal, jika IV sudah ada di daftar IV yang gagal, atau IP sudah ada di daftar IP yang gagal, IP yang mengirim permintaan koneksi akan ditambahkan ke daftar hitam, dan IP dalam daftar hitam akan langsung menolak koneksi. Untuk detail terbaru tentang anti-deteksi, silakan lihat masalah ini, dan artikel ini tidak akan memperbarui tindakan penanggulangan untuk anti-deteksi.
Diperbarui 06-Sep-2015
Artikel ini hanya ingin memberi tahu Anda untuk tidak terlalu khawatir tentang keamanan Shadowsocks, protokol saat ini belum memiliki kerentanan besar, dan server port utama juga sedang diperbarui untuk memperbaiki potensi ancaman. Saya juga telah berkomunikasi dengan baik dengan penulis ShadowsocksR, dan akan memakan waktu lama sebelum daftar putih tiba.
Diperbarui 24-Sep-2015
Keamanan Shadowsocks yang disebutkan dalam artikel ini lebih mengacu pada keamanan server, dan protokol saat ini memiliki risiko mengekspos server ke deteksi brute force dan kemudian diblokir oleh firewall (meskipun biaya deteksinya sangat tinggi). Keamanan konten yang ditransmisikan tidak perlu dikhawatirkan, yang semuanya adalah algoritme enkripsi berkekuatan tinggi kelas industri (kecuali RC4 dan TABLE), dan hampir tidak mungkin untuk memecahkan konten yang dikirimkan.
Diperbarui 18-Nov-2015
Shadowsocks telah meningkatkan keamanannya terhadap CCA dengan menambahkan satu verifikasi, dan port utama telah menyelesaikan dukungan mereka. Penting untuk menegaskan kembali bahwa tujuan Shadowsocks bukanlah untuk menjadi 100% bebas bug atau 100% antipeluru, tetapi untuk memastikan bahwa koneksinya ringan dan cepat sambil membuat metode serangan arus utama terlalu mahal untuk diterapkan.
|
Diposting pada 10/11/2017 12.41.35
|
|
|
