💾 Archived View for nytpu.com › gemlog › 2022-12-18.gmi captured on 2023-09-08 at 16:08:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
In which I discuss the history of close_notify in the Gemini commuity and assuade some fears.
In response to:
nervuri: “Many capsules don't send TLS close_notify”
reidrac: “Re: Many capsules don't send TLS close_notify”
Written on an NEC PC-8201A, while listening to Carrie & Lowell (2015) by Sufjan Stevens.
⁂
`close_notify` has been a surprisingly big topic on Gemini since it was brought up on the mailing list last year. Due to a bug in the TLS libary the Lupa crawler uses (lol), from 2022-12-01 until this month Lupa stopped tracking the close_notify statistics, however in the last historical archive with close_notify statistics[1] 49.6% of URIs (*not* capsules) didn't send a TLS close, with 36.7% of those not sending a close on success pages. Even if a lot of those URIs came from capsules hosting a large number of pages like an RFC mirror or something, 184,553 URIs—372,043 known URIs in that index × 49.6%—still had to have been a large majority of Geminispace not usng close_notify at that time.
However, after the mailing list got on it and particularly after Solderpunk updated the specification, many TLS libraries got fixed! Especially after people point out that it's not just pandering specifically to Gemini; sending close_notify (or a TLS error alert) has been mandatory in the specification since SSL 3.0 in 1996—before TLS even existed! It turns out that many TLS libraries were simply not compliant with the TLS spec, and luckily most library maintainers seemed eager to fix close_notify once they were made aware.
To clarify, I'm not blaming the maintainers here, since Gemini is the only protocol designed by people that actually understand the basics of how TLS works (or care about something other than whatever feature their new project at google needs) it's the only protocol where most clients expect close_notify and a bug like that would actually be caught.
But the point I'm making is that 3.8%/5% of hosts not using close_notify is a massive improvement over the ±50% not sending it a bit over a year ago. Hopefully we can clean up the last stragglers with the revived attention for it, and maybe even improve TLS libraries for everybody else too. I haven't written a server but just to be safe I double-checked and the stuff I've written that has a Gemini client all send a TLS close after they finish writing the request header, FWIW. It's much less important but still good practice for clients to send a close after they write the request header too.
[1]: last historical archive with close_notify statistics
According to my tests, SpaceBeans properly sends close_notify, even on Gemini error pages such as 53 Not Found which was historically where many servers failed to send a close.
If you want to test a server yourself you can use the following shell function I posted to the Gemini Mailing List before its demise:
test_close_notify() {
# CC0-1.0/BSD0/do what the fuck you want to it's literally 10 lines why would i care
# requires: POSIX shell, printf(1), sed(1), openssl(1) w/ s_client subcommand
hostname="$(printf '%s' "$1" | sed -e 's/[^/]*\/\/\([^@]*@\)\?\([^:/]*\).*/\2/')"
output="$(printf '%s\r\n' "$1" |
openssl s_client -ign_eof -connect "${hostname}:1965" 2>&1 |
tail -n1 | tr -d '\n')"
if [ "${output}" = "closed" ]; then
printf 'close_notify for "%s" properly received.\n' "${hostname}" >&2
else
printf 'close_notify for "%s" not received!\n' "${hostname}" >&2
fi
}
It uses OpenSSL's `s_client`, but extracts the information about the connection's closure so you don't have to hunt for it in the big pile of other diagnostic output.
To covert it from a shell function to a shell script just unwrap it from the function and plunk it in a `.sh`.
⁂