TLS

Keamanan Siber / 21 Sep 2026 / 6 min read

TLS Must-Staple Menjadikan OCSP Stapling sebagai Policy Sertifikat

TLS Must-Staple Menjadikan OCSP Stapling sebagai Policy Sertifikat OCSP stapling memungkinkan server TLS mengirim bukti status sertifikat di dalam handshake sehingga setiap client tidak perlu menghubungi OCSP responder milik certificate authority. Susunan ini mengurangi satu dependency jaringan tambahan di sisi client, tetapi stapling biasa bersifat opsional: ketiadaan response yang di-staple tidak dengan sendirinya membuktikan bahwa sertifikat tidak valid. Ekstensi X.509 TLS Feature mengubah kondisi tersebut ketika mengiklankan status_request. Dalam penggunaan ini mekanismenya umum disebut Must-Staple. Sertifikat menyatakan bahwa server diharapkan menyediakan TLS feature terkait. Client yang meminta feature tersebut sekaligus menerapkan ekstensi sertifikat dapat menolak koneksi ketika response status yang diwajibkan tidak tersedia.

Cybersecurity TLS

Keamanan Siber / 21 Sep 2026 / 5 min read

OCSP Stapling Membawa Status Revocation di TLS

OCSP Stapling Membawa Status Revocation di TLS Validasi sertifikat menjawab lebih dari satu persoalan. Client dapat memeriksa signature, nama, masa berlaku, dan trust anchor, tetapi sertifikat yang lolos pemeriksaan tersebut masih dapat berstatus revoked setelah diterbitkan. Status revocation karena itu berada di samping validasi path normal, bukan menggantikannya. Online Certificate Status Protocol (OCSP) menyediakan response status bertanda tangan untuk sertifikat. Client dapat melakukan query langsung ke OCSP responder, tetapi cara itu menambahkan pihak ketiga ke proses pembentukan koneksi. OCSP stapling memindahkan response yang sesuai ke pertukaran TLS: server mengambil response lalu menyajikannya kepada client yang meminta status sertifikat.

Keamanan Siber TLS

Keamanan Siber / 21 Sep 2026 / 6 min read

Mutual TLS Mengautentikasi Kedua Sisi Koneksi

Mutual TLS Mengautentikasi Kedua Sisi Koneksi Koneksi HTTPS konvensional mengautentikasi server dengan certificate, sementara client biasanya membuktikan identitasnya kemudian melalui mekanisme aplikasi seperti session cookie, bearer token, atau password. Mutual TLS, yang umum disingkat mTLS, menambahkan autentikasi client berbasis certificate ke dalam exchange TLS. Hasilnya adalah transport channel tempat setiap peer dapat memverifikasi certificate chain dan proof of possession atas private key dari sisi lainnya. Hal itu mengubah boundary autentikasi, tetapi tidak menjadikan certificate sebagai authorization policy. Identitas client yang valid tetap dapat ditolak saat mengakses resource tertentu.

Keamanan Siber TLS

Keamanan Siber / 21 Sep 2026 / 6 min read

Log Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit

Log Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Sertifikat TLS yang dipercaya publik dapat valid menurut PKI tetapi tetap tidak diharapkan oleh operator domain. Certificate authority dapat menerbitkan sertifikat setelah kompromi akun, kesalahan validasi, atau kegagalan lain pada jalur penerbitan. Validasi sertifikat biasa memeriksa chain, hostname, masa berlaku, signature, dan policy yang relevan. Pemeriksaan tersebut tidak memberi tahu operator bahwa ada sertifikat valid lain untuk nama yang sama. Certificate Transparency (CT) menambahkan lapisan audit publik pada penerbitan sertifikat. Certificate authority mengirim sertifikat atau precertificate ke log publik append-only. Log mengembalikan Signed Certificate Timestamp (SCT), yaitu janji bahwa item yang dikirim akan dimasukkan dalam maximum merge delay yang ditetapkan log. Client dapat mewajibkan bukti CT yang sesuai sebagai bagian dari policy sertifikat, sementara operator domain dapat memantau log untuk nama yang mereka kelola.

