<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Dlp on mishraJi</title>
    <link>https://blog.mishraji.org/tags/dlp/</link>
    <description>Recent content in Dlp on mishraJi</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 09 Mar 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.mishraji.org/tags/dlp/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Part 2: Cloudflare Zero Trust - TLS Inspection</title>
      <link>https://blog.mishraji.org/posts/cloudflare-ztna-part-2/</link>
      <pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.mishraji.org/posts/cloudflare-ztna-part-2/</guid>
      <description>&lt;p&gt;In &lt;a href=&#34;https://blog.mishraji.org/posts/cloudflare-ztna-part-1/&#34;&gt;Part 1&lt;/a&gt;, we enabled TLS inspection to get HTTP policies working against HTTPS traffic — that&amp;rsquo;s how we blocked social media sites on port 443. We got it working, but I didn&amp;rsquo;t really explain &lt;em&gt;what&lt;/em&gt; TLS inspection is actually doing under the hood. Let&amp;rsquo;s fix that.&lt;/p&gt;&#xA;&lt;p&gt;TLS inspection is essentially a man-in-the-middle. When your device initiates an HTTPS connection, Cloudflare Gateway intercepts it, terminates the TLS session, decrypts the traffic, inspects it, and re-encrypts before forwarding to the destination. Same thing in reverse on the way back. The Cloudflare root CA certificate we installed on the client device is what makes this work without your browser throwing certificate errors on every page.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
