For the sake of posterity, this is about “SSL Library Error 6”, and the short version is that it’s a spurious error that is almost certainly a dead end unrelated to the real TLS or SSL problem you’re working on if search brought you here.
Here’s the long version:
After updating some .htaccess files to ban Petalbot – people who add “?=warblegarble” to URLs to deliberately break caching are bad people who go in the bad people bin – I noticed a bunch of “SSL Library error 6” messages my logs, which only shows up in one unrelated search result over at nextcloud.
It’s very cool when you have more instances of an error message in your logs than there are search results for it on Google. Even cooler when you trace the client IPs generating that error and find that about a third of them are Google! Specifically GoogleBot. Another third are from “shadowserver dot org“, an organization that definitely radiates that Pinkerton legitimacy, and the last third are an assortment of randos from mostly German hosting services. Corps and cops, then. Cool, cool cool.
I think that we can all agree that while “6” is a perfectly good number – reliably whole, solid performer on the integer line, minor celebrity for achievements like “smallest product of distinct primes” and “factor of 42”, that sort of thing – that it is not otherwise spectacularly informative in this context. That’s not 6’s fault, though; it’s clearly been pressed into duty well outside if its normal scope of responsibilities, so I don’t want this to come across like I’m across like I’m making accusations or assigning blame. Detailed operational significance is just not its usual metier, you know? But we need to figure this out, so let’s try to dig ourselves out of this with something more useful, like grep.
Searching for substrings – the part of the error message before distinguishing elements appear – has always worked well for me and this type of error shows up in Apache in ssl_engine_io.c, where
ap_log_cerror(APLOG_MARK, APLOG_INFO, inctx->rc, c, APLOGNO(01992) "SSL library error %d reading data", ssl_err);
starts to point us in the right direction, though it doesn’t really tell us what “ssl_err” means. Good breadcrumbs, though, if we look up at the commented-out if statement in line 770; at some point (at least 22 years ago, wild) this line was changed from a specific error handler to a catch-all. With that in mind, we can probably figure out what these ssl_err values mean – SSL_ERROR_WANT_READ, SSL_ERROR_SSL, everything we’re seeing here – and where the number six comes into the picture if we can figure out where they’re defined.
Nothing useful about that is showing up in the Apache tree, so let’s hop over to OpenSSL proper and see what we find, and… aha! Here we go: define SSL_ERROR_ZERO_RETURN 6
We’ve found 6! Outstanding, now we just need to figure out what a “ZERO RETURN” error means in secure socket land. All of this happening on Zero Cool Day was an odd coincidence.
Searching on that brings us at long last to some reference documentation, which tells us that this error occurrs when “The TLS/SSL peer has closed the connection for writing by sending the close_notify alert. No more data can be read. Note that SSL_ERROR_ZERO_RETURN does not necessarily indicate that the underlying transport has been closed.”
Going back to Apache, we see a comment telling us that this is a TLS/QUIC thing that means “connection closed cleanly or aborted during keepalive: let the length check determine whether it’s an error”.
So, here we are. This is a spurious error generated by spec-adjacent scanning tools run by people I’m disinclined to further assist for free, so I’m going to stop here.
I don’t know why I need to rathole on this stuff but I do. Computers are understandable – they have to be understandable – but understanding them can be a lot of work, so thank you, Bodo Moeller (25 years ago), Marcus Greenwood (2 years ago), William Rowe (22 years ago), ylavic (2 years ago) and Ralf S. Engelschall (26 years ago) for helping me out.
I wish more people recognized that understanding as a collaboration. One that can span time and space in entirely unexpected ways but still: a collaboration, a commons and a collective responsibility.