Keamanan Siber TLS

Keamanan Siber / 21 Sep 2026 / 5 min read

DNS CAA Membatasi CA yang Boleh Menerbitkan Sertifikat

DNS CAA Membatasi CA yang Boleh Menerbitkan Sertifikat Certificate authority yang dipercaya secara publik hanya dapat menerbitkan sertifikat setelah menyelesaikan validasi yang diwajibkan oleh policy-nya dan aturan ekosistem yang berlaku. DNS Certification Authority Authorization (CAA) menambahkan kontrol lain: domain dapat menyatakan CA mana yang diizinkan menerbitkan sertifikat untuk namespace DNS tersebut. CAA tidak menggantikan validasi kontrol domain, Certificate Transparency, atau verifikasi sertifikat oleh client. Mekanisme ini membatasi penerbitan di sisi CA. CA yang memproses permintaan memeriksa policy CAA yang relevan sebelum penerbitan dan tidak boleh menerbitkan ketika policy melarangnya.

Keamanan Siber PKI

Keamanan Siber / 21 Sep 2026 / 6 min read

Certificate Transparency Membuat Penerbitan Sertifikat TLS Dapat Diaudit

Certificate Transparency Membuat Penerbitan Sertifikat TLS Dapat Diaudit Sertifikat TLS yang dipercaya publik dapat valid secara kriptografis tetapi tetap merupakan sertifikat yang tidak pernah diminta operator domain. Validasi sertifikat membentuk chain ke certification authority yang dipercaya dan memeriksa sertifikat terhadap policy client. Proses itu sendiri tidak memberi operator domain catatan global atas seluruh sertifikat yang diterbitkan untuk namanya. Certificate Transparency (CT) menambahkan lapisan visibilitas tersebut. Log publik menerima sertifikat atau precertificate, membuat komitmen untuk mencatatnya, lalu menyediakan riwayat append-only yang dapat diperiksa monitor. Mekanisme ini tidak menghentikan certification authority yang menerbitkan sertifikat bermasalah. CT membuat penerbitan dapat diamati dan memberi client dasar untuk meminta bukti bahwa sertifikat telah diserahkan ke log yang diterima.

Keamanan Siber TLS

Keamanan Siber / 20 Sep 2026 / 6 min read

Verifikasi Hostname TLS Mengikat Sertifikat Valid ke Nama yang Diminta

Verifikasi Hostname TLS Mengikat Sertifikat Valid ke Nama yang Diminta Sertifikat TLS dapat valid secara kriptografis tetapi tetap salah untuk server yang hendak dihubungi client. Validasi chain memeriksa apakah sertifikat dapat dihubungkan ke trust anchor yang dikonfigurasi berdasarkan aturan PKI yang berlaku. Verifikasi identitas service memeriksa hal yang berbeda: apakah sertifikat tersebut mewakili hostname yang diminta client. Kedua pemeriksaan diperlukan untuk autentikasi HTTPS biasa. Menerima sertifikat tepercaya tanpa memeriksa nama yang diminta mengubah kredensial dengan cakupan sempit menjadi kredensial untuk tujuan lain yang tidak terkait.

Cybersecurity TLS

Keamanan Siber / 20 Sep 2026 / 5 min read

Sertifikat Client mTLS Mengautentikasi Peer, Bukan Hak Akses

Sertifikat Client mTLS Mengautentikasi Peer, Bukan Hak Akses Mutual TLS menambahkan autentikasi client pada koneksi TLS. Server meminta sertifikat, memvalidasi sertifikat yang disajikan berdasarkan trust policy yang dikonfigurasi, lalu memperoleh informasi sertifikat terautentikasi sebelum data aplikasi diterima melalui koneksi tersebut. Hasil itu berguna, tetapi cakupannya lebih sempit daripada keputusan otorisasi. Sertifikat client yang valid dapat membuktikan bahwa sebuah peer menguasai private key yang terkait dengan sertifikat yang diterima. Sertifikat tersebut tidak dengan sendirinya menetapkan API method, data tenant, operasi administratif, atau resource service yang boleh digunakan peer itu.

