<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Replay Attacks on Nalar</title>
    <link>https://nalar.dev/tags/replay-attacks/</link>
    <description>Recent content in Replay Attacks on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 15 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/replay-attacks/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>TLS 1.3 Early Data Trades a Round Trip for Replay Exposure</title>
      <link>https://nalar.dev/tls-1-3-early-data-trades-a-round-trip-for-replay-exposure/</link>
      <pubDate>Tue, 15 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/tls-1-3-early-data-trades-a-round-trip-for-replay-exposure/</guid>
      <description>&lt;h1 id=&#34;tls-13-early-data-trades-a-round-trip-for-replay-exposure&#34;&gt;TLS 1.3 Early Data Trades a Round Trip for Replay Exposure&lt;/h1&gt;&#xA;&lt;p&gt;A resumed TLS 1.3 connection can carry application bytes before the server has completed the new handshake. That latency reduction is attractive on paths where a round trip is expensive, but it changes a security property that applications often assume without naming it: a protected request is not necessarily fresh merely because the server decrypted it successfully.&lt;/p&gt;&#xA;&lt;p&gt;TLS 1.3 calls this facility early data, commonly described as 0-RTT. It is available when the client and server share a pre-shared key, including one established through a prior connection. The client can derive keys and send application data in its first flight rather than waiting for the server&amp;rsquo;s handshake messages.&lt;/p&gt;</description>
    </item>
    <item>
      <title>TLS Early Data Trades Latency for Replay Risk</title>
      <link>https://nalar.dev/tls-early-data-trades-latency-for-replay-risk/</link>
      <pubDate>Mon, 14 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/tls-early-data-trades-latency-for-replay-risk/</guid>
      <description>&lt;p&gt;A client reconnects to a service it visited recently and sends an HTTP request before the new TLS handshake has finished. The request can reach application processing sooner than traffic sent after handshake completion. That small latency gain is attractive at scale, but it changes a property applications often take for granted: a protected request is not automatically a fresh request.&lt;/p&gt;&#xA;&lt;p&gt;TLS 1.3 calls this feature early data, commonly described as 0-RTT data. It is available only in suitable resumed sessions, not on an initial connection with no prior session state. The client uses information associated with a previous connection to protect data sent immediately. The server can accept that data before the new handshake completes.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
