Langsung ke konten

Arsip

TLS

51 artikel
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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Keamanan Siber 23 Sep 2026 5 min read

MTA-STS Mewajibkan TLS Terautentikasi untuk Pengiriman SMTP

MTA-STS Mewajibkan TLS Terautentikasi untuk Pengiriman SMTP SMTP STARTTLS dapat mengenkripsi transport email, tetapi TLS oportunistik biasa mengizinkan pengiriman berlanjut saat enkripsi tidak tersedia. Perilaku kompatibilitas tersebut membuka ruang bagi perantara aktif untuk menekan STARTTLS atau mengalihkan pengiriman menuju server yang tidak semestinya. SMTP MTA Strict Transport Security, yang ditetapkan dalam RFC 8461, memberi domain penerima kanal kebijakan untuk MTA pengirim yang kompatibel. Kebijakan itu menetapkan host MX yang dapat diterima dan apakah pengiriman harus memakai TLS dengan sertifikat PKIX yang valid. Dalam mode enforce, pengirim tidak melakukan downgrade secara diam-diam ketika pemeriksaan tersebut gagal.

Keamanan Siber 23 Sep 2026 6 min read

HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya

HTTP Strict Transport Security Mengunci HTTPS untuk Kunjungan Berikutnya TLS melindungi koneksi HTTP setelah klien memakai HTTPS. Pengguna yang mengetik hostname tanpa skema, mengikuti tautan lama http://, atau membuka endpoint HTTP yang melakukan redirect masih dapat memulai sesi dengan request tanpa enkripsi. HTTP Strict Transport Security (HSTS) memberi browser yang mendukungnya aturan persisten untuk host tersebut. Setelah menerima header Strict-Transport-Security yang valid melalui HTTPS, browser menyimpan kebijakan itu dan mengubah navigasi HTTP berikutnya menjadi HTTPS selama kebijakan masih aktif.

Keamanan Siber 23 Sep 2026 4 min read

DANE untuk SMTP Mengikat Autentikasi TLS ke DNSSEC

SMTP umumnya memulai koneksi dalam plaintext lalu meningkatkannya dengan STARTTLS. Opportunistic TLS meningkatkan kerahasiaan ketika kedua sisi mendukungnya, tetapi upgrade tanpa autentikasi dapat ditekan atau dialihkan oleh penyerang aktif di jaringan. DANE untuk SMTP, yang ditetapkan dalam RFC 7672, menambahkan jalur autentikasi yang berakar pada DNSSEC. MTA pengirim tidak menganggap setiap respons TLSA sebagai otoritatif. Pengirim terlebih dahulu memerlukan hasil DNSSEC-secure untuk data tujuan yang mengarahkan pengiriman. Ketika record TLSA yang dapat digunakan diperoleh secara aman untuk host MX terpilih, record tersebut membatasi kredensial server TLS yang dapat diterima pengirim.

Keamanan Siber 23 Sep 2026 4 min read

DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC

DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC TLS biasanya mengautentikasi server melalui aturan validasi sertifikat yang ditetapkan aplikasi dan trust model-nya. DANE menambahkan binding berbasis DNS: resource record TLSA mengasosiasikan endpoint layanan dengan material sertifikat atau public key, sedangkan DNSSEC menyediakan data DNS terautentikasi untuk asosiasi tersebut. Batasnya tegas. RRset TLSA yang berstatus insecure atau memiliki status DNSSEC indeterminate tidak dapat menjadi asosiasi DANE terautentikasi. Karena itu, DANE bergantung pada validasi DNSSEC dan tidak menganggap transport DNS biasa sebagai bukti yang memadai.

Keamanan Siber 22 Sep 2026 6 min read

Record CAA Membatasi Otoritas Penerbit Sertifikat