Cybersecurity mTLS

Keamanan Siber / 20 Sep 2026 / 6 min read

Pinning SPKI TLS Memerlukan Jalur Rotasi

Pinning SPKI TLS Memerlukan Jalur Rotasi Certificate pinning menambahkan batas trust lokal di atas pemeriksaan sertifikat yang sudah dilakukan TLS client. Alih-alih menerima setiap sertifikat yang memenuhi aturan PKI dan identitas service yang dikonfigurasi, client dengan pin juga mensyaratkan koneksi menyajikan material kriptografis yang cocok dengan nilai yang sudah ditanam, diprovisikan, atau dipercaya melalui mekanisme lain oleh client. Policy yang lebih sempit ini dapat mengurangi paparan terhadap penerbitan sertifikat di luar key set yang dimaksud. Konsekuensinya adalah dependency operasional baru: client harus memiliki jalur yang valid dari key yang diterima saat ini menuju key yang dapat dipakai setelah rotasi.

Cybersecurity TLS

Keamanan Siber / 20 Sep 2026 / 6 min read

OCSP Stapling Membawa Status Sertifikat ke dalam TLS Handshake

OCSP Stapling Membawa Status Sertifikat ke dalam TLS Handshake Certificate chain yang valid menjawab satu pertanyaan penting dalam TLS: apakah public key yang disajikan dapat ditautkan melalui issuer tepercaya ke identitas yang diminta? Chain tersebut tidak dengan sendirinya menyatakan bahwa sertifikat yang belum kedaluwarsa masih dapat diterima oleh issuer. Mekanisme revocation menangani status yang terpisah itu. Online Certificate Status Protocol (OCSP) memungkinkan relying party meminta status sertifikat dari OCSP responder. OCSP stapling mengubah pihak yang membawa status tersebut. Alih-alih mengharuskan setiap client menghubungi responder saat koneksi dibuat, server TLS dapat mengambil respons OCSP bertanda tangan dan menyertakannya ke handshake.

Cybersecurity TLS

Keamanan Siber / 20 Sep 2026 / 5 min read

HSTS Menetapkan Kebijakan HTTPS di Browser

HSTS Menetapkan Kebijakan HTTPS di Browser Redirect dari HTTP ke HTTPS berguna, tetapi redirect tetap berupa response HTTP. Browser yang memulai dari http://example.com sudah mengirim request tanpa autentikasi sebelum server sempat menjawab dengan 301 atau 308. Penyerang yang dapat memodifikasi koneksi tersebut dapat menghilangkan atau mengganti redirect. HTTP Strict Transport Security (HSTS) memindahkan sebagian kebijakan transport ke browser. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, browser yang mendukung HSTS mengingat bahwa host tersebut mewajibkan transport aman selama masa yang dinyatakan. Upaya berikutnya untuk memakai HTTP pada host itu diubah secara lokal sebelum request HTTP dikirim.

Cybersecurity HSTS

Keamanan Siber / 20 Sep 2026 / 6 min read

DNS CAA Membatasi Certificate Authority yang Boleh Menerbitkan untuk Domain

DNS CAA Membatasi Certificate Authority yang Boleh Menerbitkan untuk Domain Sertifikat TLS yang dipercaya publik diterbitkan oleh certificate authority yang memenuhi requirement trust browser dan operating system. Operator domain biasanya memilih satu CA, tetapi ekosistem public trust dapat berisi banyak authority yang mampu menerbitkan sertifikat yang diterima client. Record Certification Authority Authorization (CAA) menambahkan policy DNS pada saat issuance. Domain dapat menyatakan CA mana yang diizinkan menerbitkan sertifikat untuknya. RFC 8659 menetapkan model pemrosesan, termasuk lookup record, property tag, dan perilaku issuer.

Cybersecurity DNS

Keamanan Siber / 20 Sep 2026 / 6 min read

