Keamanan Siber

Keamanan Siber / 24 Sep 2026 / 5 min read

Validasi Origin RPKI Memeriksa Otorisasi Prefix dan Origin

Sebuah pengumuman BGP dapat menyebut origin AS tanpa membuktikan bahwa pemegang ruang alamat yang diumumkan memberi otorisasi kepada AS tersebut untuk mengoriginkan rute. Resource Public Key Infrastructure, atau RPKI, menyediakan objek routing bertanda tangan yang diproses relying party menjadi data otorisasi tervalidasi. Validasi origin BGP membandingkan data itu dengan rute yang dilihat router. Pemeriksaannya sengaja sempit. Mekanisme ini mengevaluasi prefix rute dan origin AS terhadap record tervalidasi. Mekanisme tersebut tidak mengautentikasi setiap AS di AS_PATH, membuktikan bahwa path yang terlihat sah, atau menentukan apakah kebijakan ekspor telah dipatuhi.

Keamanan Siber RPKI

Keamanan Siber / 24 Sep 2026 / 5 min read

SSHFP Mengikat Fingerprint Host Key SSH ke DNSSEC

Klien SSH harus menentukan apakah host key yang diberikan server memang milik host yang dituju. Key yang sudah tersimpan dapat menjadi referensi pada koneksi berikutnya, tetapi koneksi pertama memerlukan dasar autentikasi lain. SSHFP menempatkan fingerprint public host key SSH di DNS agar klien dapat membandingkan key dari server dengan data yang diperoleh melalui jalur terpisah. Record DNS itu sendiri bukan trust anchor. RFC 4255 mengaitkan verifikasi SSHFP tepercaya dengan data DNS yang terautentikasi. DNSSEC melindungi jalur lookup dan memungkinkan klien pemvalidasi membedakan data bertanda tangan dari jawaban DNS yang tidak terautentikasi. Properti keamanan yang berguna berasal dari kombinasi tersebut: SSH menyediakan host key, SSHFP membawa fingerprint-nya, dan DNSSEC mengautentikasi record DNS yang dipakai untuk perbandingan.

Keamanan Siber SSH

Keamanan Siber / 24 Sep 2026 / 5 min read

security.txt Menerbitkan Kontak Kerentanan yang Dapat Diproses Mesin

Laporan kerentanan dapat kehilangan nilai bahkan sebelum triase dimulai jika pelapor tidak dapat menemukan kontak yang masih aktif dan dikendalikan organisasi. RFC 9116 menangani persoalan perutean itu melalui security.txt, file teks yang dapat diproses mesin dan diterbitkan pada lokasi HTTPS yang dapat diprediksi. File ini tidak memberikan izin pengujian, tidak membentuk program bug bounty, dan tidak membuktikan bahwa penerima yang tercantum dapat dipercaya. Perannya lebih sempit: menerbitkan metadata pengungkapan kerentanan dalam format yang dapat diambil secara konsisten oleh manusia maupun perangkat otomatis.

Cybersecurity security.txt

Keamanan Siber / 24 Sep 2026 / 5 min read

security.txt Menerbitkan Jalur Pelaporan Kerentanan dengan Batas yang Jelas

Sebuah celah keamanan dapat sulit dilaporkan meski layanan yang terdampak mudah diidentifikasi. Formulir dukungan umum dapat mengirim pesan ke antrean yang salah, mailbox keamanan lama mungkin tidak lagi dipantau, dan peneliti tidak dapat menganggap sebuah kebijakan disclosure berlaku hanya dari nama perusahaan. RFC 9116 menangani masalah routing tersebut melalui security.txt, file kecil yang dapat diproses mesin dan diterbitkan operator layanan. File ini tidak menyatakan bahwa sebuah layanan aman, tidak memberi izin untuk melakukan pengujian, dan tidak mendefinisikan seluruh program vulnerability disclosure. Tugasnya lebih sempit: menerbitkan jalur pelaporan yang masih berlaku beserta metadata terkait pada lokasi yang dapat diprediksi.

Cybersecurity Vulnerability Disclosure

Keamanan Siber / 24 Sep 2026 / 5 min read

