connecting tinc 1.0.36/libssl3 to older nodes?

[Nathan Stratton Treadway]

On Wed, May 18, 2022 at 08:16:53 +0200, Guus Sliepen wrote:
> On Wed, May 18, 2022 at 01:28:31AM -0400, Nathan Stratton Treadway wrote:
> 
> > Thus, I believe Xenial's tinc 1.0.26 is attempting to use
> > EVP_bf_ofb()/EVP_sha1() when setting up the metadata connection -- and
> > that nothing else related to the metadata connection setup changed
> > between 1.0.26 and 1.0.33....
> 
> That's correct.

[...]
> > Does anyone have any suggestions of additional changes to either the
> > openssl.cnf override file on the Jammy node or the Tinc config files
> > that would allow Xenial and Jammy nodes to interoperate on the network
> > while we work to upgrade the all the old network nodes?
> 
> This is very annoying of course, but I don't see any option but to
> either upgrade tinc on Xenial or to downgrade tinc's OpenSSL library on
> Jammy. Upgrading tinc on Xenial might be the easiest option, it means

Do you have any sense of what what libssl operation is failing in the
1.0.26 <-> 1.0.36/libssl3 case, once my openssl.cnf configuration is
such that I get past the error:0308010C:digital envelope
routines::unsupported" errors?  

(As far as I can tell, the "Bogus data received from" message is
generated in the protocol.c:receive_request() function.)

In other words, is there something related to  EVP_bf_ofb() or EVP_sha1()
that is actually still failing, or is there some other libssl call that
would come into play during the CHALLENGE/CHAL_REPLY phase of the
negotiation?

						Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst at ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239