Gateway v0.3.9

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers and the Internet Archive. Mac OS 9 (PowerPC), and Windows 95 through XP.

What's new in 0.3.9

Gateway no longer dials itself. A proxy-configured browser re-fetching its own auto-configuration script sends the absolute form of the URL, and when that named Gateway's own address, Gateway used to answer it by opening a connection back to itself — it worked, but spent a splice slot on the loop. Gateway now remembers up to four addresses it has been asked for this way and answers them locally; the very first request for a given address still makes the one round trip that teaches Gateway the address.

Gateway can say when it is out of date. Once per launch, a little after the listeners are up, it asks github.com once whether a newer release exists. When one does, it logs a single line (code G50) with an http:// link to download it for this platform; otherwise it says nothing, whether up to date or the check simply failed. check_updates = 0 turns the request off entirely.

"Check for Updates..." is now on the menu (the tray menu on Windows, the File menu on Mac OS 9), for asking outright rather than waiting for the next launch: it shows what it finds in a dialog, with a Download button on a newer release.

Setting it up

Point the browser's HTTP proxy at the machine running Gateway, port 8765. Classilla also needs network.http.proxy.use-http-proxy-for-https set to true in about:config.

rewrite_https = 1 is on by default and needs nothing else: type addresses without a scheme and everything loads, though the address bar will not say https. For the real thing, set connect_mitm = 1 and install Gateway's certificate authority in the browser from http://<gateway-address>:8765/gateway-ca.crt.

Mail, the Wayback proxy and the Tunnel are off until configured. Every setting is listed in docs/prefs.md.

Upgrading from 0.3.8

Nothing to do. Your preferences file and certificate authority are both kept as they are. Gateway now checks github.com once at launch for a newer release; check_updates = 0 turns that off.

The Wayback pane's "Quick images" checkbox is gone because it never did anything; an old wayback_quick_images line left in your prefs file is simply ignored.

Downloads

Mac OS 9: the .sit archive for real hardware, or the .dsk disk image to mount in an emulator.
Windows: the .zip to unpack anywhere, or the .img floppy image if the machine has no other way to receive a file.

Gateway v0.3.8

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers and the Internet Archive. Mac OS 9 (PowerPC), and Windows 95 through XP.

What's new in 0.3.8

Secure pages load faster. With connect_mitm on, every picture and script on an https:// page is a new connection, and each one used to cost a full handshake — a slow RSA calculation on a vintage processor. Gateway now remembers the browser's secure session and lets it resume, so only the first connection to a site pays for the handshake. The log says resumed when it happens. Verified on Windows 95 with Internet Explorer 4 and Netscape 4.08. Should a browser turn a resumption down, Gateway forgets that session and the next connection simply does a full handshake again.

Loose ends from 0.3.7, tidied. The Tunnel's remote host can no longer be saved empty while the Tunnel is on — it would turn every client away. The Wayback checkbox once labelled "Strip charset from Content-Type" did the opposite of what it said, and now reads "Keep the charset in Content-Type"; the setting itself is unchanged. The "Find the nearest available snapshot" checkbox is gone: it was never connected to anything, and Gateway reaches the nearest snapshot regardless.

Setting it up

Point the browser's HTTP proxy at the machine running Gateway, port 8765. Classilla also needs network.http.proxy.use-http-proxy-for-https set to true in about:config.

rewrite_https = 1 is on by default and needs nothing else: type addresses without a scheme and everything loads, though the address bar will not say https. For the real thing, set connect_mitm = 1 and install Gateway's certificate authority in the browser from http://<gateway-address>:8765/gateway-ca.crt.

Mail, the Wayback proxy and the Tunnel are off until configured. Every setting is listed in docs/prefs.md.

Upgrading from 0.3.7

Nothing to do. Your preferences file is kept as it is; a wayback_api line left in it is simply ignored. The certificate authority is kept, so a browser that already trusts it stays trusting it.

Downloads

Mac OS 9: the .sit archive for real hardware, or the .dsk disk image to mount in an emulator.
Windows: the .zip to unpack anywhere, or the .img floppy image if the machine has no other way to receive a file.

Gateway v0.3.7

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers and the Internet Archive. Mac OS 9 (PowerPC), and Windows 95 through XP.

What's new in 0.3.7

A tunnel, for SSH and anything else. Module 4 relays one local port (2222) to a fixed far end over TLS, optionally through an HTTP CONNECT or SOCKS5 proxy — the job stunnel does, done on the vintage machine. Ported from roytam1's fork, with tunnel_sni rewritten so the certificate is always checked against the real host whatever the handshake sends. Off by default, and it has no login of its own: keep its port behind the machine's own boundary.

A log a person can read. Gateway's log now speaks in plain sentences, each with a short code that docs/log-codes.md explains. The byte counts, hello bytes and library error numbers are one tick away, under "Show engineering detail in the log" (log_debug).