Record CAA Membatasi Penerbitan Sertifikat Publik

Certificate authority publik tidak hanya memvalidasi kontrol atas nama DNS. Sebelum menerbitkan sertifikat, CA yang mengikuti spesifikasi CAA juga memeriksa DNS untuk mencari kebijakan Certification Authority Authorization yang relevan bagi setiap nama dalam permintaan. Kebijakan itu dapat mempersempit kumpulan penerbit yang diizinkan membuat sertifikat untuk domain tersebut. CAA merupakan kontrol penerbitan, bukan pengganti validasi kontrol domain. CA yang sudah diizinkan tetap harus menjalankan persyaratan validasi dan penerbitannya. Record ini menambahkan satu keputusan lagi: setelah validasi berhasil, apakah penerbit tersebut diizinkan oleh kebijakan CAA yang dipublikasikan domain?

Cybersecurity CAA

Keamanan Siber / 24 Sep 2026 / 6 min read

OCSP Stapling Mengirim Status Sertifikat dalam Handshake TLS

Validasi sertifikat menjawab lebih dari satu pertanyaan. Klien memeriksa bahwa sertifikat membentuk rantai ke root tepercaya, cocok dengan identitas yang dituju, berada dalam interval validitas, dan memenuhi kebijakan yang berlaku. Status pencabutan merupakan sinyal terpisah: sertifikat masih dapat berada di antara waktu notBefore dan notAfter setelah penerbit mencabutnya. Online Certificate Status Protocol (OCSP), yang ditetapkan dalam RFC 6960, memberi klien mekanisme untuk meminta status sertifikat. Namun, kueri langsung menambah dependensi jaringan pada proses pembentukan koneksi dan mengungkap identitas sertifikat yang diperiksa kepada responder. OCSP stapling memindahkan pengambilan tersebut ke server TLS. Server secara berkala memperoleh respons OCSP bertanda tangan lalu mengirimkannya kepada klien sebagai bagian dari handshake TLS.

Cybersecurity TLS

Keamanan Siber / 24 Sep 2026 / 6 min read

OCSP Stapling Membawa Status Sertifikat di Dalam TLS

Validasi sertifikat menjawab lebih dari satu pertanyaan. Klien dapat memverifikasi rantai issuer, nama, tanda tangan, dan masa berlaku, tetapi masih memerlukan informasi terkini mengenai apakah sertifikat telah dicabut sebelum tanggal kedaluwarsanya. Online Certificate Status Protocol (OCSP), yang ditetapkan dalam RFC 6960, menyediakan informasi status bertanda tangan untuk sebuah sertifikat. Pada pola OCSP langsung, klien menghubungi responder yang dioperasikan oleh, atau didelegasikan untuk, issuer sertifikat. OCSP stapling mengubah jalur pengiriman: endpoint TLS mengambil respons OCSP lalu mengirimkannya kepada klien di dalam handshake TLS.

Cybersecurity TLS

Keamanan Siber / 24 Sep 2026 / 5 min read

NSEC3 Menghash Record Penyangkalan DNSSEC Tanpa Menyembunyikan Nama yang Mudah Ditebak

Tanda tangan DNSSEC dapat mengautentikasi data yang ada, tetapi resolver juga memerlukan bukti kriptografis ketika nama atau tipe record yang diminta tidak ada. Respons NXDOMAIN tanpa tanda tangan tidak dapat memberikan properti tersebut: penyerang yang mampu mengubah lalu lintas DNS dapat membuat respons serupa. NSEC3 menyediakan record penyangkalan bertanda tangan sambil mengganti owner name teks biasa dalam rantai penyangkalan dengan hash. RFC 5155 mendefinisikan NSEC3 sebagai alternatif NSEC untuk authenticated denial of existence. Perbedaan utamanya terkait privasi cukup sempit tetapi berguna: penelusuran rantai NSEC secara langsung mengungkap owner name yang berdekatan, sedangkan NSEC3 mengekspos hash yang memerlukan pekerjaan tambahan untuk dipetakan kembali ke nama kandidat.

Keamanan Siber DNSSEC

