<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="https://www.getpagespeed.com/wp-content/plugins/seriously-simple-podcasting/templates/feed-stylesheet.xsl?v=2"?><rss version="2.0"
	 xmlns:content="http://purl.org/rss/1.0/modules/content/"
	 xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	 xmlns:dc="http://purl.org/dc/elements/1.1/"
	 xmlns:atom="http://www.w3.org/2005/Atom"
	 xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	 xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	 xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	 xmlns:googleplay="http://www.google.com/schemas/play-podcasts/1.0"
	 xmlns:podcast="https://podcastindex.org/namespace/1.0"
	 xmlns:ssp="https://castos.com/seriously-simple-podcasting/namespace/1.0"
	>
		<channel>
		<title>Scalable Stories</title>
		<atom:link href="https://www.getpagespeed.com/feed/podcast/scalable-stories/" rel="self" type="application/rss+xml"/>
		<link>https://www.getpagespeed.com/podcasts/scalable-stories</link>
		<description>Welcome to Scalable Stories—the podcast where our hosts explore the nuances of web performance, security, and scalable infrastructures. Learn how to optimize your servers with tools like NGINX modules by GetPageSpeed, Varnish Cache, and leverage platforms like RHEL and Rocky Linux for robust deployments.

Each episode offers insights into enhancing server efficiency, speeding up websites, and fortifying against security threats. Whether you’re a developer, sysadmin, or tech enthusiast, join us to unlock the secrets of scalable and secure web architectures.</description>
		<lastBuildDate>Sun, 20 Sep 2026 21:55:04 +0000</lastBuildDate>
		<language>en-US</language>
		<copyright>© 2024 GetPageSpeed LLC</copyright>
		<itunes:subtitle>Mastering Web Performance and Security</itunes:subtitle>
		<itunes:author>GetPageSpeed</itunes:author>
		<itunes:type>episodic</itunes:type>
		<itunes:summary>Welcome to Scalable Stories—the podcast where our hosts explore the nuances of web performance, security, and scalable infrastructures. Learn how to optimize your servers with tools like NGINX modules by GetPageSpeed, Varnish Cache, and leverage platforms like RHEL and Rocky Linux for robust deployments.

Each episode offers insights into enhancing server efficiency, speeding up websites, and fortifying against security threats. Whether you’re a developer, sysadmin, or tech enthusiast, join us to unlock the secrets of scalable and secure web architectures.</itunes:summary>
		<itunes:owner>
			<itunes:name>GetPageSpeed</itunes:name>
		</itunes:owner>
		<itunes:explicit>false</itunes:explicit>
		<itunes:image href="https://www.getpagespeed.com/wp-content/uploads/2014/07/scalable-stories-cover-scaled.jpg"></itunes:image>
			<image>
				<url>https://www.getpagespeed.com/wp-content/uploads/2014/07/scalable-stories-cover-scaled.jpg</url>
				<title>Scalable Stories</title>
				<link>https://www.getpagespeed.com/podcasts/scalable-stories</link>
			</image>
		<itunes:category text="Technology">
		</itunes:category>
		<googleplay:author><![CDATA[GetPageSpeed]]></googleplay:author>
						<googleplay:description>Welcome to Scalable Stories—the podcast where our hosts explore the nuances of web performance, security, and scalable infrastructures. Learn how to optimize your servers with tools like NGINX modules by GetPageSpeed, Varnish Cache, and leverage platforms like RHEL and Rocky Linux for robust deployments.