Preferences that follow your choices. Settings that only matter under another one — the mail servers for a custom provider, the tunnel's TLS options, the proxy's login — are dimmed while they do not apply, showing what would be used, and commented out in the preferences file rather than left to be misread. Change the choice back and they return as they were. The tunnel's proxy is a pop-up.

Six fixes from roytam1's fork. An idle session no longer holds its slot for ever, a CONNECT can no longer send its 200 Connection Established twice, and a site's 100 Continue is no longer taken for the answer. On the TLS side, the 1.2 fallback no longer redials a connection it cannot, sends the record version old servers expect, and notices a server hanging up mid-handshake instead of waiting 30 seconds.

Setting it up

Point the browser's HTTP proxy at the machine running Gateway, port 8765. Classilla also needs network.http.proxy.use-http-proxy-for-https set to true in about:config.

rewrite_https = 1 is on by default and needs nothing else: type addresses without a scheme and everything loads, though the address bar will not say https. For the real thing, set connect_mitm = 1 and install the authority above.

Mail, the Wayback proxy and the Tunnel are off until configured. Every setting is listed in docs/prefs.md.

Upgrading from 0.3.6

Your preferences file is kept as it is, and keeps working. One change: under provider = outlook or gmail the mail server settings in the file are now ignored in favour of the provider's own, so overriding a single host needs provider = custom with every server filled in — the Preferences window brings an existing override back when you choose Custom. The certificate authority is kept, so a browser that already trusts it stays trusting it.

Downloads

Mac OS 9: the .sit archive for real hardware, or the .dsk disk image to mount in an emulator.
Windows: the .zip to unpack anywhere, or the .img floppy image if the machine has no other way to receive a file.

Gateway v0.3.6

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers and the Internet Archive. Mac OS 9 (PowerPC), and Windows 95 through XP.

What's new in 0.3.6

SSL 3.0 over RC2, and a certificate from the era. 0.3.5 spoke SSL 3.0 over RC4 only, and turned away a browser that offered nothing but export-grade RC2. Gateway now has an RC2-CBC record layer, and the certificate it presents for each site is X.509 v1 — the form every server of that day sent, and the only one Netscape 3 accepts over RC2. Both from roytam1, verified on Netscape 3.04 Gold.

The handshake log says what the browser is speaking. Each connect_mitm handshake now logs the first bytes of the browser's hello and, if the browser walks away, how far it got — enough to tell an SSL 3.0 client from one speaking PCT, and a browser that refused the certificate from one that never sent a hello.

One script for the mail token. tools/get-email-token.py, run once on a modern computer with nothing but Python 3, signs in to Outlook.com or Gmail and prints the lines to paste into the preferences file. It replaces extract-refresh-token.py.

Setting it up

Point the browser's HTTP proxy at the machine running Gateway, port 8765. Classilla also needs network.http.proxy.use-http-proxy-for-https set to true in about:config.

rewrite_https = 1 is on by default and needs nothing else: type addresses without a scheme and everything loads, though the address bar will not say https. For the real thing, set connect_mitm = 1 and install the authority above.

Mail and the Wayback proxy are off until configured. Every setting is listed in docs/prefs.md.

Upgrading from 0.3.5

Nothing to do. The certificate authority is kept, so a browser that already trusts it stays trusting it, and the preferences file is untouched.

Downloads

Mac OS 9: the .sit archive for real hardware, or the .dsk disk image to mount in an emulator.
Windows: the .zip to unpack anywhere, or the .img floppy image if the machine has no other way to receive a file.

Gateway v0.3.5

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers and the Internet Archive. Mac OS 9 (PowerPC), and Windows 95 through XP.

What's new in 0.3.5

Browsers with no TLS at all now work. Netscape 3 and 4, Internet Explorer 3 and 4, and IE 5 for Mac OS 9 speak SSL 3.0 and nothing newer, so until now they could only use link rewriting. Gateway implements SSL 3.0 itself — the key schedule, the record MAC and an RC4 record layer — and serves them a real https:// address bar. Contributed by roytam1, verified on Netscape Communicator 4.75, 16-bit IE5 and IE 5.1.7 for Mac OS 9.

SSL 3.0 is spoken over RC4, which is what every browser of that age offers. A client that asks for SSL 3.0 with nothing but a CBC suite is told there is no cipher in common rather than being handed a broken handshake.

Settings have a window. Eight panes, on both platforms — Settings… in the Apple menu on Mac OS 9, File ▸ Preferences on Windows. The preferences file stays hand-editable and keeps its comments.

The certificate authority can be installed. Visit http://<gateway-address>:8765/gateway-ca.crt in the browser you are setting up and it will offer to install it, which stops the warning connect_mitm otherwise shows on every site. Clicking through the warning still works.

Also: the About box on Windows drew its text a third larger than the Mac's; a failed Open Transport connect reported the wrong call; and the SSLv2-compatible hello could translate two cipher specs onto one suite and send it twice.

Setting it up