Keamanan Siber / 24 Sep 2026 / 5 min read

Nonce CSP dan strict-dynamic Memindahkan Kepercayaan Script ke Root yang Diotorisasi

Content Security Policy dapat membatasi eksekusi script tanpa memelihara daftar panjang hostname tepercaya. Policy berbasis nonce memberi token yang tidak dapat diprediksi dan spesifik untuk satu respons kepada elemen script tertentu. Saat strict-dynamic juga hadir, browser yang mendukungnya dapat meneruskan kepercayaan dari root script terotorisasi ke script yang dibuat root tersebut secara programatis. Batas keamanannya berubah. Kepercayaan melekat pada root eksekusi yang diotorisasi, bukan pada setiap origin jaringan yang mungkin menyajikan JavaScript.

Cybersecurity Content Security Policy

Keamanan Siber / 24 Sep 2026 / 5 min read

MTA-STS Mengikat Pengiriman SMTP ke TLS Terautentikasi

SMTP umumnya meningkatkan koneksi plaintext dengan STARTTLS. Tanpa kebijakan transport yang terautentikasi, peningkatan tersebut dapat tetap bersifat oportunistik: pengirim dapat melanjutkan pengiriman saat TLS tidak tersedia, bergantung pada konfigurasinya. Perantara aktif yang dapat mengganggu pertukaran SMTP bisa memanfaatkan kelonggaran itu dengan menekan kapabilitas STARTTLS atau mengalihkan pengiriman. MTA Strict Transport Security (MTA-STS), yang ditetapkan dalam RFC 8461, memberi domain penerima sebuah kebijakan yang dapat disimpan dalam cache dan ditegakkan oleh MTA pengirim yang patuh. Kebijakan tersebut menyatakan host MX yang dapat diterima dan apakah pengiriman memerlukan TLS dengan sertifikat yang lolos validasi PKIX.

Cybersecurity MTA-STS

Keamanan Siber / 24 Sep 2026 / 7 min read

MTA-STS Mengikat Pengiriman SMTP ke Host yang Mendukung TLS

SMTP dirancang untuk memindahkan email di antara sistem yang dikelola secara independen, sedangkan STARTTLS oportunistik ditambahkan kemudian. Peningkatan ini memperbaiki kerahasiaan saat kedua sisi mendukungnya, tetapi perilaku oportunistik memiliki kelemahan struktural: jika negosiasi TLS gagal, pengirim dapat tetap mengirim melalui koneksi plaintext. Penyerang aktif di jaringan yang dapat mengganggu trafik SMTP dapat memanfaatkan fallback tersebut dengan menekan STARTTLS atau mengarahkan pengiriman ke host yang tidak semestinya. MTA-STS, yang distandardisasi dalam RFC 8461, memberi domain penerima cara untuk menyatakan kebijakan yang lebih ketat. Pengirim yang mendukungnya mengambil kebijakan melalui HTTPS, menyimpannya dalam cache, lalu menerapkannya pada pengiriman SMTP berikutnya. Dalam mode enforcement, pengirim mewajibkan host MX yang diotorisasi dan koneksi TLS yang valid sebelum mengirim pesan.

Cybersecurity MTA-STS

Keamanan Siber / 24 Sep 2026 / 4 min read

Log Certificate Transparency Membuka Penerbitan Sertifikat Publik

Sertifikat yang dipercaya secara publik dapat valid secara sintaksis, memiliki tanda tangan yang benar, tetapi tetap tidak diharapkan. Otoritas sertifikat dapat menerbitkannya untuk subjek yang keliru, sebuah akun dapat dikompromikan, atau proses otorisasi dapat gagal. Certificate Transparency (CT) menambahkan visibilitas publik pada penerbitan sertifikat agar sertifikat semacam itu tidak harus tetap tersembunyi dari operator domain yang terdampak. RFC 9162 menetapkan Certificate Transparency Version 2.0. Mekanisme utamanya adalah log publik append-only yang ditopang Merkle tree. Otoritas sertifikat dan pengirim lain dapat mengirim sertifikat atau precertificate ke log, sedangkan monitor dapat memeriksa entri untuk sertifikat yang berkaitan dengan domain yang mereka pantau.

