Subj : Web server: default Authentication list advertises TLS-PSK, which is c
To   : GitLab issue in main/sbbs
From : Rob Swindell
Date : Fri Jul 31 2026 01:08:48

open https://gitlab.synchro.net/main/sbbs/-/issues/1206

The web server's default `Authentication` list offers a mechanism that the
server has no ability to perform.

`WEB_DEFAULT_AUTH_LIST` is defined in `src/sbbs3/websrvr.h:135` as:

```c
#define WEB_DEFAULT_AUTH_LIST       "Basic,Digest,TLS-PSK"
```

That string is the default for the `Authentication` key of the `[Web]` section
(`src/sbbs3/sbbs_ini.c:906-907`) and for per-directory `webctrl.ini` overrides
(`src/sbbs3/websrvr.cpp:3894`).

But every code path that could make TLS-PSK function is compiled out:

* `src/sbbs3/websrvr.cpp:6936` - the loop that registers the user/password
  pairs with the TLS session, under
  `#if 0 // TLS-PSK is currently broken in cryptlib`
* `src/sbbs3/websrvr.cpp:7128` - reading `CRYPT_SESSINFO_USERNAME` back off the
  session to set `session.req.auth.type = AUTHENTICATION_TLS_PSK`, under the
  same `#if 0`

With both disabled, `req.auth.type` can never take the value
`AUTHENTICATION_TLS_PSK`. The consequences:

* the `case AUTHENTICATION_TLS_PSK:` arms at `websrvr.cpp:2127` and
  `websrvr.cpp:2224` are unreachable
* the guard at `websrvr.cpp:2814`, "If you're authenticated via TLS-PSK, you
  can't use basic or digest", is unconditionally true
* a sysop who follows the advertised default and sets `Authentication =
  TLS-PSK` for a directory gets a location that cannot be authenticated by
  anyone, with no diagnostic explaining why

`src/sbbs3/services.cpp:1196` carries the identical disabled block.

History: both blocks have been disabled since dbbfabf1b1 (funky-27-foam,
2015-08-20), "Update to 3.17a", which is the commit that first added TLS
support to the web server and services. `git blame -w` attributes the `#if 0`
lines to that commit, and its parent b19685550f contains no occurrence of "PSK"
in `websrvr.c` at all, so the support was never enabled and later switched off:
it landed already disabled.

Worth noting that cryptlib's PSK support is no longer broken in general. Two
patches added since then are in active use:

* `3rdp/build/cl-add-psk-flag.patch` (bfbf3f509f, method-29-book, 2025-02-02),
  adding a `CRYPT_TLSOPTION_USED_PSK` attribute so the application can tell
  whether PSK was negotiated
* `3rdp/build/cl-psk-only-client.patch` (9a5dbe39f8, quick-19-ultra,
  2026-05-10), forcing the client to offer only PSK suites

both consumed today by `src/sbbs3/mqtt_broker.cpp:750` and
`src/sbbs3/js_socket.cpp:2736`. So the web server's disabled code is stale
rather than blocked on upstream.

Suggested fix, smallest first:

1. Drop `TLS-PSK` from `WEB_DEFAULT_AUTH_LIST` so the shipped default no longer
   advertises a mechanism the server cannot perform.
2. Optionally, log a warning when `TLS-PSK` appears in an `Authentication` list
   while the support is compiled out, so an existing `sbbs.ini` or
   `webctrl.ini` that names it is not silently useless.

The `#if 0` blocks themselves are worth leaving in place as a marker for the
day the web server gains an additional or alternative crypto backend; this
report is about the default advertising the mechanism, not about the dormant
code.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.