Point the browser's HTTP proxy at the machine running Gateway, port 8765. Classilla also needs network.http.proxy.use-http-proxy-for-https set to true in about:config.

rewrite_https = 1 is on by default and needs nothing else: type addresses without a scheme and everything loads, though the address bar will not say https. For the real thing, set connect_mitm = 1 and install the authority above.

Mail and the Wayback proxy are off until configured. Every setting is listed in docs/prefs.md.

Upgrading from 0.3.4

If you used connect_mitm, the certificate authority is regenerated once on first run and has to be trusted again. Nothing else changes, and the preferences file is untouched.

Downloads

Mac OS 9: the .sit archive for real hardware, or the .dsk disk image to mount in an emulator.
Windows: the .zip to unpack anywhere, or the .img floppy image if the machine has no other way to receive a file.

Gateway v0.3.4

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers, and the Internet Archive. It runs on Mac OS 9 (PowerPC) and on Windows 95 through XP.

0.3.4 removes the checkbox. 0.3.3 made a typed https:// URL work in a browser with no modern TLS of its own, but only after unticking "Use SSL 2.0" — a setting every Internet Explorer ships with on, and one whose failure looked like anything except a setting. Gateway now understands the message those browsers send and connect_mitm works out of the box. Everything 0.3.3 did it still does; nothing else changed.

0.3.3, still current in everything below, makes a typed https:// URL work in a browser that has no modern TLS of its own, and takes Gateway back to Windows 95 RTM and, on paper, NT 3.51. Nothing from 0.3.2 is regressed; everything new is off by default except the link rewriting.

Which settings you need, and when

This is the part worth reading before anything else, because the right answer depends on your browser and one of the steps is a checkbox nobody would guess at.

There are two ways to get an old browser onto an https:// site, and they are alternatives rather than companions. Turning both on works but is worse than either alone: the browser fetches a page over real https and then finds every link in it rewritten to http://, which IE 6 complains about.

Prefs	For	What you get
connect_mitm = 1, rewrite_https = 0	Internet Explorer 5 and 6, Classilla, RetroZilla	Type https:// and it works. Real https as far as the browser is concerned: the padlock, Secure cookies, the URL it asked for.
rewrite_https = 1, connect_mitm = 0	Internet Explorer 4, Netscape 4.x, IE 5.1 on Mac OS 9	Type http://, or no scheme at all. Links, redirects and resources from other hosts all work. The address bar and Secure cookies do not.

rewrite_https = 1 is the default, so a fresh install behaves as the second row without being configured.

If you use connect_mitm, check that "Use TLS 1.0" is ticked

In Internet Explorer: Tools → Internet Options → Advanced, down in the Security group. Netscape 4.7 has the equivalent under Security → Navigator → Configure SSL. TLS 1.0 is the oldest protocol Gateway can speak to a browser, so a browser with it switched off has nothing in common with Gateway however capable it otherwise is.

"Use SSL 2.0" can be left alone, which is new in 0.3.4 and is the next section. In 0.3.3 it had to be unticked.

Internet Explorer 4 and Netscape 4 cannot use connect_mitm

Not a setting and not a bug. Those browsers have SSL 3.0 and no TLS; BearSSL has TLS 1.0 and no SSL. There is no version in common and nothing that creates one. Use rewrite_https with them and type addresses without a scheme — which works well, and is how the feature came to exist. What changed in 0.3.4 is the framing, not the version, so this limit is where it was.

The SSL 2.0 hello is converted rather than refused (new in 0.3.4)

Contributed by roytam1, who wrote the patch.

A browser with "Use SSL 2.0" enabled sends its very first message in SSL 2.0 framing: no TLS record header at all, just a length with its high bit set. What the message asks for can still be TLS 1.0 — the framing is a compatibility wrapper from 1996, meant to let a server that had moved on recognise the hello anyway. BearSSL never took that concession up; it rejected the format before reading a single field, and its own comment said the case might one day be handled. So the handshake failed with no certificate warning, because there was no certificate yet to warn about, and the log said BearSSL 3.

Gateway now reads that wrapper and rewrites what is inside it as an ordinary TLS ClientHello — the challenge becomes the client random, the SSL 2.0 spelling of 3DES becomes the TLS one — and the handshake goes on as though the browser had used TLS framing to begin with. Internet Explorer can be left exactly as it shipped.

A hello that genuinely asks for SSL 2.0 still fails, and so does one asking for SSL 3.0. Nothing below TLS 1.0 is implemented here and nothing below it will be: SSL 3.0 shares none of TLS's key derivation, has its own MAC construction, and is broken by POODLE besides. BearSSL 3 therefore still appears, meaning something narrower than it used to — the browser has SSL 3.0 and TLS 1.0 both switched off. When the version is the problem, the log now names the version the browser offered and says which side objected.