Each episode offers insights into enhancing server efficiency, speeding up websites, and fortifying against security threats. Whether you’re a developer, sysadmin, or tech enthusiast, join us to unlock the secrets of scalable and secure web architectures.</googleplay:description>
			<googleplay:explicit>No</googleplay:explicit>
			<googleplay:image href="https://www.getpagespeed.com/wp-content/uploads/2014/07/scalable-stories-cover-scaled.jpg"></googleplay:image>
			<podcast:locked>yes</podcast:locked>
		<podcast:funding url="https://github.com/sponsors/GetPageSpeed">Donate to the show</podcast:funding>
		<podcast:guid>77f42753-75ee-5503-9c62-e1dd03e62708</podcast:guid>
		
		<!-- podcast_generator="SSP by Castos/3.17.0" Seriously Simple Podcasting plugin for WordPress (https://wordpress.org/plugins/seriously-simple-podcasting/) -->
		<generator>https://wordpress.org/?v=7.1</generator>
<site xmlns="com-wordpress:feed-additions:1">74128791</site>
<item>
	<title>NGINX Post-Quantum TLS: X25519MLKEM768 with OpenSSL 3.5</title>
	<link>https://www.getpagespeed.com/podcast/nginx-post-quantum-cryptography-audio</link>
	<pubDate>Sun, 20 Sep 2026 21:55:04 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=124569</guid>
	<description><![CDATA[Technical Briefing: NGINX Post-Quantum TLS — X25519MLKEM768 with OpenSSL 3.5 The Problem: Harvest Now, Decrypt Later The threat model is not a quantum computer breaking TLS today — it is an attacker recording encrypted traffic now and decrypting it once a cryptographically relevant quantum computer exists. Session cookies expire in hours, but health records, contracts, source trees, and private keys remain sensitive for a decade or more. The precise vulnerability matters: Shor's algorithm break…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: NGINX Post-Quantum TLS — X25519MLKEM768 with OpenSSL 3.5 The Problem: Harvest Now, Decrypt Later The threat model is not a quantum computer breaking TLS today — it is an attacker recording encrypted traffic now and decrypting it once ]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX Post-Quantum TLS: X25519MLKEM768 with OpenSSL 3.5]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: NGINX Post-Quantum TLS — X25519MLKEM768 with OpenSSL 3.5 The Problem: Harvest Now, Decrypt Later The threat model is not a quantum computer breaking TLS today — it is an attacker recording encrypted traffic now and decrypting it once a cryptographically relevant quantum computer exists. Session cookies expire in hours, but health records, contracts, source trees, and private keys remain sensitive for a decade or more. The precise vulnerability matters: Shor's algorithm break…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-post-quantum-cryptography-audio.m4a" length="14702413" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: NGINX Post-Quantum TLS — X25519MLKEM768 with OpenSSL 3.5 The Problem: Harvest Now, Decrypt Later The threat model is not a quantum computer breaking TLS today — it is an attacker recording encrypted traffic now and decrypting it once a cryptographically relevant quantum computer exists. Session cookies expire in hours, but health records, contracts, source trees, and private keys remain sensitive for a decade or more. The precise vulnerability matters: Shor's algorithm break…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:19:28</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: NGINX Post-Quantum TLS — X25519MLKEM768 with OpenSSL 3.5 The Problem: Harvest Now, Decrypt Later The threat model is not a quantum computer breaking TLS today — it is an attacker recording encrypted traffic now and decrypting it once a cryptographically relevant quantum computer exists. Session cookies expire in hours, but health records, contracts, source trees, and private keys remain sensitive for a decade or more. The precise vulnerability matters: Shor's algorithm break…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>Parallel ESI for Varnish 6.0 LTS: vmod-pesi Now Packaged</title>
	<link>https://www.getpagespeed.com/podcast/varnish-parallel-esi-audio</link>
	<pubDate>Sat, 19 Sep 2026 22:03:25 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=124465</guid>
	<description><![CDATA[Technical Briefing: Parallel ESI for Varnish 6.0 LTS via vmod-pesi The Problem: Sequential ESI Fragment Assembly Stock open-source Varnish processes ESI includes sequentially. A page containing two uncached fragments that each take 2 seconds to render therefore takes over 4 seconds to assemble — the total is the sum of fragment latencies, not the maximum. This is a structural limitation of the open-source daemon, not a configuration issue. The Implementation: A Backport of libvdp-pesi GetPageSp…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Parallel ESI for Varnish 6.0 LTS via vmod-pesi The Problem: Sequential ESI Fragment Assembly Stock open-source Varnish processes ESI includes sequentially. A page containing two uncached fragments that each take 2 seconds to render th]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[Parallel ESI for Varnish 6.0 LTS: vmod-pesi Now Packaged]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Parallel ESI for Varnish 6.0 LTS via vmod-pesi The Problem: Sequential ESI Fragment Assembly Stock open-source Varnish processes ESI includes sequentially. A page containing two uncached fragments that each take 2 seconds to render therefore takes over 4 seconds to assemble — the total is the sum of fragment latencies, not the maximum. This is a structural limitation of the open-source daemon, not a configuration issue. The Implementation: A Backport of libvdp-pesi GetPageSp…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/varnish-parallel-esi-audio.m4a" length="7618517" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Parallel ESI for Varnish 6.0 LTS via vmod-pesi The Problem: Sequential ESI Fragment Assembly Stock open-source Varnish processes ESI includes sequentially. A page containing two uncached fragments that each take 2 seconds to render therefore takes over 4 seconds to assemble — the total is the sum of fragment latencies, not the maximum. This is a structural limitation of the open-source daemon, not a configuration issue. The Implementation: A Backport of libvdp-pesi GetPageSp…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:10:05</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Parallel ESI for Varnish 6.0 LTS via vmod-pesi The Problem: Sequential ESI Fragment Assembly Stock open-source Varnish processes ESI includes sequentially. A page containing two uncached fragments that each take 2 seconds to render therefore takes over 4 seconds to assemble — the total is the sum of fragment latencies, not the maximum. This is a structural limitation of the open-source daemon, not a configuration issue. The Implementation: A Backport of libvdp-pesi GetPageSp…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX QUIC reuseport: HTTP/3 Silently Breaks Without It</title>
	<link>https://www.getpagespeed.com/podcast/nginx-quic-reuseport-audio</link>
	<pubDate>Fri, 18 Sep 2026 22:36:40 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=124341</guid>
	<description><![CDATA[Technical Briefing: NGINX HTTP/3 reuseport, quicbpf, and SELinux The Problem: HTTP/3 Silently Fails Without reuseport With workerprocesses greater than 1, a QUIC listener configured without reuseport shares a single UDP socket across all workers. Because QUIC has no accept() step, every datagram arrives on that one socket, and whichever worker wakes first grabs it — even if it does not own that connection. The owning worker then receives mid-connection datagrams it cannot handle, producing H3RE…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: NGINX HTTP/3 reuseport, quicbpf, and SELinux The Problem: HTTP/3 Silently Fails Without reuseport With workerprocesses greater than 1, a QUIC listener configured without reuseport shares a single UDP socket across all workers. Because]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX QUIC reuseport: HTTP/3 Silently Breaks Without It]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: NGINX HTTP/3 reuseport, quicbpf, and SELinux The Problem: HTTP/3 Silently Fails Without reuseport With workerprocesses greater than 1, a QUIC listener configured without reuseport shares a single UDP socket across all workers. Because QUIC has no accept() step, every datagram arrives on that one socket, and whichever worker wakes first grabs it — even if it does not own that connection. The owning worker then receives mid-connection datagrams it cannot handle, producing H3RE…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-quic-reuseport-audio.m4a" length="7194837" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: NGINX HTTP/3 reuseport, quicbpf, and SELinux The Problem: HTTP/3 Silently Fails Without reuseport With workerprocesses greater than 1, a QUIC listener configured without reuseport shares a single UDP socket across all workers. Because QUIC has no accept() step, every datagram arrives on that one socket, and whichever worker wakes first grabs it — even if it does not own that connection. The owning worker then receives mid-connection datagrams it cannot handle, producing H3RE…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:09:32</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: NGINX HTTP/3 reuseport, quicbpf, and SELinux The Problem: HTTP/3 Silently Fails Without reuseport With workerprocesses greater than 1, a QUIC listener configured without reuseport shares a single UDP socket across all workers. Because QUIC has no accept() step, every datagram arrives on that one socket, and whichever worker wakes first grabs it — even if it does not own that connection. The owning worker then receives mid-connection datagrams it cannot handle, producing H3RE…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX Certificate Compression: RFC 8879 for Every Browser</title>
	<link>https://www.getpagespeed.com/podcast/nginx-certificate-compression-audio</link>
	<pubDate>Tue, 15 Sep 2026 22:17:45 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=124068</guid>
	<description><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the servers first flight and competes with the initial congestion window and QUICs 3x amplification limit. RFC 8879 certificate compre]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX Certificate Compression: RFC 8879 for Every Browser]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-certificate-compression-audio.m4a" length="8222351" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:10:54</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: RFC 8879 Certificate Compression in NGINX Problem Statement The TLS 1.3 certificate chain dominates the server's first flight and competes with the initial congestion window and QUIC's 3x amplification limit. RFC 8879 certificate compression shrinks that chain on every fresh handshake — a tested production chain dropped from 4735 to 3750 bytes (20.8% saving). NGINX supports this via a single directive: nginx sslcertificatecompression on; It is valid in http, server, and stre…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>Post-Quantum NGINX: OpenSSL 3.5 on Debian and Ubuntu</title>
	<link>https://www.getpagespeed.com/podcast/nginx-openssl35-debian-ubuntu-audio</link>
	<pubDate>Mon, 14 Sep 2026 21:50:05 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123987</guid>
	<description><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distributions system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reach]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[Post-Quantum NGINX: OpenSSL 3.5 on Debian and Ubuntu]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-openssl35-debian-ubuntu-audio.m4a" length="7142106" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:09:27</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Post-Quantum NGINX with OpenSSL 3.5 on Debian and Ubuntu Problem Statement NGINX packages on Debian and Ubuntu previously linked against each distribution's system OpenSSL. On Ubuntu 20.04 (focal), that meant OpenSSL 1.1.1, which reached upstream end-of-life on 11 September 2023. This also constrained which TLS features were available depending on the suite, and left DEB and RPM builds as separate stacks. Implementation NGINX packages on Debian and Ubuntu now link against an…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>OpenSSL 4.0 for NGINX: Why We Ship 3.5 LTS Instead</title>
	<link>https://www.getpagespeed.com/podcast/openssl-4-nginx-audio</link>
	<pubDate>Mon, 14 Sep 2026 02:59:02 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123912</guid>
	<description><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but i]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[OpenSSL 4.0 for NGINX: Why We Ship 3.5 LTS Instead]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/openssl-4-nginx-audio.m4a" length="7002838" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:09:16</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: OpenSSL 3.5 LTS vs. 4.0 for NGINX Packaging Problem Statement The decision between OpenSSL 3.5 and 4.0 for an NGINX fleet is a question of support windows and migration cost, not feature parity. OpenSSL 4.0 shipped in April 2026 but is explicitly not an LTS release. Under the project's policy, non-LTS branches receive only 13 months of support. OpenSSL 3.5 is the current LTS, supported until April 2030. Moving an NGINX fleet from 3.5 to 4.0 today would cut the support window…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>zstd-nginx-module: Maintained, Tested and Packaged</title>
	<link>https://www.getpagespeed.com/podcast/zstd-nginx-module-audio</link>
	<pubDate>Sun, 13 Sep 2026 01:47:50 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123807</guid>
	<description><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that si]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[zstd-nginx-module: Maintained, Tested and Packaged]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/zstd-nginx-module-audio.m4a" length="11858429" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:15:42</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Maintained zstd Module for NGINX — Streaming Fixes, Packaging, and Audit Response Problem Statement The original tokers/zstd-nginx-module (by Alex Zhang) has not seen a release since 2023 and carries bugs in its streaming path that silently truncate large responses. Over the buffer size, the filter could close the zstd frame over unconsumed input, delivering a valid but short file with no error and no log line — a failure mode that passes header assertions and is invisible w…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX RADIUS Authentication: No More htpasswd Files</title>
	<link>https://www.getpagespeed.com/podcast/nginx-radius-authentication-audio</link>
	<pubDate>Sat, 12 Sep 2026 02:27:41 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123718</guid>
	<description><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer t]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX RADIUS Authentication: No More htpasswd Files]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-radius-authentication-audio.m4a" length="6529510" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:08:38</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: RADIUS Authentication for NGINX Problem Statement NGINX ships with no built-in RADIUS support. Organizations that centralize credentials in FreeRADIUS, Microsoft NPS, Cisco ISE, or Aruba ClearPass have had no way to make NGINX defer to that authority—leaving per-tool htpasswd files as the practical alternative. The nginx-module-auth-radius package from the GetPageSpeed repository closes this gap by adding per-request RADIUS authentication (RFC 2865) to NGINX. How It Works Th…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>ECH Without Padding Is a Lookup Table</title>
	<link>https://www.getpagespeed.com/podcast/ech-handshake-padding-audio</link>
	<pubDate>Fri, 11 Sep 2026 06:09:08 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123655</guid>
	<description><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></description>
	<itunes:subtitle><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the servers encrypted handshake flight (EncryptedExtensions, Ce]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[ECH Without Padding Is a Lookup Table]]></itunes:title>
	<content:encoded><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/ech-handshake-padding-audio.m4a" length="8054478" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:10:39</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Technical Briefing: Closing the ECH Handshake-Size Side Channel in NGINX Problem Statement Encrypted Client Hello (ECH) encrypts the inner ClientHello—including the real SNI—and pads it. But the server's encrypted handshake flight (EncryptedExtensions, Certificate, CertificateVerify, Finished) still exposes its TLS record lengths on the wire. TLS 1.3 encrypts record contents but not lengths, and the dominant record is the certificate chain, which differs per virtual host. This means an observer…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>

