Mitigasi Insiden Penyadapan MitM Hetzner/Linode XMPP.ru
(devever.net)- jabber.ru dan xmpp.ru mengalami serangan MitM yang menggabungkan penyadapan trafik di jalur penyedia hosting dengan penerbitan sertifikat Domain Validation tanpa izin, sehingga memperlihatkan celah pertahanan pada layanan TLS non-web
- Pemantauan log Certificate Transparency dan probing kunci publik TLS membantu menemukan tanda-tanda anomali, tetapi deteksi sempurna sulit dilakukan di hadapan sertifikat yang tidak tercatat di CT dan MitM selektif
- Jika ACME-CAA(RFC 8657) diterapkan bersama DNSSEC, hanya akun tertentu dari CA tertentu yang dapat diizinkan menerbitkan sertifikat, sehingga penyerang tidak cukup hanya memakai CA yang sama
- Berbeda dengan browser web, banyak klien non-web tidak mewajibkan bukti CT(SCT), dan CA/Browser Forum Baseline Requirements juga tidak mewajibkan logging CT untuk semua sertifikat
- Operator perlu mempertimbangkan ACME-CAA, DNSSEC, pemantauan CT, Tor onion service, dan penyebaran yurisdiksi; pengguna harus menjadikan enkripsi end-to-end dan verifikasi fingerprint sebagai garis pertahanan dasar
Struktur inti insiden
- Operator jabber.ru dan xmpp.ru menyatakan bahwa layanan mereka terkena serangan man-in-the-middle
- Serangan tersebut merupakan gabungan dari dua unsur
- Hetzner dan Linode menyadap trafik yang menuju mesin layanan
- Penyerang menerbitkan sertifikat Domain Validation untuk layanan tersebut tanpa izin
- Dinilai besar kemungkinan negara Jerman mengoordinasikannya, atau Jerman mengoordinasikannya bersama satu atau lebih negara lain
- Kemungkinan lain masih ada
- Hetzner dan Linode mungkin secara sukarela memenuhi permintaan penyadapan dari kekuatan asing tanpa paksaan hukum
- Namun dalam kasus ini, hal tersebut akan berdampak sangat buruk bagi reputasi kedua perusahaan dan bisa jadi ilegal, sehingga kemungkinannya dinilai rendah
Metode deteksi dan keterbatasannya
- Metode pertama adalah memantau log Certificate Transparency(CT) untuk menemukan penerbitan sertifikat yang tidak diminta oleh operator
- Ada beberapa layanan yang melakukan hal ini sebagai pengganti operator
- Alat yang hanya memilih dan memberi tahu sertifikat yang tidak diminta masih punya ruang untuk ditingkatkan
- Metode kedua adalah secara berkala terhubung ke layanan dan memeriksa apakah kunci publik server TLS sesuai dengan nilai yang diharapkan
-
Area yang bisa terlewat oleh pemantauan CT
- Bahkan sertifikat yang diterbitkan oleh CA yang sah tidak selalu dicatat di log CT
- CA/Browser Forum Baseline Requirements saat ini belum menjadikan logging CT sebagai persyaratan wajib bagi CA
- Browser web menolak sertifikat yang tidak memiliki bukti kriptografis bahwa sertifikat tersebut tercatat di log CT, sehingga logging CT secara praktis dipaksakan
- Sebagian besar aplikasi klien non-web tidak memeriksa atau mensyaratkan adanya bukti catatan CT pada sertifikat
- Secara teori, penyerang dapat memperoleh sertifikat yang tidak tercatat di CT
-
Kemungkinan MitM selektif menghindari deteksi
- Meski berupaya mendeteksi MitM melalui probing layanan, penyerang dapat mengidentifikasi koneksi untuk deteksi dan tidak menerapkan MitM pada koneksi tersebut
- Setidaknya probe perlu dijalankan melalui Tor agar terhindar dari situasi yang mudah diidentifikasi
- Stack TLS dapat di-fingerprint melalui sinyal seperti urutan daftar TLV, sehingga ada kemungkinan membedakan klien XMPP sungguhan dari agen probe
- Alih-alih mengecualikan probe yang dikenal dengan blacklist, penyerang juga dapat melakukan MitM dengan whitelist hanya terhadap trafik orang tertentu yang menjadi target
- Kedua metode deteksi tidak dapat memberikan keandalan penuh
Risiko yang dapat dikurangi dengan ACME-CAA
- Sertifikat TLS adalah mekanisme untuk mencegah serangan MitM, tetapi model Domain Validation yang digunakan CA untuk memverifikasi kendali domain itu sendiri rentan terhadap MitM
- Risiko meningkat jika penyerang dapat menyadap seluruh trafik menuju situs korban, bukan hanya sebagian
- ACME-CAA(RFC 8657) dapat memitigasi masalah ini dalam situasi tertentu
- Gagasan intinya adalah menggunakan record DNS untuk menetapkan bahwa hanya akun tertentu dari CA tertentu yang boleh menerbitkan sertifikat domain
- Sekadar menggunakan CA yang sama tidak cukup
- Diperlukan hak akses ke akun yang sama di CA tersebut
- Pada Let's Encrypt, diperlukan akses ke kunci privat ACME yang digunakan untuk permintaan sertifikat
- Berdasarkan metode serangan yang diketahui, jika ekstensi ini diterapkan, serangan tersebut dinilai dapat dicegah
-
Hal yang perlu diperhatikan saat penerapan
- Agar ACME-CAA berfungsi dengan benar, diperlukan penerapan DNSSEC
- Tanpa DNSSEC, permintaan DNS dari CA juga dapat disadap
- Orang yang menguasai kunci penandatangan DNSSEC dapat melewati penghalang ini
- Zona DNS yang dilindungi DNSSEC dapat dioperasikan tanpa menyerahkan kunci penandatangan kepada pihak ketiga
- Dalam kasus ini, penyedia hosting DNS tidak punya kewenangan untuk merusak zona
- Cara ini dinilai sebagai strategi penerapan terbaik
- Penyerang dapat mencoba menekan registrar domain atau registry TLD untuk mengubah kunci penandatangan DNSSEC yang terdaftar pada domain
- Tindakan ini kemungkinan akan terlihat
- Karena karakteristik caching DNS, mungkin sulit bagi penyerang untuk mencegah probe berulang mendeteksi perubahan kunci
- Ada juga kemungkinan penyerang menekan CA itu sendiri agar salah menerbitkan sertifikat
- Jika CA pihak ketiga melanggar aturan atau melakukan kesalahan, kerentanan tetap ada
- CA/Browser Forum Baseline Requirements mengharuskan CA memeriksa DNSSEC
- Namun CA pihak ketiga tetap dapat menerbitkan sertifikat meski tidak diizinkan oleh record CAA
- Karena logging CT tidak wajib, sertifikat semacam itu mungkin tidak terdeteksi
Alur yang bisa dipilih penyerang yang lebih mahir
- Penyerang dalam insiden ini bukan penyerang yang sempurna karena membiarkan sertifikat ilegal kedaluwarsa
- Seiring meluasnya enkripsi yang murah dan mudah, serangan tingkat negara diperkirakan akan menjadi lebih canggih dan lebih sering terjadi
- Penyerang tingkat negara yang lebih mahir dapat memilih alur berikut
- Memanfaatkan fakta bahwa CA tidak wajib mencatat sertifikat di log CT dan meminta sertifikat yang tidak tercatat
- Menekan penyedia hosting untuk melakukan MitM pada seluruh trafik yang menuju mesin korban
- Membedakan trafik target dan trafik deteksi secara heuristik berdasarkan fingerprint stack TLS dan IP asal
- Menggunakan MitM agar CA percaya bahwa penyerang adalah pengendali sah domain korban
- Jika domain menggunakan ACME-CAA dan DNSSEC, penyerang dapat mencoba menekan penyedia hosting DNS, registrar, registry TLD, atau CA
Celah dalam infrastruktur TLS saat ini
-
Kurangnya pemaksaan CT pada klien TLS non-web
- Browser web mensyaratkan sertifikat CA menyertakan bukti kriptografis atas pencatatan log CT
- Sebagian besar klien TLS lain tidak mewajibkan bukti CT, sehingga dapat menerima sertifikat yang tidak tercatat
- Banyak klien XMPP kemungkinan termasuk dalam kategori ini
- Verifikasi CT bukan fitur yang otomatis aktif hanya karena terhubung ke OpenSSL; diperlukan implementasi terpisah
- Perangkat lunak yang digunakan untuk komunikasi sensitif perlu mempertimbangkan dukungan pemaksaan CT
-
Tidak adanya kewajiban logging CT untuk sertifikat
- CA/Browser Forum Baseline Requirements, aturan industri yang harus diikuti CA, tidak mengharuskan sertifikat dicatat di log CT
- Dinilai perlu ada arah yang mewajibkan semua sertifikat dicatat di log CT
- Jika pemaksaan CT diterapkan secara luas, masalah ini secara teknis dapat menjadi tidak relevan
-
Kurangnya layanan pemantauan CT
- Dibutuhkan lebih banyak layanan pemantauan CT
- Layanan notifikasi CT utama saat ini mencakup SSLMate's Cert Spotter
- Harganya bisa menjadi beban bagi layanan berbasis relawan dan sejenisnya
- Pemantauan CT harus dirancang untuk mengurangi false positive dan hanya memberi tahu penerbitan sertifikat yang tampak abnormal atau tidak sah
-
Tidak adanya transparansi DNSSEC
- Saat ini tidak ada infrastruktur kriptografis yang telah diterapkan untuk mendeteksi perubahan kunci DNSSEC yang disetel pada domain
- Jika registrar domain dan registry TLD ditekan atau disusupi lalu mengubah kunci DNSSEC domain, perlindungan ACME-CAA dapat melemah
- Solusi transparansi yang membuat perubahan kunci zona DNSSEC terlihat publik akan diinginkan
- Solusi ini cukup mencatat perubahan kunci zona seperti record DS, bukan seluruh record pada zona
Rekomendasi untuk operator layanan
- Jika layanan berpotensi menjadi target serangan tingkat negara, disarankan menerapkan pertahanan berdasarkan urutan efektivitas biaya
-
ACME-CAA dan DNSSEC
- Menerapkan ACME-CAA dapat mempersulit penyerang menipu CA untuk menerbitkan sertifikat domain
- Panduan penerapan dapat merujuk pada artikel penerapan ACME-CAA
- Security Considerations dalam RFC juga memuat poin perhatian penting
- Jika menerapkan ACME-CAA, DNSSEC juga harus diterapkan bersama
- Jika memungkinkan, pilih penyedia DNSSEC yang tidak mengharuskan kunci penandatangan diserahkan kepada penyedia
-
Layanan proxy dan pemantauan CT
- Menggunakan layanan seperti Cloudflare dinilai mirip dengan kondisi ketika Anda sudah melakukan MitM terhadap diri sendiri
- Anda perlu berlangganan layanan pemantauan log CT atau secara berkala memeriksa log sendiri
- SSLMate's Cert Spotter menyediakan pemantauan otomatis berbayar
- Cert Spotter bersifat open source, sehingga juga dapat di-host sendiri
- crt.sh menyediakan pencarian manual log CT
-
Penyebaran yurisdiksi dan Tor onion service
- Anda dapat mempertimbangkan penyebaran yurisdiksi dengan menempatkan registrar domain, registry TLD, hosting DNS, CA, dan penyedia hosting di negara yang berbeda-beda
- Pemilihan dapat mempertimbangkan negara atau blok geopolitik yang kecil kemungkinannya saling bekerja sama
- Menyediakan Tor onion service dapat melewati infrastruktur terpusat seperti TLS dan CA
- Pada Tor onion service, kunci publik layanan adalah alamat itu sendiri
- Pengguna harus menerima alamat onion yang benar melalui kanal tepercaya
- Pihak ketiga dapat mengarahkan pengguna ke alamat onion yang salah
-
Probing otomatis berbasis Tor
- Probing otomatis melalui Tor bukan solusi sempurna, tetapi dapat menangkap kesalahan ceroboh yang terjadi di dunia nyata
- Menggunakan Tor mengurangi kemungkinan probe mudah diidentifikasi
- Untuk mengurangi kemungkinan fingerprint TLS, sebaiknya perangkat lunak klien menggunakan pustaka TLS yang umum dipakai
- Jika memungkinkan, menggunakan klien sungguhan lebih baik
- Untuk layanan XMPP, klien XMPP sungguhan dapat digunakan
- Sekalipun berhasil, ini hanya deteksi setelah kompromi terjadi, dan pada titik itu pengguna mungkin sudah menjadi korban
-
Vektor serangan lain dan asumsi terburuk
- Jika MitM dibuat lebih sulit, penyerang semakin mungkin menggunakan jalur lain seperti kompromi mesin itu sendiri, pencurian kunci privat, atau pencurian informasi sensitif
- Penyerang tingkat negara dapat menekan penyedia VM agar melakukan dump memori di tingkat hypervisor
- Server khusus pun dapat disusupi melalui akses fisik oleh penyerang
- Operator harus menganjurkan enkripsi end-to-end kepada pengguna dan berasumsi bahwa layanan bisa disusupi meski sudah berupaya sebaik mungkin
- Enkripsi “end-to-end” yang dikirim melalui aplikasi web dinilai bukan perlindungan yang bermakna
Tindakan yang diperlukan dari CA, pengembang klien, dan pengguna
-
CA/Browser Forum
- Harus mewajibkan semua sertifikat dicatat di log CT atau mengajukan usulan semacam itu
-
Pengembang aplikasi klien
- Menambahkan fitur yang mewajibkan adanya Signed Certificate Timestamps(SCTs) pada sertifikat TLS dan mengaktifkannya secara default
- Membuat pengguna dapat mengetahui bahwa mereka mendapatkan perlindungan ini
- Karena pemaksaan bukti CT memiliki sejumlah variabilitas, diskusi terkait juga perlu dipertimbangkan
- Perangkat lunak harus disediakan sebagai open source agar dapat diaudit publik
- Risiko rantai pasok dan kemungkinan pengembang sendiri dipaksa secara hukum untuk merusak perangkat lunak juga perlu dipertimbangkan
- Kanal distribusi yang tidak dikendalikan langsung oleh pengembang, seperti repositori paket distribusi Linux, dapat membantu mengurangi dampak
-
Pengguna akhir
- Bahkan jika operator layanan beroperasi dengan iktikad baik, pengguna harus berasumsi bahwa layanan dapat disusupi meski sudah berupaya sebaik mungkin
- Jika nyawa bergantung pada tidak disusupinya layanan tersebut, jangan percaya pada layanan itu
- Di XMPP, gunakan teknologi enkripsi end-to-end seperti OMEMO atau OTR
- Selalu verifikasi fingerprint lawan komunikasi
- Jangan melakukan enkripsi end-to-end dengan perangkat lunak berbasis web, atau setidaknya berasumsilah bahwa itu telah disusupi
- Jika penyedia layanan menawarkan Tor onion service, pertimbangkan untuk menggunakannya, tetapi alamat onion harus diperoleh dari sumber tepercaya
-
CA dan penulis standar
- Jika CA belum mendukung ACME-CAA(RFC 8657), mereka perlu mempertimbangkan implementasinya
- CA yang tidak berbasis ACME pun dapat mengimplementasikan ACME-CAA
- Meski aturan CA/Browser Forum mengizinkan sertifikat yang tidak tercatat di CT, CA dapat mengadopsi kebijakan untuk mencatat semua sertifikat di CT
- Penulis standar dapat kembali meninjau kemungkinan transparansi DNSSEC, setidaknya untuk record DS
Evaluasi terhadap confidential computing
- Jika turut mengkhawatirkan kompromi mesin oleh penyedia hosting, teknologi confidential computing saat ini tidak dinilai sebagai solusi yang memadai
- Penerapannya sendiri mungkin lebih baik daripada tidak melakukan apa pun, tetapi jangan dipercaya sebagai aman
- Teknologi saat ini, termasuk AMD, Intel, dan lainnya, dinilai bergantung pada kunci emas vendor yang dapat digunakan untuk memasang backdoor pada sistem
- Penyerang tingkat negara dapat menekan vendor agar menyerahkan kunci, dan jika itu terjadi metode tersebut runtuh
- Metode confidential computing yang tidak bergantung pada kunci emas mungkin saja memungkinkan, tetapi pendekatan saat ini belum memenuhi standar tersebut
Materi terkait
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: saran mitigasi khusus XMPP
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: laporan insiden asli
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 komentar
Komentar Hacker News
Ringkasan serangan di https://notes.valdikss.org.ru/jabber.ru-mitm/ menarik
Penyerang menerbitkan beberapa sertifikat SSL/TLS untuk jabber.ru dan xmpp.ru melalui Let’s Encrypt sejak 18 April 2023, dan terkonfirmasi bahwa dari 21 Juli hingga 19 Oktober, serangan man-in-the-middle diterapkan pada 100% trafik klien setidaknya di port XMPP STARTTLS 5222
Setelah itu, ketika gagal menerbitkan ulang sertifikat, port 5222 jabber.ru menyajikan sertifikat yang kedaluwarsa, dan tak lama setelah investigasi serta pertanyaan ke Hetzner/Linode dimulai, serangan berhenti, tetapi pada sebagian server Linode masih tersisa penyadapan pasif melalui hop routing tambahan
Server itu sendiri tampaknya tidak diretas, dan jaringan Hetzner serta Linode tampaknya direkonfigurasi dengan menargetkan IP layanan XMPP
Baik halaman tersebut maupun halaman yang ditautkan dari sini tidak menyebut certificate pinning; saya tidak tahu apakah karena XMPP tidak mendukungnya, tetapi jika mendukung, bukankah serangan seperti ini bisa dicegah
Sayangnya jabber.ru memakai perangkat lunak server dari 2016, jadi versi lama itu tidak mendukungnya
Certificate pinning sekarang banyak bermasalah karena umur sertifikat pendek dan sering diperbarui. Jika pengguna diminta setiap bulan untuk mengizinkan sertifikat baru, mereka juga akan menekan “Accept” begitu saja pada sertifikat penyerang
Channel binding bekerja terlepas dari sertifikat dan memastikan stream TLS berakhir pada pihak yang diharapkan
Agak mengherankan jika fokusnya pada ketiadaan dukungan CT/SCT di klien XMPP. Serangan ini menggunakan sertifikat valid yang diterbitkan Let’s Encrypt dan juga masuk ke log CT, sehingga tidak akan terdeteksi dengan CT/SCT
Jika ada record CAA yang ketat, verifikasi SCT mungkin bisa menangkap skenario teoretis ketika sertifikat diterbitkan oleh otoritas sertifikat lain, tetapi dalam praktiknya CAA pun tidak ada, dan channel binding lebih ramah privasi serta lebih sedikit bergantung pada pihak ketiga
Dengan kata lain, mereka bisa merespons protokol ACME pada HTTP yang di-hosting, atau bisa menulis record DNS TXT, sehingga tampaknya korban sudah kehilangan kendali atas server proses atau nameserver
Saya memahami certificate pinning hanya mungkin ketika klien dapat dikendalikan, dengan cara memasukkan langsung sertifikat yang diizinkan ke klien dan mem-bypass seluruh infrastruktur kunci publik web
Dalam situasi ketika klien umum tersambung, tidak ada cara untuk mengetahui sertifikat mana yang seharusnya diizinkan, dan memang untuk tujuan itulah infrastruktur kunci publik web digunakan
Tentu saja, sekalipun menyediakan klien sendiri, masalahnya hanya naik satu tingkat: lokasi tempat pelanggan mengunduh klien kustom bisa disusupi dan klien berbahaya dapat didistribusikan
Daftar ini melewatkan langkah pertahanan yang paling obvious. Sebagai metode autentikasi, SCRAM-xxxxx-PLUS harus diaktifkan dan, jika memungkinkan, diwajibkan
Ide varian PLUS sederhana tetapi efektif. Alih-alih memverifikasi hanya dengan salt, verifikasi diikat ke koneksi TLS tertentu, sehingga autentikasi hanya valid pada satu koneksi TLS
Ini juga disebut channel binding
Saya penasaran siapa pengguna akhir xmpp.ru dan jabber.ru. Apakah ini untuk menangkap trafik antara tentara atau mata-mata Rusia? Saya tidak suka pengawasan massal, tetapi tidak paham kenapa yang ditarget justru domain Rusia
Yang lebih masuk akal adalah skenario untuk menangkap carder atau operator botnet. Jabber/XMPP masih cukup populer di kalangan Rusia di dunia itu, dan di tulisan seperti Krebs on Security pun sering terlihat tangkapan layar atau log yang memuat berbagai server seperti @exploit.in, @jabber.ru, dan sebagainya
Meski begitu, apa pun niatnya, pengawasan massal pada umumnya menjijikkan
Saya tidak tahu persis berapa rasio penggunaan kriminal dan non-kriminal di kedua server itu, tetapi seperti Tor yang mencampurkan hal yang jelas ilegal dengan penggunaan sah, di sini pun pasti ada cukup banyak percakapan yang sepenuhnya biasa
Jadi sejak awal saya tidak terlalu setuju dengan pelanggaran privasi demi mengawasi sembarang pelaku kejahatan siber di negara di luar yurisdiksi yang bahkan sulit diekstradisi
Saya paham bahwa Hetzner mungkin tidak punya pilihan selain bekerja sama kalau tidak ingin bernasib seperti Lavabit, tetapi sebagai orang yang sering merekomendasikannya, saya akan cukup kecewa kalau Hetzner mengetahui serangan man-in-the-middle itu dan tetap mengizinkan atau membantunya. Di luar itu, saya menganggapnya salah satu perusahaan hosting terbaik
Transparansinya bagus, uptime, keandalan, dan dukungannya lebih baik daripada kebanyakan penyedia cloud, dan biayanya juga tidak berlebihan. Upaya mereka menjadikan desain ramah lingkungan sebagai pilihan yang juga cerdas secara ekonomi patut dipuji
Dalam “reduce > reuse > recycle”, bagian reduce terlihat pada desain KISS mereka. Misalnya atap tinggi dan miring yang membantu pembuangan panas alami[2], sasis server yang lebih mirip penopang struktur minimal dan penutup aliran udara daripada sasis sungguhan, serta desain mainboard standar dengan soket diputar 90 derajat agar VRM, CPU, dan memori dapat didinginkan oleh satu kipas[3]
“Reuse” terlihat pada lelang server mereka. Alih-alih membuang perangkat keras lama, mereka menyewakannya dengan mekanisme lelang Belanda, sehingga menghindari baik biaya perangkat keras baru maupun biaya lingkungan dari manufaktur baru di setiap generasi
Kalau mereka punya dedicated server di luar Eropa, saya ingin lebih banyak menggunakannya
[1]: “Legal” sendiri juga sulit didefinisikan. Jurnalis di satu negara adalah “agen asing” di negara lain, dan “pejuang kebebasan” di satu negara adalah “teroris” di negara lain
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
Tulisan itu mengatakan “CT bersifat opsional”, tetapi bukankah pada akhirnya ini masalah yang harus diputuskan oleh klien XMPP? Sekarang browser secara de facto mewajibkannya, saya penasaran apa yang menghalangi klien XMPP untuk mewajibkan CT
Saya juga tidak tahu trust store seperti apa yang mereka andalkan jika menerbitkan sertifikat yang tidak berfungsi di browser
Masalahnya, perilaku mewajibkan CT hampir tidak diaktifkan secara default di pustaka TLS mana pun. Jadi pengembang klien XMPP harus sengaja mengaktifkannya, dan saat ini saya rasa sebagian besar atau semuanya tidak melakukannya. Tentu saja ini bisa berubah
Tulisan ini menyarankan penggunaan OTR di XMPP, tetapi sayangnya OTRv3 memakai kriptografi lama dan OTRv4 belum final
https://dustri.org/b/time-to-sunset-otr.html
Untuk pertanyaan “apa yang akan dilakukan penyerang sempurna?”, kalau bisa mendapatkan akses fisik ke komputer, sepertinya ada cara mengekstrak data dari perangkat dengan semacam penyadapan bus
Itu masuk akal pada era dial-up serta broadband lambat dan berlatensi tinggi, tetapi sekarang banyak tempat memiliki fiber berkecepatan tinggi dan latensi rendah hingga titik peering
Semakin kita keluar dari data center dan cloud, infrastruktur internet seharusnya bekerja sebagaimana desain awalnya, dan kebutuhan untuk melewati titik agregasi terpusat yang kini menjadi titik kegagalan serius sekaligus risiko keamanan besar akan berkurang
Saya mencari tahu tentang CAA, tetapi penyedia DNS yang saya pakai tidak mendukung record tersebut. Apakah ada alasan mengapa harus berupa tipe baru, bukan record TXT yang lebih umum?
Jika tidak bisa, Anda perlu meminta dukungan. Record CAA adalah tipe yang semakin banyak dipakai, jadi layanan yang masih belum mendukungnya sekarang bukanlah layanan yang terlalu bagus
Saya tidak tahu detail pembahasan desain CAA, tetapi kemungkinan besar itu dibahas di milis IETF terkait
Penyedia DNS seharusnya mendukung berbagai tipe RR, dan pemilik domain harus memberikan suaranya melalui record NS
Daftar penyedia DNS yang mendukung CAA ada di https://github.com/StackExchange/dnscontrol/blob/master/docu...
Layak dicoba apakah Anda bisa menjalankan server primer tersembunyi dan menjadikan penyedia hanya sebagai server sekunder. Saya mengakali batasan itu di Linode dengan cara ini
Opsi untuk menjalankan otoritas sertifikat sendiri dan memilih sertifikat root dengan hati-hati terlewatkan
Penyedia dapat mengakses host, sehingga mereka bisa memeriksa pekerjaan dari luar tanpa disadari pengguna
Misalnya, mereka harus menanam modul kernel yang tetap bertahan setelah upgrade kernel dan menyembunyikan dirinya dengan sangat canggih. Artikel itu juga membahas analisis dump memori mentah
Apa solusi teknis mendasar untuk serangan seperti ini oleh negara atau aktor kuat setara negara? Adakah cara untuk memenuhi impian nyentrik tentang perangkat lunak yang dapat didistribusikan secara bebas, tetapi tidak dapat disensor, diintervensi, atau dimodifikasi oleh siapa pun selain pembuatnya?
Apakah sistem P2P yang dibangun dengan baik di atas infrastruktur internet saat ini sudah cukup sebagai jawaban, atau haruskah kita juga membangun internet mesh global berbandwidth rendah yang beroperasi secara nirkabel?
Semoga Freenet 2023 berkembang menjadi pengalaman pengembang yang mulus untuk aplikasi P2P