This has not been run against a real browser. The conversion is tested on the host and reasoned through against RFC 5246 Appendix E.2, including the transcript hashing that decides whether the last message of the handshake succeeds. Whether a period Internet Explorer completes a handshake through it is exactly what 0.3.4 is for. third_party/certainly/PATCHES.md §22 has the detail, including the one change from the original patch that was left out and why.

One URL instead of two ports (new in 0.3.4)

Both listeners now serve a proxy auto-configuration script at /proxy.pac — http://192.168.1.5:8765/proxy.pac, or the same path on :8888. In Internet Explorer it goes under Tools → Internet Options → Connections → LAN Settings → Use automatic configuration script, and Netscape 4 has the same thing under Edit → Preferences → Advanced → Proxies. Every browser this program targets supports it.

Which port you fetch it from is how you choose. From :8765 the script routes every host to the live proxy. From :8888 it routes every host to the archive except the ones on the wayback_live allow-list — so the browser stays pointed at one place and a whitelisted site genuinely never reaches :8888 at all. That is the one thing two port numbers cannot say on their own. Each script names which of the two it is in its first lines, so two bookmarks are tellable apart.

A host on wayback_live goes DIRECT — not the archive, and not Gateway either. The list names the sites you want left alone, so the script leaves them alone. The consequence is worth knowing for an https host on that list: the browser then does its own handshake, which is the thing Gateway normally spares it, so put one there only if the browser can manage modern TLS by itself.

The proxy addresses in the script are taken from the Host: header of the request that fetched it, so they are addresses that browser has just demonstrated it can reach — two interfaces, a name from the hosts file, or 127.0.0.1 from the same machine all produce a working script with nothing to fill in. Gateway's own address and anything undotted return DIRECT, so re-fetching the script cannot go through the proxy the script describes.

This is automatic configuration, not automatic detection. WPAD needs DHCP option 252 or a wpad DNS record and Gateway can provide neither, so the URL is pasted once. /wpad.dat serves the same script for anyone whose network already points WPAD at this machine.

Sites without TLS 1.3 now work at all (new in 0.3.4)

Gateway always opens a connection to a site with a TLS 1.3 hello, and falls back to TLS 1.2 when the site has no 1.3. That fallback had never once completed, so a site serving only TLS 1.2 could not be fetched — it failed as a handshake error, a certificate error, or a read failure depending on where it got to, and none of those named the real cause.

Two faults, both needed: Gateway rejected any TLS 1.2 ServerHello that carried no extensions, which is legal and is what a server with nothing to add sends; and once past that, it treated an ordinary outgoing record as evidence that the handshake had restarted, so the first read after the request always failed on a connection with nothing wrong with it. third_party/certainly/PATCHES.md §25 and §26 have the detail.

Most of the web hides this, because a host with TLS 1.3 goes near neither. The sites this matters for are the small, hand-run, old-web ones — which are the sites this program exists for. www.floodgap.com is the worked example and the one that found both.

Typing an https:// URL

With connect_mitm = 1, a CONNECT to port 443 is no longer a pipe Gateway stays out of. Any other port stays a raw tunnel, because nothing obliges a CONNECT to be a TLS one — git, ssh through a proxy and anything else that only wants bytes moved keep working exactly as before. Gateway answers it, presents a certificate it made for that host, and speaks TLS 1.0 to the browser while speaking TLS 1.3 to the site.

The certificates are Gateway's own and are made on the vintage machine. Nothing outside it takes part and nothing is downloaded. The first time it is needed, Gateway generates a 1024-bit RSA key and a self-signed authority, and keeps them beside the preferences as Gateway CA. That generation blocks Gateway while it runs — it is looking for two 512-bit primes on period hardware — and happens once; the log reports how long it took. Certificates for individual hosts are minted from that key as they are asked for, which is fast, and signed with SHA-1 because the browsers this exists for cannot verify anything newer.

Your browser will warn that it does not recognise the issuer, with a Yes button to continue. Installing Gateway CA stops the warning and is worth doing, because resources on other hosts tend to fail quietly rather than prompt.

It is off by default for a reason: the only cipher these browsers and BearSSL share is 3DES, so every byte of every pa...

Gateway v0.3.3

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers, and the Internet Archive. It runs on Mac OS 9 (PowerPC) and on Windows 95 through XP.

0.3.3 makes a typed https:// URL work in a browser that has no modern TLS of its own, and takes Gateway back to Windows 95 RTM and, on paper, NT 3.51. Nothing in 0.3.2 is regressed; everything new is off by default except the link rewriting.

Which settings you need, and when

This is the part worth reading before anything else, because the right answer depends on your browser and one of the steps is a checkbox nobody would guess at.

There are two ways to get an old browser onto an https:// site, and they are alternatives rather than companions. Turning both on works but is worse than either alone: the browser fetches a page over real https and then finds every link in it rewritten to http://, which IE 6 complains about.

