Tor memperkenalkan pertahanan proof-of-work untuk layanan onion
(blog.torproject.org)- Tor 0.4.8 memperkenalkan pertahanan yang memprioritaskan lalu lintas jaringan yang terverifikasi saat layanan onion mengalami serangan DoS
- Dalam struktur layanan onion yang menyembunyikan alamat IP, pembatasan laju berbasis IP tidak sepenuhnya memadai, sehingga dibutuhkan metode teka-teki klien yang tidak merusak privasi
- Saat layanan berada di bawah tekanan, klien harus membuktikan beban kerja melalui operasi teka-teki yang makin sulit, dan prioritas koneksi ditentukan berdasarkan tingkat tersebut
- Waktu pemecahan awal untuk pengguna biasa sekitar 5ms pada komputer cepat dan hingga 30ms pada perangkat keras yang lebih lambat, sehingga masih dapat ditangani oleh sebagian besar perangkat
- Jika lalu lintas serangan meningkat, beban kerja yang diminta dapat naik hingga sekitar 1 menit, membuat upaya koneksi massal menjadi mahal, sementara pengguna normal tetap mendapat peluang akses di tengah kemacetan
Pertahanan PoW untuk layanan onion di Tor 0.4.8
- Bersamaan dengan rilis Tor 0.4.8, Tor secara resmi memperkenalkan pertahanan proof-of-work (PoW) untuk layanan onion
- Tujuannya adalah menekan serangan DoS sambil memprioritaskan lalu lintas yang terverifikasi
- Operator layanan onion disarankan memperbarui ke versi 0.4.8
- Karena layanan onion menyembunyikan alamat IP demi privasi pengguna, layanan ini dapat rentan terhadap serangan DoS, dan perlindungan hanya dengan pembatasan laju berbasis IP tradisional tidaklah memadai
Teka-teki klien dan pemrosesan prioritas
- PoW pada dasarnya bekerja seperti sistem tiket yang dinonaktifkan secara default, lalu membentuk antrean prioritas saat terjadi tekanan pada jaringan
- Sebelum mengakses layanan onion, klien harus memecahkan teka-teki kecil untuk membuktikan bahwa mereka telah melakukan sejumlah beban kerja tertentu
- Semakin sulit teka-tekinya, semakin besar pekerjaan yang telah dilakukan
- Layanan onion menentukan prioritas koneksi berdasarkan tingkat usaha yang ditunjukkan klien
- Jika penyerang membanjiri layanan onion dengan banyak permintaan, upaya komputasi yang diperlukan untuk mengakses situs .onion akan meningkat
- Upaya koneksi dalam jumlah besar membutuhkan lebih banyak sumber daya komputasi
- Semakin besar beban kerja, semakin rendah profitabilitas bagi penyerang
Dampak yang terlihat bagi pengguna umum
- Pengguna umum biasanya hanya mengirim sedikit permintaan sekaligus, sehingga beban pemecahan teka-teki tetap berada pada tingkat yang dapat dikelola oleh sebagian besar perangkat
- Waktu pemecahan awal sekitar 5ms pada komputer cepat
- Hingga 30ms pada perangkat keras yang lebih lambat
- Jika lalu lintas serangan meningkat, beban kerja dapat bertambah hingga sekitar 1 menit
- Proses ini tidak terlihat oleh pengguna, dan pengalaman menunggu jawaban PoW mirip dengan menunggu koneksi jaringan yang lambat
- Jika situs-situs utama mengadopsi pendekatan ini, dampak negatif serangan terarah terhadap kecepatan jaringan dapat berkurang, dan saat lonjakan lalu lintas mendadak terjadi, pendekatan ini dapat membantu penyeimbangan beban sehingga akses ke layanan onion menjadi lebih konsisten dan andal
1 komentar
Komentar Hacker News
Menarik. Kalau melihat proposalnya, ekspektasinya jelas: bukan untuk menghentikan botnet besar, melainkan menargetkan pertahanan terhadap script kiddie atau botnet skala kecil
Pengguna yang benar-benar ingin terhubung saat serangan DoS tetap bisa lewat, tetapi mungkin perlu sedikit usaha
Menarik juga bahwa https://github.com/tevador/equix dipilih sebagai algoritme proof-of-work
Bukan seperti Bitcoin, yang berhasil jika turun di bawah nilai target statis, melainkan struktur tempat klien “menawar” dengan upaya proof-of-work, dan semakin besar upaya yang dikeluarkan, semakin tinggi prioritasnya. Penjelasannya menyebut ini mirip proof-of-stake karena yang disetorkan bukan koin, melainkan pekerjaan
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
Versi ini juga bagus, tapi menurut saya akan lebih baik jika ditambahkan transfer nilai
Selain itu, proof-of-work hanyalah komputasi sia-sia yang tidak perlu. Komputasi tidak gratis, dan setiap watt yang dipakai untuk proof-of-work memperburuk krisis iklim saat ini
Sebagai orang yang tinggal di wilayah yang dalam beberapa hari akan mencapai suhu terasa 120 derajat dan suhu aktual 109 derajat, secara sopan saya ingin mengatakan: siapa pun yang menyarankan proof-of-work sebagai ide bagus untuk apa pun, silakan enyah
Ini bukan menarik, melainkan contoh konsumsi mencolok paling terang-terangan di Bumi
Tulisan yang lebih baik, yaitu detail teknis sebenarnya, ada di https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Fungsi proof-of-work yang dipilih tampaknya equi-X
Saya heran hal seperti ini tidak dimasukkan lebih awal, dan karena saya belum membaca proposal [0] dengan cukup detail, saya belum tahu apakah ini akan menambah data yang memengaruhi anonimitas pengguna. Namun kalau hanya diikat per pasangan pengguna-layanan dan tidak disimpan di mana pun, tampaknya tidak masalah
Saya juga penasaran seberapa besar ini akan mengurangi beban layanan yang diproksikan dan beban node itu sendiri secara terpisah. Karena akses tersebar ke beberapa node, sepertinya manfaatnya lebih besar di sisi layanan
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Bagus. Mungkin sebentar lagi CDN untuk pertahanan DDoS tidak diperlukan lagi. Cukup sediakan API sebagai layanan Onion
Cara seperti ini dulu juga pernah diusulkan untuk mencegah spam email
Cloudflare juga bisa melakukannya. Setiap kali mengakses situs yang sibuk, Anda akan dipaksa menjalankan komputasi tidak berguna selama beberapa detik hingga beberapa menit. Efek keseluruhannya tampaknya akan menyedot baterai di seluruh dunia
http://www.hashcash.org/
Menariknya, ini menjadi inspirasi untuk penambangan proof-of-work Bitcoin
Karena gas rumah kaca juga akan disemburkan ke atmosfer
Saya penasaran apa yang mencegah pelaku penyalahgunaan mendapatkan identitas baru dan terus melakukan DDoS ketika proof-of-work mulai berjalan
Edit: sepertinya proof-of-work ditetapkan per “layanan” yang diserang, bukan per klien
Karena anonimitas atau sifat yang memungkinkan pembuatan identitas baru secara bebas, penyerang dapat menguras kapasitas lewat serangan Sybil dan menyebabkan denial of service
Saya penasaran apakah ada cara yang lebih elegan untuk mengatasi serangan Sybil di sini. Misalnya, banyak CPU memiliki pasangan kunci unik per prosesor, dan bisa diverifikasi dengan sertifikat root CA dari penerbit seperti Intel, AMD, dan lainnya. Jika proof-of-work digabungkan dengan penandatanganan beruntun dan verifikasi paralel diizinkan, setiap proof-of-work menjadi unik per CPU sehingga tidak bisa diparalelkan dengan botnet
Mereka tampaknya menargetkan memori untuk menaikkan biaya botnet. Kelihatannya ada banyak cara lain untuk mengurangi skenario serangan ini. Logika yang sama mungkin bisa diterapkan pada ponsel yang memakai eSIM. Setelah itu, autentikasi jaringan seluler memakai kriptografi kunci publik, jadi sepertinya pembuktian unik juga mungkin dilakukan
Ini hanya ide spontan, jadi kemungkinan besar saya melewatkan masalah yang jelas dari pendekatan ini
Alasan memilih algoritma yang banyak memakai memori adalah untuk mencegah penggunaan hardware khusus, yaitu ASIC
Ke arah yang mirip, bagaimana kalau server memiliki beberapa pool IP dan klien diminta mengembalikan bukti port knocking? Misalnya, server memberi token, meminta klien mengirimkannya ke IP:port ini, lalu menunggu respons unik yang bisa diverifikasi. Ini bisa disebut bukti latensi. Penggunaan CPU rendah dan beban bisa didistribusikan ke beberapa mesin dan port. Kekurangannya jelas: perlu beberapa IP dan berpotensi beberapa server. Bisa saja diimplementasikan di mesin yang sama, tetapi kalau begitu beban CPU hanya berpindah menjadi koneksi port
Saya punya ide untuk mengurangi trafik jaringan Tor atau membuatnya lebih cepat. Jaringannya seharusnya bisa dipakai seperti CDN. Jika ingin memublikasikan sebuah file, kita seharusnya bisa mengirim potongan file ke node yang diizinkan, lalu ketika ada permintaan file, mengarahkan peminta ke node-node tersebut
Tentu saja harus berhati-hati agar jaringan Tor tidak menjadi “pengganti torrent anonim” dan merusak tujuannya
Usulan saat ini berbicara tentang “memprioritaskan trafik jaringan yang terverifikasi”. Karena itu benar-benar membantu jaringan, akan menarik jika berbagi “potongan file” bisa meningkatkan prioritas trafik. Dengan kata lain, ini menjadi bukti kontribusi bandwidth, bukan “proof-of-work”
Meski begitu, saya kurang paham bagaimana ini mengurangi trafik jaringan. Bagaimanapun juga tetap harus berkomunikasi dengan node CDN
Melihat tujuan dan batasan yang ditetapkan usulan ini, tampaknya masuk akal, dan mungkin akan mencapai tujuan tersebut. Seperti disebutkan, ini akan berhasil terhadap botnet kecil, tetapi botnet besar tetap bisa melampaui sumber daya yang tersedia pada klien individual
Secara pribadi saya tidak menyukai proof-of-work. Di sini ini lebih mirip non-dialog sebagai mekanisme pertahanan; bisa membuat hardware lama cepat menjadi usang, dan jika dilihat dari seluruh perangkat yang terdampak, kemungkinan memakai daya yang cukup besar. Jika diterapkan dalam skala besar, ini menjadi beban lingkungan yang signifikan
Dari sudut pandang penyerang, membuat tingkat kesulitannya setinggi itu saja sudah bisa dianggap keberhasilan. Jika pengguna harus menunggu 1 menit sambil perangkatnya berjalan 100%, dalam banyak kasus mereka akan pergi begitu saja
Tetap saja, ini cara yang cukup baik untuk meredam serangan DoS tanpa merusak anonimitas pengguna, jadi dari sudut pandang itu, terlepas dari kekurangannya, ini solusi yang bagus. Selama hanya ada di Tor, tidak terlalu bermasalah, tetapi jika diterapkan pada web umum, menurut saya itu akan menjadi bencana total
Artikelnya mengatakan perbedaan waktu penyelesaian antara server kelas atas dan ponsel kelas bawah hanya 6 kali. Saya tidak mengerti bagaimana itu mungkin. Server memiliki RAM dan jumlah CPU jauh lebih dari 6 kali dibanding ponsel, dan CPU-nya kemungkinan juga lebih cepat
Selain itu, dalam DDoS, pekerjaan di sisi server bisa diparalelkan dengan sangat mudah sampai menyulitkan, sedangkan pekerjaan di sisi klien belum tentu bisa diparalelkan
Bahkan kalau perbedaannya hanya 6 kali, atau bahkan 1 kali, katanya ketika DDoS terdeteksi waktu penyelesaiannya 1 menit. Pada titik itu, bukankah layanan tersebut pada dasarnya sudah tumbang?
Inti dari bagian bahwa waktu penyelesaian menjadi 1 menit saat DDoS terdeteksi adalah mengubah serangan DoS yang mudah saat ini, yaitu introduction flooding, menjadi kegagalan parsial atau perlambatan. Ini peningkatan bertahap untuk masalah yang sulit