2021-02-16 Perl upgrading woes

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 => "",
-    port => $port,
-    tls => 1,
-    tls_cert => "t/cert.pem",
-    tls_key => "t/key.pem",
-    tls_verify => 0x00, } => sub {
+  Mojo::IOLoop->client(
+    {
+      address => "",
+      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.


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

$ phoebe --host melanobombus --host --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
[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
[2021-02-17 22:42:52.78911] [39528] [info] Listening on

As you can see, “melanobombus” is translated to because of my “/etc/hosts” file, which contains the following:	localhost	melanobombus	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:// | 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 and thus it would get served without TLS. Somehow, the TLS part now know that it’s only supposed to serve 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 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, 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

Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit the comment page if you need to fix typos. You can subscribe to new comments by email without leaving a comment.

To save this page you must answer this question:

Just say HELLO