<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Transport Security on Nalar</title>
    <link>https://nalar.dev/tags/transport-security/</link>
    <description>Recent content in Transport Security on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/transport-security/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Keep TLS Certificate Verification Enabled</title>
      <link>https://nalar.dev/keep-tls-certificate-verification-enabled/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/keep-tls-certificate-verification-enabled/</guid>
      <description>&lt;p&gt;An HTTPS client does more than encrypt bytes. During the TLS handshake, it also checks evidence about the server&amp;rsquo;s identity. If application code disables those checks, the connection can remain encrypted while being connected to an unintended endpoint.&lt;/p&gt;&#xA;&lt;p&gt;That distinction is central to secure TLS use. Encryption protects data against passive observation, but authenticated encryption to the wrong peer does not establish the identity the application intended to contact.&lt;/p&gt;&#xA;&lt;p&gt;The practical rule is: &lt;strong&gt;keep certificate-chain and hostname verification enabled, and repair trust configuration instead of bypassing verification&lt;/strong&gt;.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
