<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>TLS on Nalar</title>
    <link>https://nalar.dev/id/tags/tls/</link>
    <description>Recent content in TLS on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/tls/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik</title>
      <link>https://nalar.dev/id/certificate-transparency-membuat-penerbitan-sertifikat-dapat-diaudit-secara-publik/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/certificate-transparency-membuat-penerbitan-sertifikat-dapat-diaudit-secara-publik/</guid>
      <description>&lt;h1 id=&#34;certificate-transparency-membuat-penerbitan-sertifikat-dapat-diaudit-secara-publik&#34;&gt;Certificate Transparency Membuat Penerbitan Sertifikat Dapat Diaudit Secara Publik&lt;/h1&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Encrypted ClientHello Memisahkan Routing Publik dari Identitas TLS Privat</title>
      <link>https://nalar.dev/id/encrypted-clienthello-memisahkan-routing-publik-dari-identitas-tls-privat/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/encrypted-clienthello-memisahkan-routing-publik-dari-identitas-tls-privat/</guid>
      <description>&lt;h1 id=&#34;encrypted-clienthello-memisahkan-routing-publik-dari-identitas-tls-privat&#34;&gt;Encrypted ClientHello Memisahkan Routing Publik dari Identitas TLS Privat&lt;/h1&gt;&#xA;&lt;p&gt;TLS 1.3 mengenkripsi sebagian besar pesan handshake, tetapi koneksi biasa tetap memperlihatkan &lt;code&gt;ClientHello&lt;/code&gt; awal. Pesan ini dapat memuat Server Name Indication, sehingga pengamat di jalur jaringan dapat mengaitkan koneksi dengan hostname yang diminta sebelum trafik aplikasi terlindungi.&lt;/p&gt;&#xA;&lt;p&gt;Encrypted ClientHello, yang distandardisasi dalam RFC 9849, mengubah batas tersebut. Client membuat &lt;code&gt;ClientHelloInner&lt;/code&gt; privat berisi parameter khusus layanan, lalu membungkusnya di dalam &lt;code&gt;ClientHelloOuter&lt;/code&gt; publik. Pesan outer tetap dapat dipakai infrastruktur yang menghadap client, sementara field sensitif di dalamnya dilindungi dengan Hybrid Public Key Encryption.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Identitas Mutual TLS Dapat Hilang di Terminating Proxy</title>
      <link>https://nalar.dev/id/identitas-mutual-tls-dapat-hilang-di-terminating-proxy/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/identitas-mutual-tls-dapat-hilang-di-terminating-proxy/</guid>
      <description>&lt;h1 id=&#34;identitas-mutual-tls-dapat-hilang-di-terminating-proxy&#34;&gt;Identitas Mutual TLS Dapat Hilang di Terminating Proxy&lt;/h1&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake</title>
      <link>https://nalar.dev/id/tls-must-staple-mengubah-ocsp-yang-hilang-menjadi-kegagalan-handshake/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/tls-must-staple-mengubah-ocsp-yang-hilang-menjadi-kegagalan-handshake/</guid>
      <description>&lt;h1 id=&#34;tls-must-staple-mengubah-ocsp-yang-hilang-menjadi-kegagalan-handshake&#34;&gt;TLS Must-Staple Mengubah OCSP yang Hilang Menjadi Kegagalan Handshake&lt;/h1&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
