pagekitec fails to connect securely on openwrt with openssl 1.1.1d

[karlp]

used to work in the past

log from connecting

t=2019-10-02 14:00:59.202; ts=5d94ad9b; tid=77b30d74; ll=2e; msg=Connecting to [159.69.241.209]:443 (session=new, in DNS)
t=2019-10-02 14:00:59.600; ts=5d94ad9b; tid=77b30d74; ll=2f; msg=5[pkc_start_ssl]: Failed to prepare SSL object!
t=2019-10-02 14:00:59.601; ts=5d94ad9b; tid=77b30d74; ll=30; msg=Connect failed: 5
t=2019-10-02 14:00:59.602; ts=5d94ad9b; tid=77b30d74; ll=31; msg=pkmanager.c: TLS handshake failed

Version: This is pagekitec.c from libpagekite 0.91.190530C
using musl-libc 1.1.23

[BjarniRunar]

It works!

[plan44]

Since I upgraded my server to debian bullseye (from debian buster) including pagekite.py backend, I cannot connect any more with pagekitec from openwrt with openssl 1.1.1t.

I spend a few hours trying to get more information at the pagekitec end (adding ERR_print_errors et. al.) in pkconn.c but I don't get anything more than the error code 5 from SSL_get_error() as follows:

tid=778c2d7c; ll=1e; msg=Connecting to [x.x.x.x]:22280 (session=new, in DNS)
tid=778c2d7c; ll=1f; msg=5[pkc_start_ssl]: Starting TLS connection with xxx.xxx.ch
tid=778c2d7c; ll=20; msg=5: Started SSL handshake
tid=778c2d7c; ll=21; msg=5: TLS handshake failed! SSL_get_error()=5
tid=778c2d7c; ll=22; msg=Connect failed: 5
tid=778c2d7c; ll=23; msg=pkmanager.c: TLS handshake failed
tid=778c2d7c; ll=24; msg=Network is up but kites are not ready.
tid=77908d7c; ll=25; msg=Tick!  [repeating=yes, next=16, status=50, tunnels=0, v=0.91.201110C]

Any idea what could be the reason?

[karlp]

well, it's definitely unrelated to this bug :) I would suggest looking at what actually changed debian side, are they for instance now only allowing tls1.3 or something? I no longer remember the env vars or whatever to get openssl to spit out more information. You probably also would need to rebuild openssl with debug to get the information out of it.

[plan44]

@karlp thanks for the quick response! In fact, Bullseye (Debian 11) defaults to not using TLSv2, but several sources say it can be configured to use it by setting the following in /etc/ssl/openssl.cnf (which I did):

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1

Only, pagekite.py does not seem to pick that up.

I tried to instrument libpagekite on the client side to see more about that ominous err==5, but the openssl error stack seems to be empty at that point (ERR_print_errors() outputs nothing).

My problem is that I have a three to four digit number of devices in the field I'd like to keep accessible without being forced to update them. On the other hand, keeping the server at an old unsupported debian version forever is not a good option, especially since it should work (when TLSv1.2 is enabled server side).

So I'd like to understand why exactly the handshake fails. I tried to follow upon the comment on line 78 of pkerror /* FIXME: Why did it fail? */, but etirely unsuccessful so far.

Also, as TLSv1.3 is supported in OpenSSL v1.1.1 libpagekite is built against, I would like to understand what prevents the handshake to just use TLSv1.3?

[plan44]

Ok, I managed to track it down:

• using tshark on the server, I could see that the back-ends based on libpagekite actually try to connect with TLSv1 only, despite being built with OpenSSL 1.1.1t, which supports TLSv1.2 and TLSv1.3 (and has those enabled in the actual build, I verified with openssl ciphers on the actual back-end device).

• To solve my problem, which was allowing these clients to allow to connect again without needing an update, I had to make PyPagekite accept TLSv1 on a Debian 11. The details are off-topic here, but the problem was that PyPagekite does not use the system-wide ssl conf, so I had to add a way to specify the needed cipher list (DEFAULT@SECLEVEL=1), see Add tls_ciphers option to allow specifiying custom ciphers list PyPagekite#113.

• Still unclear to me is why libpagekite uses neither TLSv1.3 nor TLSv1.2, but TLSv1 despite underlying OpenSSL supporting all three.