Record CAA Membatasi Otoritas Penerbit Sertifikat Certificate authority dapat memvalidasi kontrol atas sebuah domain dan tetap menghadapi pertanyaan kebijakan yang terpisah: apakah CA tersebut diizinkan oleh operator domain untuk menerbitkan sertifikat bagi nama itu? Certification Authority Authorization, atau CAA, menyediakan tipe record DNS untuk menyatakan batas tersebut. CAA bekerja sebelum penerbitan sertifikat. CA publik yang berpartisipasi memeriksa kebijakan DNS CAA yang berlaku dan mengevaluasi apakah identitas issuer miliknya diizinkan. Mekanisme ini tidak membuat sertifikat menjadi tepercaya, mencabut sertifikat yang sudah ada, atau memerintahkan browser menolak sertifikat setelah diterbitkan. CAA mempersempit kumpulan issuer yang semestinya membuat sertifikat baru untuk domain tersebut.

Keamanan Siber 22 Sep 2026 6 min read

OCSP Stapling Membawa Status Sertifikat dalam TLS Handshake

OCSP Stapling Membawa Status Sertifikat dalam TLS Handshake Validasi sertifikat mencakup dua persoalan yang berbeda. Client perlu memastikan bahwa sertifikat membentuk chain ke authority yang dipercaya dan valid untuk identitas yang dituju, tetapi client juga dapat memerlukan bukti terkini bahwa sertifikat belum dicabut sebelum masa berlakunya berakhir. Online Certificate Status Protocol, atau OCSP, menyediakan response status bertanda tangan untuk sertifikat. Client dapat menghubungi OCSP responder secara langsung, tetapi langkah itu menambah dependency jaringan saat koneksi dibentuk dan dapat mengungkap sertifikat yang sedang diperiksa kepada responder. OCSP stapling memindahkan response yang sudah di-cache ke pertukaran TLS: server mengambil bukti status lalu menyajikannya kepada client yang memintanya.

Keamanan Siber 22 Sep 2026 5 min read

HSTS Mengikat Kebijakan HTTPS ke Hostname

HSTS Mengikat Kebijakan HTTPS ke Hostname HTTPS melindungi pertukaran HTTP setelah koneksi aman terbentuk dan terautentikasi. Ada persoalan terpisah sebelum titik itu: pengguna dapat mengetik hostname tanpa skema, mengikuti link http://, atau mencapai endpoint HTTP yang melakukan redirect sebelum browser memiliki kebijakan transport untuk situs tersebut. HTTP Strict Transport Security (HSTS) menangani transisi itu. Server HTTPS mengirim header response Strict-Transport-Security, lalu user agent yang sesuai menyimpan kebijakan untuk host tersebut. Selama kebijakan masih aktif, request HTTP yang cocok diubah menjadi HTTPS sebelum request tanpa enkripsi dikirim ke jaringan.

Keamanan Siber 22 Sep 2026 5 min read

DNS CAA Membatasi Otoritas Penerbit Sertifikat

DNS CAA Membatasi Otoritas Penerbit Sertifikat Penerbitan sertifikat publik bergantung pada certificate authority yang memvalidasi kontrol atas nama domain yang diminta. DNS Certification Authority Authorization (CAA) menambahkan sinyal kebijakan terpisah: domain dapat menyatakan certificate authority mana yang diizinkan menerbitkan sertifikat untuk nama tersebut. CAA tidak menggantikan validasi kontrol domain, tidak membuktikan bahwa pemohon sah, dan tidak melindungi private key. Perannya lebih sempit. Certificate authority publik yang mematuhi standar memeriksa kebijakan CAA yang berlaku sebelum penerbitan dan tidak boleh menerbitkan ketika kebijakan tersebut melarangnya.

Keamanan Siber 22 Sep 2026 5 min read

Certificate Transparency Membuka Penerbitan Sertifikat untuk Audit Publik

Certificate Transparency Membuka Penerbitan Sertifikat untuk Audit Publik Sertifikat TLS yang dipercaya publik merupakan pernyataan dari certificate authority. PKI tradisional memberi klien cara untuk memvalidasi pernyataan tersebut terhadap root tepercaya, tetapi keberhasilan validasi path saja tidak membuat penerbitan sertifikat terlihat secara publik. Certificate Transparency, yang umum disingkat CT, menambahkan lapisan audit. Log yang berpartisipasi menerima entri sertifikat dan memasukkannya ke struktur data append-only. Bukti yang dihasilkan memungkinkan klien, operator domain, dan monitor mendeteksi sertifikat yang telah masuk ke Web PKI publik, termasuk sertifikat yang tidak diperkirakan ada oleh operator.