Skip to content

v0.4.2 — the UCI images check the server's name

Latest
Latest

Choose a tag to compare

View all tags
@JC-000 JC-000 released this 23 Aug 11:58
v0.4.2
e60028f
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Three prebuilt products, one disk each. No assembler, no cc65, no Python packages, no build step.

New: the UCI images check the server's name

Until now the client sent a server name and never checked the certificate was for that name — any certificate was accepted. c64-https-uci-onchip and c64-https-uci-comb now compare the certificate's subjectAltName dNSName entries against the host the image was built for:

  • case-insensitive (RFC 4343), leftmost-label wildcards only (RFC 6125 §6.4.3) — so *.example.org matches www.example.org but never example.org, a.b.example.org, and *.com never matches example.com
  • SAN only, no commonName fallback — CN has been deprecated since RFC 6125 §6.4.4 and every CA-issued certificate since ~2017 carries SAN
  • a certificate with no SAN extension is rejected, as current browsers do

c64-https-ip65-onchip does not have this check, and that image is byte-identical to v0.4.1. The routine is 491 B; that layout's largest free block is 170 B. Tracked as #135.

Please read this before trusting it

This is not server authentication, and it does not make the client safe against an active attacker.

There is still no certificate chain validation on any image — no trust store, no root CAs, no issuer check. Someone who can redirect your connection can self-sign a certificate carrying the correct name, and the new check passes it happily.

What changed is narrower: "any certificate is accepted" has become "any certificate naming the right host is accepted". That is a real improvement and it is not the same thing as knowing who you are talking to. Treat the transport as confidential against passive observers, not authenticated against active ones. README's "What this client does NOT authenticate" says the same thing in more detail.

Which one do I want?

image for
c64-https-ip65-onchip bone-stock C64 + RR-Net cartridge maximum compatibility — no REU, no turbo, nothing optional. ~36 min per handshake at 1 MHz. No name checking.
c64-https-uci-onchip Ultimate 64 / C64 Ultimate at turbo, REU off boots straight to the menu
c64-https-uci-comb Ultimate 64 / C64 Ultimate at turbo, REU on fastest — 1.73x quicker verify (16.4 s vs 28.4 s, U64E at 48 MHz). Builds a 16 KB table into REU bank 2 at each boot: ~34 s at 64 MHz, ~45 s at 48 MHz.

Each image is built for one host, baked in at build time; the released images target the bundled c64-https-listener.py. Point them at that, or rebuild with make HTTPS_HOST=....

If you are still on v0.4.0, replace it regardless of which image you use: a server presenting a P-384 certificate could corrupt resident code and hang the machine. Fixed in v0.4.1; no real server ever triggered it.

Verification

make package-verify — 11/11, RELEASE ARTIFACTS VERIFIED, from a clean checkout. All four sections ran, none skipped:

  • every PRG rebuilt from clean and byte-compared
  • every .d64 read back with c1541 and byte-compared against its PRG
  • every .d64 booted in VICE to the banner with the right backend line
  • the listener selftest negotiating TLS 1.3 twice, including a forced TLS_CHACHA20_POLY1305_SHA256 — the C64's only suite

Specific to the new check: 23 test vectors, 9 of them rejects, including the four wildcard over-matches. Six use real production certificates fetched live from en.wikipedia.org, github.com and lwn.net — each accepted for its own host and rejected for a wrong one. And on hardware, both UCI images at 48 MHz with the check live: the 125,258 B Wikipedia article fetched over TLS, HTTP 200, body byte-verified against a host-side reference.

Submodule pins unchanged: libs/nistcurves v0.11.2, libs/x25519 v0.11.2.

c64-https-ip65-onchip.prg     47105  58df15644b3ea91c0e6774b65392129cc4a5cffe126dfab96073a528758901d3
c64-https-uci-onchip.prg      62977  1af096e14de3c8f89efcd18b5862086d6e1e7918a9ca7fbaa81fc35368c740f4
c64-https-uci-comb.prg        62977  250364fd6b886126d888e24941127812d8e1ef8025b5d8f01e2258b01985dee0
c64-https-ip65-onchip.d64    174848  a10659f249a244d17e7700126e2eb28283417f529c2603e111e4d32db8152131
c64-https-uci-onchip.d64     174848  90bc5253b37860e121c2a1d9c128ab80667b4648f9b9661548279e9c20dc55d1
c64-https-uci-comb.d64       174848  84a6e2ac8ddd0aa4211b1faeb3fe8cf10a80baa08576c6560c36ed1d7fbbc964
Assets 10
Loading