<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>TLS on Defender TD5</title><link>https://td5.390er.de/kategorien/tls/</link><description>Recent content in TLS on Defender TD5</description><generator>Hugo</generator><language>de</language><lastBuildDate>Sun, 30 Aug 2026 13:12:34 +0200</lastBuildDate><atom:link href="https://td5.390er.de/kategorien/tls/index.xml" rel="self" type="application/rss+xml"/><item><title>TLS 1.2 and 1.3 on System 7: a 68K client measured against a live server</title><link>https://td5.390er.de/68k-tls/tls-on-system-7-68k-client-measured/</link><pubDate>Sun, 30 Aug 2026 12:08:09 +0200</pubDate><guid>https://td5.390er.de/68k-tls/tls-on-system-7-68k-client-measured/</guid><description>&lt;h2 id="question"&gt;Question&lt;/h2&gt;
&lt;p&gt;No browser that runs on System 7 can open an &lt;code&gt;https://&lt;/code&gt; URL against a server configured today: Netscape 3 and 4, iCab 2.9 and MacWeb speak SSL 2/3 with RC4 and DES, without SNI and without SHA-2 certificates, and every current server closes the handshake. The usual remedy is to terminate TLS on a proxy and hand the guest plain HTTP. This article asks the narrower question: can the guest itself complete a modern handshake, and at what cost in seconds?&lt;/p&gt;</description></item></channel></rss>