Prefs	For	What you get
connect_mitm = 1, rewrite_https = 0	Internet Explorer 5 and 6, Classilla, RetroZilla	Type https:// and it works. Real https as far as the browser is concerned: the padlock, Secure cookies, the URL it asked for.
rewrite_https = 1, connect_mitm = 0	Internet Explorer 4, Netscape 4.x, IE 5.1 on Mac OS 9	Type http://, or no scheme at all. Links, redirects and resources from other hosts all work. The address bar and Secure cookies do not.

rewrite_https = 1 is the default, so a fresh install behaves as the second row without being configured.

If you use connect_mitm, untick "Use SSL 2.0"

In Internet Explorer: Tools → Internet Options → Advanced, down in the Security group. It is on by default, and it has to be off. Leave "Use SSL 3.0" and "Use TLS 1.0" ticked. Netscape 4.7 has the same switch under Security → Navigator → Configure SSL.

A browser with SSL 2.0 enabled sends its very first message in SSL 2.0 framing, which has no TLS record header at all. BearSSL rejects that format before reading a single field, so the handshake fails with no certificate warning — which makes it look like anything except a checkbox. The log names it:

#3 handshake with the browser failed for lite.duckduckgo.com
   (BearSSL 3: it sent an SSL 2.0-style hello -- untick "Use SSL 2.0" ...)

Internet Explorer 4 and Netscape 4 cannot use connect_mitm

Not a setting and not a bug. Those browsers have SSL 3.0 and no TLS; BearSSL has TLS 1.0 and no SSL. There is no version in common and nothing that creates one. Use rewrite_https with them and type addresses without a scheme — which works well, and is how the feature came to exist.

Typing an https:// URL

With connect_mitm = 1, a CONNECT to port 443 is no longer a pipe Gateway stays out of. Any other port stays a raw tunnel, because nothing obliges a CONNECT to be a TLS one — git, ssh through a proxy and anything else that only wants bytes moved keep working exactly as before. Gateway answers it, presents a certificate it made for that host, and speaks TLS 1.0 to the browser while speaking TLS 1.3 to the site.

The certificates are Gateway's own and are made on the vintage machine. Nothing outside it takes part and nothing is downloaded. The first time it is needed, Gateway generates a 1024-bit RSA key and a self-signed authority, and keeps them beside the preferences as Gateway CA. That generation blocks Gateway while it runs — it is looking for two 512-bit primes on period hardware — and happens once; the log reports how long it took. Certificates for individual hosts are minted from that key as they are asked for, which is fast, and signed with SHA-1 because the browsers this exists for cannot verify anything newer.

Your browser will warn that it does not recognise the issuer, with a Yes button to continue. Installing Gateway CA stops the warning and is worth doing, because resources on other hosts tend to fail quietly rather than prompt.

It is off by default for a reason: the only cipher these browsers and BearSSL share is 3DES, so every byte of every page gets encrypted three times over on a connection that never leaves the machine.

Links that used to become dead ends

rewrite_https = 1, on by default, turns https:// into http:// in HTML, CSS and JavaScript on the way to the browser. A 1997 browser meeting an https:// link does not ask Gateway for the page — it opens a tunnel and tries its own handshake, which fails with "an error occurred in the secure channel support" or "no common encryption algorithm(s)", neither of which mentions a proxy. Changing the link before the browser sees it avoids the whole situation, and the plaintext hop it creates is loopback on the machine Gateway is already running on.

Binary bodies are never touched — a JPEG that happens to contain those eight bytes would be corrupted by one — and a https:// split across a read boundary is still matched, which is the case that would otherwise leave one broken link per few hundred and no way to explain it.

A redirect fix came with it, and it is the more important half. The rule for which redirects Gateway follows itself asked where Gateway was rather than what the client could do, so after following one http → https hop Gateway was itself on TLS and handed the next https → https hop back to the browser as a Location it could not fetch. Two redirects was all it took, and lite.duckduckgo.com sends exactly two. The client hop is always plaintext, so every hop ending in TLS is Gateway's to follow.

Windows 95 RTM, and NT 3.51 on paper

Reported by roytam1, who had solved the same problem in RetroZilla.

Gateway named CryptAcquireContextA in its entropy pool, which made it an import, and an import the loader cannot resolve rejects the whole executable before any of Gateway's own version handling runs. CryptoAPI arrived with Windows 95 OSR2, so on 95 RTM and NT 3.51 Gateway did not fail to gather entropy — it failed to start. Those functions are now looked up at run time, and their absence costs one entropy source instead of the program. BearSSL carried a second copy of the same import, which is compiled out.

msvcrt.dll turned out to be the real floor rather than CryptoAPI: MinGW links it and it only ships with the system from OSR2 onward. The installer now carries a copy and drops it beside Gateway.exe, but only on a machine whose SYSTEM directory has none, so nothing from OSR2 forward is touched.

NT 3.51 needed one more thing: it is Program Manager, it has no notification area, and its Shell_NotifyIcon is a stub that fails. Gateway now checks, and where there is no tray the log window keeps a menu bar — Start/Stop, Start with Windows, Exit, About — and closing it minimises to a desktop icon instead of hiding.