Cybersecurity PKI

Keamanan Siber / 24 Sep 2026 / 5 min read

HTTP Message Signatures Mengikat Komponen HTTP yang Dipilih

TLS melindungi pertukaran HTTP selama trafik bergerak melalui koneksi TLS, tetapi beberapa desain aplikasi memerlukan pernyataan kriptografis yang melekat pada pesan HTTP itu sendiri. Gateway dapat menghentikan TLS sebelum meneruskan request, layanan dapat perlu mengautentikasi metadata request tertentu, atau pesan dapat melewati beberapa hop HTTP ketika perlindungan transport dan kepercayaan aplikasi berada pada batas yang berbeda. HTTP Message Signatures, yang ditetapkan dalam RFC 9421, menangani batas tersebut. Signer memilih komponen pesan HTTP, membentuk signature base sesuai aturan, menandatanganinya, lalu mengirim metadata yang memberi tahu verifier komponen dan parameter yang tercakup. Mekanisme ini sengaja bersifat selektif: sebuah tanda tangan tidak otomatis mencakup setiap field atau setiap properti pesan.

Cybersecurity HTTP

Keamanan Siber / 24 Sep 2026 / 4 min read

HSTS Menutup Jalur Downgrade HTTPS pada Koneksi Berikutnya

TLS melindungi koneksi HTTPS setelah klien memilih HTTPS dan menyelesaikan TLS handshake. Masih ada persoalan terpisah pada batas skema. Pengguna dapat mengetik hostname tanpa skema, membuka tautan lama http://, atau mencapai redirect yang dimulai melalui cleartext. Penyerang yang mampu mengganggu pertukaran HTTP pertama dapat mencoba mempertahankan browser agar tidak beralih ke HTTPS. HTTP Strict Transport Security (HSTS), yang didefinisikan dalam RFC 6797, memindahkan keputusan tersebut ke user agent. Setelah sebuah host mengirim header Strict-Transport-Security yang valid melalui koneksi aman, user agent yang sesuai menyimpan kebijakan itu. Selama masa berlakunya, percobaan berikutnya untuk menghubungi host tersebut melalui HTTP diubah menjadi HTTPS sebelum request HTTP dikirim.

Cybersecurity HTTPS

Keamanan Siber / 24 Sep 2026 / 5 min read

HSTS Mengikat Origin HTTP ke TLS Setelah Kontak Aman Pertama

HTTPS melindungi koneksi setelah klien memilih HTTPS dan menyelesaikan TLS. Pengguna yang memasukkan hostname tanpa skema, membuka bookmark http://, atau menerima tautan HTTP masih dapat memulai melalui HTTP tanpa enkripsi sebelum server mengalihkan request. HTTP Strict Transport Security (HSTS), yang didefinisikan dalam RFC 6797, memindahkan keputusan pengalihan tersebut ke user agent setelah origin menetapkan kebijakan melalui koneksi aman. Kebijakan HSTS merupakan state yang disimpan klien. Setelah diterima, state ini mengubah perilaku navigasi dan koneksi berikutnya untuk host yang tercakup sampai kebijakan kedaluwarsa atau diganti.

Cybersecurity HSTS

Keamanan Siber / 24 Sep 2026 / 5 min read

Encrypted Client Hello Menjaga Metadata TLS Sensitif di Dalam ClientHello Inner

TLS 1.3 mengenkripsi sebagian besar pesan handshake setelah ServerHello, tetapi ClientHello awal dikirim sebelum key handshake tersebut tersedia. Akibatnya, field pada flight pertama masih terlihat oleh pengamat jaringan. Server Name Indication (SNI) sangat sensitif karena dapat menunjukkan layanan yang dituju meski sertifikat berikutnya dan traffic aplikasi sudah terenkripsi. RFC 9849 mendefinisikan Encrypted Client Hello (ECH) untuk mempersempit paparan itu. ECH tidak mengenkripsi seluruh paket pertama. Mekanisme ini membentuk dua pesan ClientHello dengan peran berbeda: ClientHelloInner privat yang memuat parameter koneksi untuk backend dan ClientHelloOuter publik yang membawa representasi terenkripsi dari pesan inner.