Certificate Transparency Membuat Misissuance Dapat Diaudit Publik

Certificate Transparency Membuat Misissuance Dapat Diaudit Publik Browser dapat memvalidasi certificate chain TLS tetapi tetap menghadapi masalah struktural pada PKI: certification authority tepercaya dapat menerbitkan sertifikat valid lain untuk domain yang sama tanpa diharapkan operator domain. Path validation biasa memeriksa sertifikat yang disajikan pada koneksi saat ini. Proses itu tidak menyediakan inventaris global atas sertifikat yang diterbitkan di tempat lain. Certificate Transparency (CT) menambahkan audit trail publik. Sertifikat TLS publik atau precertificate dapat dikirim ke CT log yang memelihara Merkle tree append-only. Log yang menerima submission mengembalikan Signed Certificate Timestamp (SCT), yaitu komitmen bertanda tangan yang terkait dengan entry tersebut. Monitor dapat memeriksa isi log untuk sertifikat yang relevan, sedangkan auditor dapat memeriksa bukti inclusion dan consistency.

Cybersecurity TLS

Komputasi Awan / 19 Sep 2026 / 5 min read

Wildcard Subdomain di Cloudflare Workers: Batas Routing dan TLS

Hostname seperti demo.instara.app dapat mencapai Cloudflare Worker melalui satu wildcard DNS record dan satu Worker Route. Hostname yang lebih dalam seperti web.demo.instara.app dapat di-resolve oleh wildcard DNS record yang sama, tetapi tetap gagal sebelum Worker dijalankan karena edge certificate tidak mencakup hostname tersebut. Perbedaan ini penting karena ada tiga mekanisme independen yang terlibat dalam sebuah request: DNS resolution | v Worker Route matching | v TLS certificate coverage Ketiganya menggunakan sintaks wildcard, tetapi aturan pencocokannya tidak identik.

Komputasi Awan Cloudflare Workers

Keamanan Siber / 19 Sep 2026 / 4 min read

State HSTS Menutup Celah Downgrade pada Request Pertama

State HSTS Menutup Celah Downgrade pada Request Pertama Sebuah situs dapat mengalihkan setiap request HTTP ke HTTPS dan tetap memiliki celah sebelum redirect itu tiba. Browser sudah lebih dahulu mengirim request HTTP melalui jaringan. Perantara aktif dapat mengubah pertukaran tersebut, menahan redirect, atau mempertahankan koneksi client pada HTTP plaintext. HTTP Strict Transport Security (HSTS), yang ditetapkan dalam RFC 6797, memindahkan lokasi keputusan tersebut. Setelah menerima header Strict-Transport-Security yang valid melalui koneksi aman, user agent yang sesuai menyimpan state kebijakan untuk host itu. Navigasi HTTP berikutnya ke host tersebut diubah menjadi HTTPS secara lokal sebelum request tidak aman dikirim.

Cybersecurity HSTS

Keamanan Siber / 19 Sep 2026 / 7 min read

OCSP Stapling Memindahkan Bukti Pencabutan ke TLS Handshake

OCSP Stapling Memindahkan Bukti Pencabutan ke TLS Handshake Sertifikat TLS dapat masih berada dalam masa berlaku setelah penerbitnya menandai sertifikat tersebut sebagai dicabut. Tanggal dan tanda tangan pada sertifikat tidak memuat perubahan status yang terjadi kemudian, sehingga client yang menerapkan pemeriksaan pencabutan memerlukan informasi status dari mekanisme lain. OCSP menyediakan respons status bertanda tangan untuk sertifikat tertentu. OCSP stapling mengubah jalur pengirimannya: TLS server mengambil respons lalu mengirim bukti bertanda tangan itu kepada client selama handshake.

Keamanan Siber TLS

Keamanan Siber / 19 Sep 2026 / 5 min read

MQTT over TLS pada ESP32: Enkripsi Transport dan Autentikasi Broker Adalah Batas yang Berbeda