Neither has been run. Every claim here is an argument about the binary's imports, which CI now checks on each build; the behaviour is unverified and there is no substitute for hardware. If you have either, a report would be welcome.

Also

The Mac .sit and .dsk now carry a starting Gateway Prefs beside the application, so a first run has something to read.

Large responses could stall (fixed in 0.3.2)

A TLS 1.3 record carries at most 16384 bytes of plaintext, and 16401 on the wire once its content type byte and 16-byte authentication tag are counted. The buffer receiving that plaintext is exactly 16384 bytes, and a check added in 0.3.0 compared the wire size against it. That comparison was true even for a completely empty buffer, so a maximum-sized record could never be decrypted: Gateway waited for room that was already there, and the connection sat until its idle timeout.

Any response big enough to fill one record reached it. A 24 KB image from the Internet Archive is sent as one maximum-sized record followed by a small one, so the first stalled and the rest never arrived. Smaller assets were unaffected, which is why pages mostly loaded while individual larger images and scripts did not.

The comparison now accounts for the record's overhead. An empty buffer always has room for a legal record, while a buffer still holding unread bytes continues to apply backpressure, which is what the check was added for. A record claiming more plaintext than the buffer could ever hold is now reported as an error rather than waited on, since no amount of draining would make space for it.

Both platforms were affected and both are fixed. third_party/certainly/PATCHES.md §20 has the detail.

Installing

Mac OS 9: unpack Gateway.sit, or mount Gateway.dsk in an emulator. Copy docs/prefs-example.txt into the System Preferences folder as Gateway Prefs. If the Finder shows a generic icon, rebuild the desktop by holding Command-Option through startup.

Windows: run Setup.exe, from the zip or from the floppy image. It installs to C:\Gateway by default, lets you choose elsewhere, adds a Gateway group to the Start Menu and registers an uninstaller. Upgrading over an existing installation keeps your Gateway.ini, which holds your mail password and sign-in token. To install by hand instead, the zip also carries Gateway.exe on its own.

Both need the configuration file to be writable: Gateway rewrites it when a mail provider rotates its refresh token, so a read-only copy works until the first rotation and then stops.

Requirements

Mac OS 9 with Open Transport, a PowerPC Mac, 8 MB of application memory (4 MB minimum). Real hardwar...

Gateway v0.3.2

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers, and the Internet Archive. It runs on Mac OS 9 (PowerPC) and on Windows 95 OSR2 through XP.

0.3.2 is a single fix, and an important one: anything larger than about 16 KB fetched over TLS could hang. If you are running 0.3.0 or 0.3.1, upgrade.

Large responses could stall

A TLS 1.3 record carries at most 16384 bytes of plaintext, and 16401 on the wire once its content type byte and 16-byte authentication tag are counted. The buffer receiving that plaintext is exactly 16384 bytes, and a check added in 0.3.0 compared the wire size against it. That comparison was true even for a completely empty buffer, so a maximum-sized record could never be decrypted: Gateway waited for room that was already there, and the connection sat until its idle timeout.

Any response big enough to fill one record reached it. A 24 KB image from the Internet Archive is sent as one maximum-sized record followed by a small one, so the first stalled and the rest never arrived. Smaller assets were unaffected, which is why pages mostly loaded while individual larger images and scripts did not.

The comparison now accounts for the record's overhead. An empty buffer always has room for a legal record, while a buffer still holding unread bytes continues to apply backpressure, which is what the check was added for. A record claiming more plaintext than the buffer could ever hold is now reported as an error rather than waited on, since no amount of draining would make space for it.

Both platforms were affected and both are fixed. third_party/certainly/PATCHES.md §20 has the detail.

Installing

Mac OS 9: unpack Gateway.sit, or mount Gateway.dsk in an emulator. Copy docs/prefs-example.txt into the System Preferences folder as Gateway Prefs. If the Finder shows a generic icon, rebuild the desktop by holding Command-Option through startup.

Windows: run Setup.exe, from the zip or from the floppy image. It installs to C:\Gateway by default, lets you choose elsewhere, adds a Gateway group to the Start Menu and registers an uninstaller. Upgrading over an existing installation keeps your Gateway.ini, which holds your mail password and sign-in token. To install by hand instead, the zip also carries Gateway.exe on its own.

Both need the configuration file to be writable: Gateway rewrites it when a mail provider rotates its refresh token, so a read-only copy works until the first rotation and then stops.

Requirements

Mac OS 9 with Open Transport, a PowerPC Mac, 8 MB of application memory (4 MB minimum). Real hardware and SheepShaver both work.

Windows 95 OSR2, 98, Me, NT 4.0, 2000 or XP. Verified on Windows Me, Windows 2000 and Windows 95 OSR2 under 86Box; the remaining versions are within the range the binary's imports allow but have not each been run.

Known limits

