Cybersecurity

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

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

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 / 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

Keamanan Siber / 23 Sep 2026 / 5 min read

Validasi Origin RPKI Memeriksa Otoritas Prefix BGP

BGP mengumumkan reachability, tetapi sebuah route advertisement tidak membuktikan bahwa Autonomous System yang menjadi origin memiliki otorisasi untuk mengumumkan prefix tersebut. Resource Public Key Infrastructure, atau RPKI, menambahkan data otorisasi resource bertanda tangan yang dapat diubah menjadi record untuk validasi origin pada router. Pemeriksaan ini sengaja memiliki cakupan sempit. Prefix dan origin AS pada rute dibandingkan dengan validated ROA payloads, yang umum disebut VRP. Hasilnya dapat digunakan oleh kebijakan routing, tetapi tidak mengautentikasi setiap AS di dalam AS_PATH dan tidak mengubah BGP menjadi protokol validasi path.

Cybersecurity RPKI

Keamanan Siber / 23 Sep 2026 / 6 min read

TLS-RPT Menampilkan Kegagalan TLS SMTP sebagai Laporan Agregat

Keamanan transport SMTP memiliki persoalan observabilitas. Domain penerima dapat memublikasikan kebijakan MTA-STS atau record DANE TLSA, tetapi banyak kegagalan terjadi pada sistem pengirim di luar kendalinya: validasi sertifikat dapat gagal, host MX dapat tidak terjangkau, negosiasi STARTTLS dapat bermasalah, atau kebijakan transport yang dipublikasikan dapat tidak valid. Penerima memerlukan telemetri dari pengirim tersebut untuk membedakan deployment yang berfungsi dari kebijakan yang tanpa terlihat menghambat pengiriman. SMTP TLS Reporting, yang umum disebut TLS-RPT, menetapkan kanal telemetri tersebut dalam RFC 8460. Domain penerima memublikasikan record DNS TXT yang menyebut satu atau beberapa tujuan laporan. Sistem pengirim yang mendukung mekanisme ini kemudian menghasilkan laporan agregat mengenai sesi TLS yang berhasil memenuhi kebijakan dan kegagalan yang ditemui saat mengirim email ke domain tersebut.

Cybersecurity TLS-RPT

Keamanan Siber / 23 Sep 2026 / 4 min read

TLS Must-Staple Mewajibkan Status OCSP

TLS Must-Staple Mewajibkan Status OCSP OCSP stapling memungkinkan server TLS membawa bukti status sertifikat di dalam handshake. Client dapat memvalidasi response tersebut tanpa membuat request terpisah ke OCSP responder milik certificate authority. Namun, stapling biasa tidak otomatis membuat response yang hilang menjadi kesimpulan tentang status sertifikat: ketiadaan dapat sekadar berarti server tidak mengirimkannya. RFC 7633 mendefinisikan ekstensi X.509v3 TLS Feature. Sertifikat dapat memakai ekstensi ini untuk menyatakan bahwa sebuah fitur TLS diwajibkan. Fitur yang umum disebut Must-Staple menunjuk status_request, sehingga penggunaan sertifikat terikat pada pengiriman informasi status sertifikat bagi client yang mengimplementasikan ekstensi tersebut.

Cybersecurity TLS

Keamanan Siber / 23 Sep 2026 / 5 min read

Subresource Integrity Mengikat Aset Eksternal ke Digest Kriptografis

Subresource Integrity Mengikat Aset Eksternal ke Digest Kriptografis Halaman web dapat memuat JavaScript dan CSS dari origin di luar batas deployment-nya sendiri. Susunan ini praktis untuk package bersama dan content delivery network, tetapi sebagian jalur eksekusi atau presentasi halaman ikut bergantung pada server yang mengirim resource tersebut. Subresource Integrity (SRI) menambahkan batasan pada tingkat byte terhadap dependensi itu. Halaman menyertakan satu atau beberapa digest kriptografis melalui atribut integrity. Browser yang mendukung SRI mengambil resource, menghitung digest memakai algoritma yang dideklarasikan, lalu menerima response hanya jika byte-nya memenuhi metadata integritas.

Cybersecurity Web Security

Keamanan Siber / 23 Sep 2026 / 4 min read

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC Client SSH memerlukan dasar tepercaya untuk menentukan apakah host key server benar-benar milik host yang dituju. Entri lokal known_hosts menyediakan dasar tersebut setelah sebuah key diterima, tetapi koneksi pertama tetap memerlukan jalur verifikasi jika key belum diprovisikan sebelumnya. SSHFP menempatkan fingerprint host key di DNS. RFC 4255 mendefinisikan resource record SSHFP agar client dapat membandingkan public key yang disajikan server SSH dengan fingerprint yang dipublikasikan untuk hostname tersebut. Properti keamanannya bergantung pada data DNS yang terautentikasi: fingerprint yang cocok dari jawaban DNS tanpa autentikasi tidak memenuhi kondisi trust yang ditetapkan untuk verifikasi SSHFP yang aman.

Cybersecurity SSH