ESP32 yang memindahkan koneksi MQTT dari port 1883 ke 8883 tidak sekadar berpindah port. Stream TCP sekarang diharapkan membawa MQTT di dalam TLS. Data dalam perjalanan terlindungi hanya jika client TLS juga memvalidasi sertifikat broker. Autentikasi username/password MQTT merupakan mekanisme terpisah: kredensial mengidentifikasi client kepada broker, sedangkan validasi sertifikat mengidentifikasi broker kepada ESP32. Menyebut konfigurasi ini “MQTT dengan HTTPS” mencampur dua protokol aplikasi. MQTT tidak berubah menjadi HTTP ketika TLS ditambahkan. MQTT dapat berjalan melalui TCP biasa atau melalui koneksi TCP yang dilindungi TLS.

ESP32 MQTT

Keamanan Siber / 19 Sep 2026 / 7 min read

Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit, Bukan Otomatis Aman

Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit, Bukan Otomatis Aman Sertifikat yang dipercaya publik dapat valid secara sintaksis, memiliki chain menuju trusted root, tetapi tetap merupakan penerbitan yang tidak diharapkan operator domain. Certificate Transparency (CT) menutup celah visibilitas tersebut dengan menempatkan penerbitan sertifikat ke log append-only yang dapat diaudit secara publik. Mekanisme ini mengubah keterlihatan Web PKI; sertifikat yang tercatat di log tidak otomatis menjadi bukti bahwa setiap keputusan penerbitannya benar.

Keamanan Siber TLS

Keamanan Siber / 19 Sep 2026 / 7 min read

Binding Sertifikat OAuth mTLS Memindahkan Bukti Token ke Koneksi TLS

Binding Sertifikat OAuth mTLS Memindahkan Bukti Token ke Koneksi TLS Sebuah OAuth access token dapat lolos dari seluruh pemeriksaan sintaks dan kriptografi di resource server tetapi tetap belum cukup untuk memperoleh akses. Pada token yang terikat sertifikat mutual TLS, server juga memerlukan bukti dari koneksi TLS: client yang membawa token harus memiliki private key yang sesuai dengan sertifikat yang diasosiasikan dengan token tersebut. Kondisi ini mengubah batas keamanan. Bearer token dapat digunakan oleh pihak yang memperoleh nilai token, dengan tetap tunduk pada pembatasan token lainnya. Token yang terikat sertifikat menambahkan syarat kepemilikan terpisah yang terhubung ke TLS client certificate. Token dan private key menjadi dua bagian dalam jalur otorisasi yang sama.

Keamanan Siber OAuth

Keamanan Siber / 17 Sep 2026 / 6 min read

TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake

TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake Server TLS dapat memiliki private key yang valid dan menyajikan sertifikat yang membentuk chain ke root tepercaya, tetapi bukti status revokasinya tidak tersedia. OCSP stapling biasa tidak selalu mengubah kondisi tersebut menjadi kegagalan: client dapat meminta informasi status, tetapi dalam protokol stapling dasar server masih diperbolehkan tidak mengirim respons. Sifat opsional ini menciptakan batas keamanan. Intermediary aktif yang mampu menghalangi akses ke OCSP responder dapat memanfaatkan kebijakan client yang menerima pemeriksaan revokasi yang tidak konklusif. Ekstensi TLS Feature dari RFC 7633 mengubah sertifikat itu sendiri sehingga fitur TLS tertentu menjadi syarat penggunaan yang dapat diterima. Untuk OCSP stapling, sertifikat dapat menyatakan bahwa client yang patuh harus menerima bukti status yang diminta.

Keamanan Siber TLS

Keamanan Siber / 17 Sep 2026 / 9 min read

Identitas Mutual TLS Dapat Hilang di Terminating Proxy