Cybersecurity TLS

Keamanan Siber / 24 Sep 2026 / 5 min read

DNS Cookies Mengikat Permintaan UDP pada Keterjangkauan Jalur Balik

UDP memungkinkan pengirim menaruh alamat sumber pada datagram tanpa handshake transport yang membuktikan bahwa pengirim dapat menerima trafik pada alamat tersebut. DNS mewarisi sifat ini saat berjalan di atas UDP. Penyerang off-path dapat mengirim query dengan alamat sumber palsu dan mencoba membuat server DNS mengarahkan respons ke host lain. DNS Cookies menambahkan mekanisme challenge-and-return ringan di dalam EDNS. RFC 7873 mendefinisikan opsi COOKIE, sedangkan RFC 9018 memperketat konstruksi Server Cookie untuk deployment yang interoperabel. Mekanisme ini tidak mengubah UDP menjadi transport terautentikasi. Ia memberi klien dan server DNS bukti tambahan mengenai apakah peer telah ikut dalam pertukaran sebelumnya pada alamat jaringan yang relevan.

Cybersecurity DNS

Keamanan Siber / 24 Sep 2026 / 5 min read

DNS Cookies Mengikat Balasan UDP ke State Klien Terkini

UDP memberi DNS transport dengan overhead rendah, tetapi source address dapat dipalsukan dan balasannya dapat ditiru oleh pengirim off-path. DNS Cookies menambahkan sedikit state yang dibuat klien dan, setelah kontak dengan server yang mendukungnya, state yang dibuat server. Mekanisme ini menaikkan biaya pemalsuan off-path tanpa mengharuskan server menyimpan tabel sesi untuk setiap klien. Cakupannya sengaja terbatas. RFC 7873 mendeskripsikan DNS Cookies sebagai keamanan transaksi ringan terhadap serangan denial-of-service, amplifikasi, pemalsuan, dan cache poisoning dari pihak off-path. Mekanisme ini tidak melindungi dari pihak yang dapat mengamati pertukaran DNS. RFC 9018 kemudian memperketat konstruksi cookie agar server anycast dengan implementasi berbeda dapat saling beroperasi.

Keamanan Siber DNS

Keamanan Siber / 24 Sep 2026 / 5 min read

Delegated Credential TLS Membatasi Paparan Kunci Sertifikat

Deployment TLS berskala besar sering membutuhkan kemampuan penandatanganan pada banyak mesin layanan. Menyalin private key sertifikat ke setiap endpoint memperluas jumlah sistem yang dapat membocorkan kredensial berumur panjang ketika dikompromikan. Menyimpan kunci itu di satu lokasi dengan kontrol ketat mengurangi paparan, tetapi remote signing untuk setiap handshake dapat menambah dependensi operasional pada jalur layanan. Delegated Credentials for TLS, yang distandardisasi dalam RFC 9345, menyediakan pilihan yang lebih sempit untuk TLS 1.3. Pemegang sertifikat dapat memakai private key sertifikat untuk mengotorisasi public key lain selama periode terbatas. Endpoint menerima delegated private key pasangannya dan dapat mengautentikasi handshake TLS tanpa memegang private key sertifikat.

Cybersecurity TLS

Keamanan Siber / 24 Sep 2026 / 5 min read

DANE TLSA Mengikat Kunci TLS ke DNSSEC

TLS biasanya mengautentikasi server melalui rantai sertifikat yang berakhir pada trust anchor yang sudah diterima klien. DANE menambahkan jalur lain: domain dapat menerbitkan record TLSA di DNS dan melindunginya dengan DNSSEC. Klien yang mendukung DANE kemudian dapat mencocokkan material sertifikat dari TLS handshake dengan asosiasi yang diterbitkan domain. RFC 6698 mendefinisikan resource record TLSA. RFC 7671 memperbarui aturan operasional dan mempersempit beberapa pilihan deployment. Properti keamanannya spesifik: hanya data TLSA yang tervalidasi DNSSEC yang layak digunakan untuk autentikasi DANE. RRset TLSA berstatus insecure atau indeterminate tidak menyediakan binding DNS terautentikasi yang dibutuhkan DANE.