Gmail is implemented as a provider but has not been tried against a live account. TLS 1.3 offers ChaCha20-Poly1305 and AES-128-GCM with X25519 and P-256; a server insisting on anything else will not connect. The compiled-in anchors — 129 of them, the whole system set — are all Gateway will ever trust, since neither target has a usable system trust store.

Archived pages can be slow: the Internet Archive rate-limits, so wayback_connects defaults to 1, and a missing image is usually wayback_tolerance refusing a snapshot too far from your date rather than a failure.

Not warranted

A hobby project pointed at operating systems with no memory protection, no ASLR and no privilege separation. Research software, no warranty — do not put anything through it you would regret losing.

Gateway v0.3.1

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers, and the Internet Archive. It runs on Mac OS 9 (PowerPC) and on Windows 95 OSR2 through XP.

0.3.1 is a follow-up to 0.3.0, which added Windows. Everything here came out of using that release: a way to stop the gateway without quitting it, an installer, and the Windows build behaving as the Mac one does.

Stop and start without quitting

Both builds gain a menu item that releases the ports and drops what is in flight, and another click binds them again. The application stays up either way, so the log stays readable and the settings can be corrected before starting again — which is the point of stopping rather than quitting. The item names what a click will do: Stop Gateway while it runs, Start Gateway while it does not.

On Windows the tray icon says which it is. The opening under the arch is green while running and red while stopped, and blue in Explorer, on the taskbar and in the window caption, where the icon means the application rather than its state. All three are the same drawing with four gradient steps changed, because at sixteen pixels square the opening is the only element with enough room to carry a state — greying the whole icon was tried first and read as a flat blob.

A Windows installer

Setup.exe installs to C:\Gateway by default and lets you choose somewhere else, creates a Gateway group in the Start Menu, and registers a proper uninstaller with Add or Remove Programs.

Two things it deliberately will not do. It never overwrites an existing Gateway.ini, because that file holds the mail password and the OAuth refresh token, and replacing it on an upgrade would silently log you out of your own mail. And the uninstaller asks before removing it rather than assuming that uninstalling the program means discarding the credentials. It also closes a running Gateway before deleting it, and clears the registry entry that Start with Windows writes, which would otherwise have Windows complaining at every login about a program that is gone.

The Windows release ships as a zip and as a 1.44 MB floppy image. Mount the image as drive A: in 86Box, or write it to a real diskette — Setup is a third of a floppy, so it fits with room to spare.

Also fixed

• One Gateway at a time on Windows. A shortcut in the Startup group and the tray menu's Start with Windows are separate mechanisms that cannot see each other, so enabling both launched two copies at login, each trying to bind the same ports. A named mutex settles it; the second copy surfaces the first one's window and exits, which also covers double-clicking the executable while it is already in the tray.
• The Windows About window now carries the Mac's content and layout, in Windows' own typeface: the icon at the top, the same seven lines at the same offsets, with the names in bold.
• The About box agrees with the version again, on both platforms.

Installing

Mac OS 9: unpack Gateway.sit, or mount Gateway.dsk in an emulator. Copy docs/prefs-example.txt into the System Preferences folder as Gateway Prefs. If the Finder shows a generic icon, rebuild the desktop by holding Command-Option through startup.

Windows: run Setup.exe, from the zip or from the floppy image. To install by hand instead, the zip also carries Gateway.exe on its own; put it anywhere with a Gateway.ini beside it.

Both need the configuration file to be writable: Gateway rewrites it when a mail provider rotates its refresh token, so a read-only copy works until the first rotation and then stops.

Requirements

Mac OS 9 with Open Transport, a PowerPC Mac, 8 MB of application memory (4 MB minimum). Real hardware and SheepShaver both work.

Windows 95 OSR2, 98, Me, NT 4.0, 2000 or XP. Verified on Windows Me under 86Box; the other versions are within the range the binary's imports allow but have not each been run.

Known limits

Gmail is implemented as a provider but has not been tried against a live account. TLS 1.3 offers ChaCha20-Poly1305 and AES-128-GCM with X25519 and P-256; a server insisting on anything else will not connect. The compiled-in anchors — 129 of them, the whole system set — are all Gateway will ever trust, since neither target has a usable system trust store.

Archived pages can be slow: the Internet Archive rate-limits, so wayback_connects defaults to 1, and a missing image is usually wayback_tolerance refusing a snapshot too far from your date rather than a failure.

docs/inventory.md is the honest account of how this is put together, and third_party/certainly/PATCHES.md lists the twenty fixes the vendored TLS library has needed.

Not warranted

A hobby project pointed at operating systems with no memory protection, no ASLR and no privilege separation. Research software, no warranty — do not put anything through it you would regret losing.

Gateway v0.3.0

Gateway is a TLS 1.3 gateway and proxy that runs on the vintage machine rather than in front of it, so applications written before modern TLS existed can reach the current web, current mail servers, and the Internet Archive.

