TLS by default, plain Protocol A only after confirmation

littlefox commented

2026-10-17 10:15:28 +00:00

Owner

User (D-026): "Someone in a meeting not too long ago stated that lyskom and the server has TLS support for encrypted communication. We should verify that and use it as default if possible. If TLS encryption is available and possible to use, we should still allow the fallback to be standard raw Protocol A communication, but only after user confirmation"

Verified 2026-10-17

lyskomd 2.1.2 (vendored; upstream master has nothing newer): no TLS code. Protocol A lists encryption as an open issue ("Should we use TLS? More study needed").
TLS patch: an experimental lyskomd TLS patch was posted in 2005 (bug 133). It was criticised because negotiation blocks the server and a MITM can force a fallback, and there's no sign it was merged.
Emacs client: no TLS. It encrypts by tunnelling through ssh (kom-ssh-relay-host).
kom.lysator.liu.se (one logged-out TLS hello per port): 4894 answers in plain Protocol A. 4895, 4896, 4443, 443 and 993 don't answer. No TLS endpoint today. A TLS front end such as stunnel in front of lyskomd would be the realistic way to get one.

Plan

Desktop: TLS client transport (rustls with webpki roots), tried first. A connection that isn't TLS (handshake fails) is not silently retried in plain text. The login page asks "Servern stöder inte kryptering. Anslut okrypterat?" and the user decides. The answer is remembered per server, can be changed, and is shown as a lock / no-lock indicator.
Browser: the page talks to kom-relay. The relay does the TLS to the server (--tls), and the plain-text fallback needs the same confirmation, carried as a relay request parameter. Browser→relay should be wss when served over https.
Devserver and CI: stunnel (or a rustls test proxy) in front of lyskomd on a second port with a self-signed CA, so both the TLS and the fallback paths are tested.
The MITM downgrade risk is exactly why the fallback needs confirmation. Once a server has been seen with TLS, a later plain-text connection is a warning, not a question.

User (D-026): "Someone in a meeting not too long ago stated that lyskom and the server has TLS support for encrypted communication. We should verify that and use it as default if possible. If TLS encryption is available and possible to use, we should still allow the fallback to be standard raw Protocol A communication, but only after user confirmation" ## Verified 2026-10-17 - **lyskomd 2.1.2** (vendored; upstream master has nothing newer): no TLS code. Protocol A lists encryption as an open issue ("Should we use TLS? More study needed"). - **TLS patch:** an experimental lyskomd TLS patch was posted in 2005 (bug 133). It was criticised because negotiation blocks the server and a MITM can force a fallback, and there's no sign it was merged. - **Emacs client:** no TLS. It encrypts by tunnelling through ssh (`kom-ssh-relay-host`). - **kom.lysator.liu.se** (one logged-out TLS hello per port): 4894 answers in plain Protocol A. 4895, 4896, 4443, 443 and 993 don't answer. **No TLS endpoint today.** A TLS front end such as stunnel in front of lyskomd would be the realistic way to get one. ## Plan - **Desktop:** TLS client transport (rustls with webpki roots), tried first. A connection that isn't TLS (handshake fails) is *not* silently retried in plain text. The login page asks "Servern stöder inte kryptering. Anslut okrypterat?" and the user decides. The answer is remembered per server, can be changed, and is shown as a lock / no-lock indicator. - **Browser:** the page talks to kom-relay. The relay does the TLS to the server (`--tls`), and the plain-text fallback needs the same confirmation, carried as a relay request parameter. Browser→relay should be wss when served over https. - **Devserver and CI:** stunnel (or a rustls test proxy) in front of lyskomd on a second port with a self-signed CA, so both the TLS and the fallback paths are tested. - The MITM downgrade risk is exactly why the fallback needs confirmation. Once a server has been seen with TLS, a later plain-text connection is a warning, not a question.

littlefox added the

area/protocol

kind/feature

labels

2026-10-17 10:15:28 +00:00

littlefox referenced this issue from a commit

2026-10-17 10:36:22 +00:00

TLS by default; plain Protocol A only after the user agrees

littlefox referenced this issue from a pull request that will close it,

2026-10-17 10:37:20 +00:00

TLS by default; plain Protocol A only after the user agrees #40

littlefox closed this issue

2026-10-17 11:04:40 +00:00

littlefox commented

2026-10-17 11:04:41 +00:00

Author

Owner

Merged via PR #40. CI run #57 is green, and packaging run #54 builds on all four distros with rustls/ring.

Verified:

Integration test tls_front_end: TLS works, plain port gives NotTls, unknown CA gives a certificate error.
e2e: all specs now run over TLS. tls.spec.ts covers confirm, cancel, remember and the downgrade warning.
Desktop smoke test over TLS.

kom.lysator.liu.se has no TLS front end, so users there get the confirmation question.

Merged via PR #40. CI run #57 is green, and packaging run #54 builds on all four distros with rustls/ring. Verified: - Integration test tls_front_end: TLS works, plain port gives NotTls, unknown CA gives a certificate error. - e2e: all specs now run over TLS. tls.spec.ts covers confirm, cancel, remember and the downgrade warning. - Desktop smoke test over TLS. kom.lysator.liu.se has no TLS front end, so users there get the confirmation question.

littlefox referenced this issue from a commit

2026-10-17 11:55:51 +00:00

kom-relay: finish the WebSocket close handshake before dropping it

Rows
Columns

TLS by default, plain Protocol A only after confirmation #39

Verified 2026-10-17

Plan