<item>
	<title>NGINX TLS Vulnerability Fixes: BREACH, SWEET32, ROBOT</title>
	<link>https://www.getpagespeed.com/podcast/nginx-tls-vulnerability-fixes-audio</link>
	<pubDate>Wed, 09 Sep 2026 22:24:45 +0000</pubDate>
	<dc:creator><![CDATA[GetPageSpeed]]></dc:creator>
	<guid isPermaLink="false">https://www.getpagespeed.com/?post_type=podcast&#038;p=123557</guid>
	<description><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></description>
	<itunes:subtitle><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, ]]></itunes:subtitle>
	<itunes:episodeType>full</itunes:episodeType>
	<itunes:title><![CDATA[NGINX TLS Vulnerability Fixes: BREACH, SWEET32, ROBOT]]></itunes:title>
	<content:encoded><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></content:encoded>
	<enclosure url="https://www.getpagespeed.com/wp-content/uploads/2026/09/nginx-tls-vulnerability-fixes-audio.m4a" length="5606699" type="audio/mpeg"></enclosure>
	<itunes:summary><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></itunes:summary>
	<itunes:explicit>false</itunes:explicit>
	<itunes:block>no</itunes:block>
	<itunes:duration>00:07:26</itunes:duration>
	<itunes:author><![CDATA[GetPageSpeed]]></itunes:author>	<googleplay:description><![CDATA[Here is the technical briefing based on the provided source summary. --- Technical Briefing: Eliminating Legacy TLS Vulnerabilities and Achieving Post-Quantum Readiness in NGINX Problem Statement Four legacy TLS vulnerabilities—BREACH, Lucky13, SWEET32, and ROBOT—continue to dominate security scan reports for NGINX deployments. While the fixes are typically simple, they are often misapplied or missed due to configuration drift. Additionally, achieving post-quantum readiness requires specific so…]]></googleplay:description>
	<googleplay:explicit>No</googleplay:explicit>
	<googleplay:block>no</googleplay:block>
</item>
	</channel>
</rss>