Identitas Mutual TLS Dapat Hilang di Terminating Proxy Sebuah layanan dapat mewajibkan sertifikat client pada endpoint publik, hanya menerima sertifikat yang berantai ke certificate authority yang disetujui, tetapi tetap meneruskan request yang pada akhirnya tidak terautentikasi ke aplikasi di belakangnya. Pemeriksaan TLS bisa saja sepenuhnya benar. Celah muncul ketika reverse proxy mengakhiri koneksi TLS tersebut lalu membuka koneksi lain menuju backend. Mutual TLS mengautentikasi endpoint pada koneksi TLS tertentu. Ia tidak otomatis menempelkan identitas client yang sudah diautentikasi ke request HTTP setelah koneksi itu berakhir, dan koneksi TLS kedua tidak otomatis mewarisi peer dari koneksi pertama. Begitu proxy menjadi TLS server bagi client eksternal, proxy-lah komponen yang memiliki hasil verifikasi sertifikat client. Identitas backend yang diturunkan dari hasil tersebut harus melewati batas kepercayaan baru.

Keamanan Siber TLS

Keamanan Siber / 17 Sep 2026 / 5 min read

Encrypted ClientHello Memisahkan Routing Publik dari Identitas TLS Privat

Encrypted ClientHello Memisahkan Routing Publik dari Identitas TLS Privat TLS 1.3 mengenkripsi sebagian besar pesan handshake, tetapi koneksi biasa tetap memperlihatkan ClientHello awal. Pesan ini dapat memuat Server Name Indication, sehingga pengamat di jalur jaringan dapat mengaitkan koneksi dengan hostname yang diminta sebelum trafik aplikasi terlindungi. Encrypted ClientHello, yang distandardisasi dalam RFC 9849, mengubah batas tersebut. Client membuat ClientHelloInner privat berisi parameter khusus layanan, lalu membungkusnya di dalam ClientHelloOuter publik. Pesan outer tetap dapat dipakai infrastruktur yang menghadap client, sementara field sensitif di dalamnya dilindungi dengan Hybrid Public Key Encryption.

Cybersecurity TLS

Keamanan Siber / 17 Sep 2026 / 6 min read

Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik

Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik Certificate authority yang dipercaya publik dapat menerbitkan sertifikat yang secara sintaksis valid untuk sebuah domain meskipun penerbitan itu seharusnya tidak pernah terjadi. Validasi TLS path saja tidak dapat mengungkap kesalahan tersebut jika sertifikat berantai ke root tepercaya, cocok dengan nama yang diminta, masih dalam masa berlaku, dan memenuhi pemeriksaan kebijakan client lainnya. Certificate Transparency mengubah bukti yang tersedia di sekitar peristiwa itu. Alih-alih hanya mengandalkan catatan privat CA dan pengungkapan insiden di kemudian hari, ekosistem dapat mewajibkan penerbitan sertifikat meninggalkan bukti yang dapat diverifikasi secara kriptografis dalam log append-only publik. Log tidak memutuskan apakah sebuah sertifikat diotorisasi. Log membuat penerbitan dapat diamati dan membuat bentuk tertentu dari equivocation log dapat dideteksi.

Keamanan Siber TLS

Keamanan Siber / 16 Sep 2026 / 5 min read

TLS Early Data Menukar Latensi Handshake dengan Risiko Replay

TLS Early Data Menukar Latensi Handshake dengan Risiko Replay Client yang kembali dapat memiliki cukup state dari koneksi TLS 1.3 sebelumnya untuk mengirim application data bersama flight handshake pertamanya. Ini menghilangkan satu round trip dari critical path untuk traffic yang memenuhi syarat, tetapi juga mengubah properti keamanan yang sering dianggap implisit oleh aplikasi: encrypted transport tidak lagi berarti sebuah request hanya dapat muncul satu kali di seluruh koneksi. TLS 1.3 early data, yang umum disebut 0-RTT, dilindungi menggunakan key yang diturunkan dari pre-shared key yang terkait dengan session sebelumnya atau PSK yang disediakan secara eksternal. Server belum memberikan fresh handshake state ketika byte tersebut dikirim. Akibatnya, early data memiliki replay property yang lebih lemah daripada application data biasa yang dikirim setelah handshake.

Keamanan Siber TLS