# Re: Many capsules don't send TLS close_notify
December 18, 2022
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”:
gemini://rawtext.club/~nervuri/close_notify.gmi
reidrac: “Re: Many capsules don't send TLS close_notify”:
gemini://capsule.usebox.net/gemlog/20221218-re-many-capsules-don-t-send-tls-close-notify.gmi
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]: gemini://gemini.bortzmeyer.org/software/lupa/archive-stats/2021-11-01.gmi
## SpaceBeans & close_notify
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`.
* * *
Contact via email: alex [at] nytpu.com
or through anywhere else I'm at:
gopher://nytpu.com/0/about
Copyright (c) 2022 nytpu - CC BY-SA 4.0
