<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cybersecurity on Nalar</title>
    <link>https://nalar.dev/id/tags/cybersecurity/</link>
    <description>Recent content in Cybersecurity 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/cybersecurity/index.xml" rel="self" type="application/rss+xml" />
    <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>HTTP Request Smuggling Berawal dari Perbedaan Framing Pesan</title>
      <link>https://nalar.dev/id/http-request-smuggling-berawal-dari-perbedaan-framing-pesan/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/http-request-smuggling-berawal-dari-perbedaan-framing-pesan/</guid>
      <description>&lt;h1 id=&#34;http-request-smuggling-berawal-dari-perbedaan-framing-pesan&#34;&gt;HTTP Request Smuggling Berawal dari Perbedaan Framing Pesan&lt;/h1&gt;&#xA;&lt;p&gt;Reverse proxy dapat memvalidasi request HTTP, meneruskannya ke aplikasi yang diizinkan, tetapi tetap mengirim urutan request yang berbeda dari yang dianggapnya telah diterima. Kegagalan ini tidak mengharuskan proxy mengabaikan autentikasi atau origin menjalankan sintaks yang rusak. Masalah dapat muncul ketika dua pemroses HTTP berbeda pendapat tentang byte yang menandai akhir satu request dan awal request berikutnya.&lt;/p&gt;&#xA;&lt;p&gt;Perbedaan itulah batas keamanan utama pada HTTP request smuggling. Front end membaca stream dengan satu interpretasi framing, sedangkan penerima downstream membaca stream yang diteruskan dengan interpretasi lain. Byte yang dianggap body oleh satu komponen dapat dianggap awal request baru oleh komponen lain. Pada koneksi persisten, interpretasi kedua dapat memengaruhi trafik yang datang kemudian pada channel downstream yang sama.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