0.3.0 adds Windows. The same program, the same settings file, the same three modules, on Windows 95 OSR2 through XP — and it fixes two memory bugs that were live in the Mac builds all along.

Windows 95 OSR2 and later

Gateway.exe is a single native Win32 binary with no installer and no dependencies. It runs as a tray icon: right-click for Show/Hide Window, Start with Windows, About Gateway and Quit.

Settings live in Gateway.ini beside the executable rather than in a profile directory — 95 and 98 have no user profiles by default and NT puts them somewhere else again — and the file is the same one Mac OS 9 uses. Line endings do not matter to Gateway, so a configuration written on either platform works on the other.

95 needs OSR2 or later, which is where msvcrt.dll starts shipping with the system. Beyond that the binary imports nothing newer than Windows 95: every entry point it uses is listed in docs/porting.md §3, along with how that was established rather than assumed.

Roughly 9,500 of Gateway's 12,000 lines are shared between the two platforms unchanged — the protocol grammar, both proxy modules, the TLS library and the stream layer. What is per-platform is the transport, the preferences and log files, the entropy source, and the shell.

Two fixes that matter on Mac OS 9 too

HKDF wrote past the end of every key and IV buffer (PATCHES.md §19). br_hmac_out always writes the hash's whole output — 32 bytes for SHA-256 — and a TLS 1.3 IV is 12. Every IV derivation overran its buffer by 20 bytes, four times per handshake, onto whichever local the compiler had placed next. Which key that destroyed depended on the stack layout, so the same source was correct on PowerPC, corrupted the client's traffic key on x86 at -Os, and corrupted the server's at -O0.

Decrypted data was discarded when the reader fell behind (PATCHES.md §20). Application data was appended to a buffer holding exactly one maximum record, and the overflow was dropped with a comment saying "truncate if buffer full". Whenever a client read more slowly than a server sent — the ordinary case on this hardware — that punched a hole in the byte stream: chunked bodies were reported malformed, plain ones arrived short and sat until their idle timeout, and pages loaded at the speed of the timeout rather than the network.

Both were present in 0.2.0 and earlier. Upgrading is worthwhile on Mac OS 9 whether or not you care about Windows.

Also in this release

• CONNECT is verified. It shipped in 0.1.0 and had never been exercised,
  because there is no git client for Mac OS 9 to point at it. RetroZilla on Windows Me does exercise it.
• 129 trust anchors, up from 29. The curated list was a guess about which
  authorities the vintage web needs, and it kept being wrong — GlobalSign for lite.cnn.com, then Sectigo for code.jquery.com. A BearSSL anchor is a name and a public key rather than a certificate, so the whole system set costs about 53 KB and retires the problem.
• A transfer waiting on a slow client is no longer timed out. A browser
  busy parsing a large script stops reading; that is backpressure, not an idle connection, and cutting it off cost exactly one timeout of stall.
• A cipher self-test at startup, silent unless it fails.
• The About box agrees with the version. 0.2.0 shipped with resources
  reading 0.2 and an About box still saying 0.1; the number now lives in one header that both platforms read.

Installing

Mac OS 9: unpack Gateway.sit, or mount Gateway.dsk in an emulator. Copy docs/prefs-example.txt into the System Preferences folder as Gateway Prefs. If the Finder shows a generic icon, rebuild the desktop by holding Command-Option through startup.

Windows: unpack Gateway.zip anywhere and run Gateway.exe. Copy docs/prefs-example.txt beside it as Gateway.ini. Use Start with Windows in the tray menu to run it at login.

Both need the configuration file to be writable: Gateway rewrites it when a mail provider rotates its refresh token, so a read-only copy works until the first rotation and then stops.

Requirements

Mac OS 9 with Open Transport, a PowerPC Mac, 8 MB of application memory (4 MB minimum). Real hardware and SheepShaver both work.

Windows 95 OSR2, 98, Me, NT 4.0, 2000 or XP. Verified on Windows Me under 86Box; the other versions are within the range the binary's imports allow but have not each been run.

Known limits

Gmail is implemented as a provider but has not been tried against a live account. TLS 1.3 offers ChaCha20-Poly1305 and AES-128-GCM with X25519 and P-256; a server insisting on anything else will not connect. The compiled-in anchors are all Gateway will ever trust, since neither target has a usable system trust store.

Archived pages can be slow: the Internet Archive rate-limits, so wayback_connects defaults to 1, and a missing image is usually wayback_tolerance refusing a snapshot too far from your date rather than a failure.

docs/inventory.md is the honest account of how this is put together. third_party/certainly/PATCHES.md lists the twenty fixes the vendored TLS library has needed, and §19 and §20 record how they were found — a known-answer test, byte counters, and the peer's own alert, each eliminating a layer that had otherwise been guessed at.

Not warranted

A hobby project pointed at operating systems with no memory protection, no ASLR and no privilege separation. Research software, no warranty — do not put anything through it you would regret losing.