A simple blog made with Zola and Duckquill Zola 2026-07-10T00:00:00+00:00 https://cetanu.github.io/tags/security/atom.xml 2026-07-10T00:00:00+00:00 2026-07-10T00:00:00+00:00 Vasilios Syrakis https://cetanu.github.io/blog/do-we-really-need-tls-for-cat-pictures/ <p>It is a common piece of skepticism: <em>"Is encrypting every single corner of the web actually necessary? If I’m just reading a static blog post or looking at a cute picture of a cat, there are no passwords or credit cards involved. Why do we need to wrap all of that in TLS? Aren’t we just wasting a massive amount of CPU cycles globally?"</em></p> <p>On the surface, it seems like a reasonable complaint. Wrapping every HTTP response in a layer of cryptography must have a cost.</p> <p>But when you dig into the mechanics of modern networks and the history of how ISPs behave when we leave our traffic in plaintext, the answer becomes obvious. Ubiquitous TLS isn’t paranoia or wasteful bloat—it is the bare minimum required to keep the web functional.</p> <p>Let’s break down the actual compute cost of TLS and look at what happens to your data when you don’t encrypt it.</p> <hr /> <h2 id="the-compute-myth-is-tls-actually-wasting-cpu"><a class="zola-anchor" href="#the-compute-myth-is-tls-actually-wasting-cpu" aria-label="Anchor link for: the-compute-myth-is-tls-actually-wasting-cpu"><i class="icon"></i></a> The Compute Myth: Is TLS Actually Wasting CPU?</h2> <p>Historically, yes, SSL/TLS was computationally expensive. In the 1990s and early 2000s, setting up a secure connection and encrypting a stream of data was a heavy burden for servers. Websites that wanted encryption often had to buy dedicated, expensive SSL accelerator expansion cards to offload the cryptographic math from the main CPU.</p> <p>Today, that bottleneck is long gone.</p> <h3 id="1-hardware-accelerated-cryptography-aes-ni-modern-cpus-both-client-side"><a class="zola-anchor" href="#1-hardware-accelerated-cryptography-aes-ni-modern-cpus-both-client-side" aria-label="Anchor link for: 1-hardware-accelerated-cryptography-aes-ni-modern-cpus-both-client-side"><i class="icon"></i></a> 1. Hardware-Accelerated Cryptography (AES-NI) Modern CPUs (both client-side</h3> <p>and server-side) have dedicated hardware instructions built directly into the silicon to handle symmetric encryption. The most famous of these is Intel and AMD’s <strong>AES-NI</strong> (Advanced Encryption Standard New Instructions).</p> <p>With AES-NI, the CPU doesn’t need to run a software loop to encrypt data block-by-block. Instead, it offloads it to hardware execution units that run the operations in a handful of clock cycles.</p> <p>Because of this, modern processors can encrypt and decrypt AES-GCM (the primary cipher suite used in TLS 1.3) at near-memory speeds. A single modern CPU core can easily encrypt multiple gigabits of data per second. On a typical web server, the CPU overhead of encrypting the payload is a fraction of a percent.</p> <h3 id="2-tls-1-3-handshake-optimizations-the-most-computationally-intensive-part"><a class="zola-anchor" href="#2-tls-1-3-handshake-optimizations-the-most-computationally-intensive-part" aria-label="Anchor link for: 2-tls-1-3-handshake-optimizations-the-most-computationally-intensive-part"><i class="icon"></i></a> 2. TLS 1.3 Handshake Optimizations The most computationally intensive part</h3> <p>of TLS isn’t actually encrypting the data stream (symmetric cryptography)—it is the initial handshake where the client and server negotiate keys (asymmetric cryptography).</p> <p>TLS 1.3, finalized in 2018, radically streamlined this process:</p> <ul> <li><strong>One Round-Trip (1-RTT):</strong> The handshake was cut from two round-trips to one, reducing latency.</li> <li><strong>Pre-Shared Key (PSK) Session Resumption:</strong> Returning visitors can resume a session in zero round-trips (0-RTT), skipping the expensive asymmetric key generation entirely.</li> <li><strong>Faster Algorithms:</strong> Modern deployments favor elliptic curve algorithms like <code>X25519</code> for key exchange and <code>ECDSA</code> or <code>Ed25519</code> for signatures. These are orders of magnitude faster and lighter than the classic, bulky RSA keys of the past.</li> </ul> <p>If you profile a modern web application, the resources spent on TLS are a drop in the bucket. Parsing a JSON payload, running a database query, rendering a React component, or executing a snippet of JavaScript takes orders of magnitude more CPU cycles than encrypting a packet.</p> <hr /> <h2 id="if-the-compute-cost-is-low-why-encrypt-cat-pictures"><a class="zola-anchor" href="#if-the-compute-cost-is-low-why-encrypt-cat-pictures" aria-label="Anchor link for: if-the-compute-cost-is-low-why-encrypt-cat-pictures"><i class="icon"></i></a> If the Compute Cost is Low, Why Encrypt Cat Pictures?</h2> <p>If the computational cost is negligible, we still have to ask: what is the point of encrypting non-sensitive content? If someone intercepts your request to see a cat picture, they just see a cat picture. Who cares?</p> <p>The issue isn’t just <strong>confidentiality</strong> (keeping secrets secret). The real threat is <strong>integrity</strong> (making sure the data isn’t tampered with).</p> <p>Without TLS, your connection is just plain HTTP. That means every router, switch, and intermediate network node between your browser and the web server can read your traffic—and more importantly, they can <strong>modify</strong> it.</p> <p>This isn’t a theoretical threat. Throughout the 2010s, Internet Service Providers (ISPs), public Wi-Fi operators, and network gateways repeatedly behaved like active man-in-the-middle attackers to monetize and track plaintext web traffic.</p> <p>Here are a few of the most egregious examples of what ISPs did when they were allowed to read plaintext streams.</p> <hr /> <h2 id="when-isps-act-like-malicious-actors"><a class="zola-anchor" href="#when-isps-act-like-malicious-actors" aria-label="Anchor link for: when-isps-act-like-malicious-actors"><i class="icon"></i></a> When ISPs Act Like Malicious Actors</h2> <h3 id="1-verizon-s-supercookie-uidh"><a class="zola-anchor" href="#1-verizon-s-supercookie-uidh" aria-label="Anchor link for: 1-verizon-s-supercookie-uidh"><i class="icon"></i></a> 1. Verizon’s “Supercookie” (UIDH)</h3> <p>From 2012 to 2016, Verizon Wireless silently injected a unique tracking header called the <strong>UIDH</strong> (Unique Identifier Header) into every unencrypted HTTP request sent by its mobile users.</p> <pre class="giallo" style="color: #A9B1D6; background-color: #1A1B26;"><code data-lang="http"><span class="giallo-l"><span style="color: #BB9AF7;">GET</span><span> /cat-pictures</span><span style="color: #89DDFF;"> HTTP</span><span>/</span><span style="color: #FF9E64;">1.1</span></span> <span class="giallo-l"><span style="color: #F7768E;">Host</span><span style="color: #89DDFF;">:</span><span style="color: #9ECE6A;"> example.com</span></span> <span class="giallo-l"><span style="color: #F7768E;">X-UIDH</span><span style="color: #89DDFF;">:</span><span style="color: #9ECE6A;"> 9f8a3c2e1b0d7f... &lt;-- Injected by Verizon&#39;s network</span></span></code></pre> <p>Because HTTP traffic was plaintext, Verizon’s network equipment could intercept the packets in transit, append this custom header, and forward it to the destination server.</p> <p>This header acted as an undeletable tracking cookie. Even if users cleared their browser cookies, blocked trackers, or used incognito mode, third-party advertising networks (like Turn) could read this injected <code>X-UIDH</code> header and use it to reconstruct the user’s tracking profile across the web.</p> <p>Because it was done at the network level, users had no way to disable it. It was only stopped after a security researcher exposed the practice, leading to public outcry and a <strong>$1.35 million fine</strong> from the FCC in 2016. If the sites had been using HTTPS, Verizon would not have been able to inject the header without breaking the cryptographic signature of the packet.</p> <h3 id="2-comcast-s-javascript-injection-in-2017-comcast-users-began-noticing"><a class="zola-anchor" href="#2-comcast-s-javascript-injection-in-2017-comcast-users-began-noticing" aria-label="Anchor link for: 2-comcast-s-javascript-injection-in-2017-comcast-users-began-noticing"><i class="icon"></i></a> 2. Comcast’s JavaScript Injection In 2017, Comcast users began noticing</h3> <p>strange popups appearing on top of the websites they were browsing.</p> <p>Comcast was using deep packet inspection (DPI) to monitor customer traffic. When they detected a user was browsing an unencrypted HTTP site, they would modify the HTML on the fly, injecting custom JavaScript code into the webpage before it reached the user’s browser.</p> <p>The injected code was used to display “courtesy notices” telling users they were approaching their monthly data cap, or warning them that their modem was out of date.</p> <p>While Comcast claimed this was a feature to help consumers, injecting arbitrary JavaScript into third-party websites is incredibly dangerous. It can break the site’s layout, cause conflicts with the site’s own scripts, and introduce major security vulnerabilities. If a hacker managed to compromise Comcast’s injection system, they could have executed arbitrary code on millions of customer browsers.</p> <h3 id="3-hotel-and-airport-wi-fi-ad-injection-if-you-ve-ever-connected-to-a-hotel"><a class="zola-anchor" href="#3-hotel-and-airport-wi-fi-ad-injection-if-you-ve-ever-connected-to-a-hotel" aria-label="Anchor link for: 3-hotel-and-airport-wi-fi-ad-injection-if-you-ve-ever-connected-to-a-hotel"><i class="icon"></i></a> 3. Hotel and Airport Wi-Fi Ad Injection If you’ve ever connected to a hotel</h3> <p>or airport Wi-Fi network and seen a strange floating toolbar at the bottom of every page, or unexpected ads on sites that don’t usually host them, you’ve experienced ad injection.</p> <p>Public Wi-Fi gateways frequently intercept HTTP traffic to inject local advertisements, promotions, or terms-of-service agreements. By rewriting the HTML of the websites you visit, they degrade your browsing experience and can expose your browser to malicious ads (malvertising).</p> <h3 id="4-dns-hijacking-and-search-redirection-many-isps-including-charter-cox"><a class="zola-anchor" href="#4-dns-hijacking-and-search-redirection-many-isps-including-charter-cox" aria-label="Anchor link for: 4-dns-hijacking-and-search-redirection-many-isps-including-charter-cox"><i class="icon"></i></a> 4. DNS Hijacking and Search Redirection Many ISPs (including Charter, Cox,</h3> <p>and Rogers) historically practiced DNS hijacking on unencrypted traffic. If you typed in a non-existent URL (like <code>http://this-does-not-exist.com</code>), instead of showing a browser error page, the ISP would intercept the request and redirect you to a custom search page loaded with ads and sponsored links, monetizing your typos.</p> <hr /> <h2 id="the-three-pillars-of-tls"><a class="zola-anchor" href="#the-three-pillars-of-tls" aria-label="Anchor link for: the-three-pillars-of-tls"><i class="icon"></i></a> The Three Pillars of TLS</h2> <p>When we encrypt the web, we aren’t just hiding passwords. We are establishing three fundamental guarantees:</p> <table><thead><tr><th style="text-align: left">Guarantee</th><th style="text-align: left">What It Means</th><th style="text-align: left">What Happens Without It</th></tr></thead><tbody> <tr><td style="text-align: left"><strong>Confidentiality</strong></td><td style="text-align: left">Only you and the server can read the data.</td><td style="text-align: left">ISPs, governments, or hackers on your local Wi-Fi can see exactly which pages, articles, and pictures you are viewing.</td></tr> <tr><td style="text-align: left"><strong>Integrity</strong></td><td style="text-align: left">The data cannot be modified in transit.</td><td style="text-align: left">Network middleboxes can inject ads, tracking headers, popups, or malicious scripts into the page.</td></tr> <tr><td style="text-align: left"><strong>Authenticity</strong></td><td style="text-align: left">You are communicating with the real website.</td><td style="text-align: left">An attacker can spoof the website’s identity (e.g., DNS poisoning) and serve you a fake page without your browser raising any warnings.</td></tr> </tbody></table> <p>Even if you are only looking at cat pictures, you deserve to know that the cat pictures you are seeing are the actual ones sent by the server, and not a modified payload injected with tracking scripts and banner ads.</p> <h2 id="conclusion"><a class="zola-anchor" href="#conclusion" aria-label="Anchor link for: conclusion"><i class="icon"></i></a> Conclusion</h2> <p>The push for a 100% encrypted web—championed by projects like <em>Let’s Encrypt</em>, search engines prioritizing HTTPS, and browsers displaying warnings for insecure sites—was a necessary response to the reality of the internet’s infrastructure.</p> <p>The internet is not a direct wire between your computer and a server; it is a chain of intermediaries. And history has proven that if those intermediaries are given the power to read and modify your traffic, they will exploit it for profit.</p> <p>Thanks to modern hardware acceleration like AES-NI and the design of TLS 1.3, we can secure the entire web with virtually zero performance penalty. Encrypted cat pictures aren’t a waste of compute—they are a victory for user privacy and web integrity.</p>