Cybersecurity DANE

Keamanan Siber / 24 Sep 2026 / 6 min read

DANE TLSA Mengikat Kredensial TLS ke DNSSEC

Sertifikat TLS biasanya sampai ke klien melalui TLS handshake, lalu klien memutuskan apakah sertifikat itu dapat dipercaya berdasarkan kebijakan autentikasi yang dikonfigurasi. DNS-Based Authentication of Named Entities, atau DANE, menambahkan input terautentikasi yang terpisah: record TLSA yang dilindungi DNSSEC dapat menyatakan material sertifikat atau public key yang dapat diterima untuk endpoint layanan tertentu. Mekanisme ini bukan nama pengganti untuk TLS. TLS tetap menyediakan handshake, key agreement, enkripsi, dan perlindungan record. DANE menyediakan data autentikasi yang dapat diterapkan klien saat mengevaluasi kredensial server.

Keamanan Siber DANE

Keamanan Siber / 24 Sep 2026 / 5 min read

Certificate Transparency Memisahkan Janji Log dari Bukti Inklusi

Sertifikat TLS dapat lolos validasi chain biasa dan tetap perlu diawasi secara publik. Certificate Transparency (CT) menambahkan visibilitas tersebut dengan menempatkan sertifikat atau precertificate pada log publik yang dirancang untuk audit. Model keamanannya lebih presisi daripada sekadar pernyataan bahwa sertifikat sudah dicatat: CT memisahkan janji bertanda tangan dari log dengan bukti berikutnya bahwa entri yang dijanjikan benar-benar masuk ke Merkle tree milik log. RFC 9162 mendeskripsikan CT versi 2.0. Log yang sesuai merupakan Merkle tree append-only. Saat menerima pengajuan sertifikat atau precertificate, log mengembalikan Signed Certificate Timestamp (SCT). SCT adalah komitmen bertanda tangan yang terkait dengan pengajuan yang diterima dan sebuah timestamp. SCT sendiri bukan Merkle inclusion proof.

Cybersecurity TLS

Keamanan Siber / 24 Sep 2026 / 6 min read

CDS dan CDNSKEY Mengotomatiskan Pembaruan Trust Delegasi DNSSEC

Child zone yang ditandatangani DNSSEC dapat merotasi signing key tanpa langsung mengubah delegasi, tetapi validator pada akhirnya bergantung pada record set DS yang dipublikasikan parent. State di sisi parent ini menciptakan titik serah operasional: key baru di child tidak otomatis menjadi anchor delegasi aman hanya karena key tersebut sudah dipublikasikan oleh child. CDS dan CDNSKEY menyediakan mekanisme in-band untuk titik serah tersebut. RFC 7344 menetapkan record yang dapat dipublikasikan child pada apex zone untuk memberi sinyal parameter DS yang diusulkan. Parental agent dapat mengambil sinyal itu, memvalidasinya berdasarkan aturan yang berlaku, menerapkan kebijakan penerimaan lokal, lalu memperbarui set DS di sisi parent.

Cybersecurity DNSSEC

Keamanan Siber / 24 Sep 2026 / 4 min read

CAA Membatasi Penerbitan Sertifikat ke CA yang Diotorisasi

Otoritas sertifikat publik memvalidasi kendali atas nama domain sebelum menerbitkan sertifikat, tetapi kendali domain bukan satu-satunya kebijakan yang dapat dipublikasikan operator domain. Certificate Authority Authorization (CAA), yang ditetapkan dalam RFC 8659, menambahkan sinyal berbasis DNS yang menyatakan CA mana yang diizinkan menerbitkan sertifikat untuk suatu nama. CAA tidak menggantikan validasi kendali domain. CAA menambahkan titik keputusan lain sebelum penerbitan: CA yang mematuhi ketentuan memeriksa kebijakan CAA yang berlaku dan hanya melanjutkan jika kebijakan tersebut mengizinkan CA menerbitkan sertifikat yang diminta.

Cybersecurity CAA