I’ve got the first failing reports from CPAN testers reporting some TLS issues:
Mojo::Reactor::Poll: I/O watcher failed: Client creation failed: SSL connect attempt failed error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
This seems to be related to upgrading IO::Socket::SSL from 2.068 to 2.069, but when I check the commit log, I see nothing suspicious.
When you upgrade Mojolicious from 8.67 to 9.0 things are even worse because they removed the tls_verify option for Mojo::IOLoop::TLS.
In t/test.pl you can change the test client code using Mojo::IOLoop as follows:
@@ -125,13 +125,15 @@ sub query_gemini {
my ($header, $mimetype, $encoding, $buffer);
# create client
- Mojo::IOLoop->client({
- address => "127.0.0.1",
- port => $port,
- tls => 1,
- tls_cert => "t/cert.pem",
- tls_key => "t/key.pem",
- tls_verify => 0x00, } => sub {
+ Mojo::IOLoop->client(
+ {
+ address => "127.0.0.1",
+ port => $port,
+ tls => 1,
+ tls_cert => "t/cert.pem",
+ tls_key => "t/key.pem",
+ tls_options => { SSL_verify_mode => 0x00 }
+ } => sub {
my ($loop, $err, $stream) = @_;
die "Client creation failed: $err\n" if $err;
$stream->on(error => sub {
That still doesn’t solve the TLS/SSL error, however. If you upgrade Net::SSLeay from 1.88 to 1.90 that seems to make no difference, and the list of changes appears innocuous.
My system has OpenSSL 1.1.1d installed, if that makes a difference.
I currently have no workaround except downgrading.
#Perl #Phoebe
(Please contact me if you want to remove your comment.)
⁂
I have at least an inkling of what’s wrong. First, I verified that I can have a simple setup with Mojo::IOLoop acting both as server and as client, and that I can use IO::Socket::SSL as a client as well.
So that’s not where the problem is. The problem is somewhere in the hostnames.
Here’s an example. Start the server serving the hostname “melanobombus” and the IP 127.0.0.1.
$ phoebe --host melanobombus --host 127.0.0.1 --log_level=debug [2021-02-17 22:42:52.78734] [39528] [info] Running ./wiki/config [2021-02-17 22:42:52.78762] [39528] [info] PID: 39528 [2021-02-17 22:42:52.78767] [39528] [info] Host: melanobombus 127.0.0.1 [2021-02-17 22:42:52.78769] [39528] [info] Port: 1965 [2021-02-17 22:42:52.78772] [39528] [info] Space: [2021-02-17 22:42:52.78778] [39528] [info] Token: hello [2021-02-17 22:42:52.78781] [39528] [info] Main page: [2021-02-17 22:42:52.78784] [39528] [info] Pages: [2021-02-17 22:42:52.78786] [39528] [info] MIME types: [2021-02-17 22:42:52.78788] [39528] [info] Wiki data directory: ./wiki [2021-02-17 22:42:52.78807] [39528] [info] Listening on 127.0.1.1:1965 [2021-02-17 22:42:52.78911] [39528] [info] Listening on 127.0.0.1:1965
As you can see, “melanobombus” is translated to 127.0.1.1 because of my “/etc/hosts” file, which contains the following:
127.0.0.1 localhost 127.0.1.1 melanobombus 127.0.1.1 xn--mlanobombus-bbb ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Phoebe takes host “melanobombus”, figures out the IP number, and listens on the appropriate port.
Now let’s test it, by requesting a few names:
$ script/gemini gemini://melanobombus | head -2 20 text/gemini; charset=UTF-8 # Welcome to Phoebe! $ script/gemini gemini://127.0.0.1 | head -2 20 text/gemini; charset=UTF-8 # Welcome to Phoebe! $ script/gemini gemini://localhost | head -2 Mojo::Reactor::Poll: I/O watcher failed: SSL connect attempt failed error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
So I’m guessing the problem has nothing to do with the TLS options. This has nothing to do with SSL3 or TLSv1. The problem is that “localhost” isn’t being served, somehow, eventhough “localhost” translates to 127.0.0.1 and thus it would get served without TLS. Somehow, the TLS part now know that it’s only supposed to serve 127.0.0.1 and “melanobombus”. It shouldn’t work for “localhost” and it’s telling me: “you have requested an unrecognized name”. I got confused by the name of the error location: “routines:ssl3_read_bytes:tlsv1”.
All right!
---
This would be the CN attribute of the TLS cert. It’s only valid for the domain named, unfortunatlely. As far as TLS is concerned, localhost and 127.0.0.1 are two different domains.
– splatt9990 2021-02-17 23:03 UTC
---
Yes, this seems to be it. This used to work and now it no longer does. What I did now in my test setup was to remove all the occurrences of 127.0.0.1, replacing them with localhost, plus related changes, and that seems to work. I *think* I started doing that because some CPAN testers did not have “localhost” set, but I no longer remember. We’ll see what happens.
– Alex 2021-02-20 22:49 UTC