connecting tinc 1.0.36/libssl3 to older nodes?

Nathan Stratton Treadway nathanst at ontko.com
Wed May 18 07:28:31 CEST 2022


On Fri, May 06, 2022 at 07:22:45 +0200, Guus Sliepen wrote:
> Hi, as far as tinc itself is concerned it should be fine if nodes are
> linked against different versions of OpenSSL. However, OpenSSL might
> have deprecated some cryptographic algorithms, and distributions might
> sometimes change which algorithms to enable/disable when packaging
> OpenSSL. Are you using the defaults from tinc, or did you specify which
> encryption and/or authentication algorithm to use by adding "Cipher = ..."
> or "Digest = ..." statements to any of tinc's configuration files?
> 
> Can you tell me which distribution and its version you have on the
> server that runs tinc 1.0.26? I can then try to reproduce the situation.


I did further testing with Tinc from various Ubuntu releases, and found:

* the stock Tinc package in Xenial (1.0.26/libssl1.0.0) has the same
  behavior as my original node did.  (So for further testing now I am
  just using a stock Xenial node.)

* the stock Tinc package in Impish (1.0.36/libssl1.1) is able to
  interoperate with both Tinc-in-Jammy (1.0.36/libssl3) and Tinc-in-
  Xenial without any additional openssl configuration on any node.

* stock Tinc from Jammy is also able to interoperate with stock Tinc
  in Bionic 1.0.33/libssl1.1) without any additional openssl
  configuration.


So, I looked through the git log between release-1.0.26 and
release-1.0.33 in hopes of identifying any Tinc code changes that would
matter to the libssl1.x -> libssl3 transition.  The changed lines that
jumped out at me were:


=====
diff --git a/src/net_setup.c b/src/net_setup.c
index 863616b7..13719f52 100644
--- a/src/net_setup.c
+++ b/src/net_setup.c

-               myself->incipher = EVP_bf_cbc();
+               myself->incipher = EVP_aes_256_cbc();


-       myself->connection->outcipher = EVP_bf_ofb();
+       if(keylen <= 16) {
+               myself->connection->outcipher = EVP_aes_128_cfb();
+       } else if(keylen <= 24) {
+               myself->connection->outcipher = EVP_aes_192_cfb();
+       } else {
+               myself->connection->outcipher = EVP_aes_256_cfb();
+       }


-               myself->indigest = EVP_sha1();
+               myself->indigest = EVP_sha256();
 
-       myself->connection->outdigest = EVP_sha1();
+       myself->connection->outdigest = EVP_sha256();
=====

Since the connection between nodes appears to fail during metadata setup
(based on the log messages I posted in my earlier email), I'm assuming
that it's the myself->connection->outcipher and
myself->connection->outdigest changes that matter here.

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....

According to 
  https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html  
, Blowfish is part of the legacy provider in libssl3, so it makes sense
that it's not available by default on the Jammy node.

However, as far as I can tell this does get successfully enabled when my
openssl.cnf override-file is in place (on the Jammy node):

=====
ubuntu at jammy:~$ openssl list  -cipher-algorithms | grep "Provided:\|BF"
  bf => BF-CBC
  BF-CBC
  BF-CFB
  BF-ECB
  BF-OFB
  blowfish => BF-CBC
Provided:

ubuntu at jammy:~$ OPENSSL_CONF=/etc/tinc/openssl_seclevel1.cnf openssl list  -cipher-algorithms | grep "Provided:\|BF"
  bf => BF-CBC
  BF-CBC
  BF-CFB
  BF-ECB
  BF-OFB
  blowfish => BF-CBC
Provided:
  { 1.3.6.1.4.1.3029.1.2, BF, BF-CBC, BLOWFISH } @ legacy
  BF-ECB @ legacy
  BF-OFB @ legacy
  BF-CFB @ legacy

=====

(SHA1 appears to still be supported in libssl3:
=====
ubuntu at jammy:~$ openssl list  -digest-algorithms | grep "Provided:\|SHA1"
  RSA-SHA1 => SHA1
  RSA-SHA1-2 => RSA-SHA1
  MD5-SHA1
  SHA1
  sha1WithRSAEncryption => SHA1
  ssl3-sha1 => SHA1
Provided:
  { 1.3.14.3.2.26, SHA-1, SHA1, SSL3-SHA1 } @ default
  MD5-SHA1 @ default
=====
)

I am not sure how many bits of security the EVP_bf_ofb() algorithm is
considered to have, but it seems I need to have "CipherString =
DEFAULT:@SECLEVEL=1" in my override file in order to get past the
"digital envelope routines::unsupported" error during metadata
negotiation.

(The
  https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_security_level.html
page says SECLEVEL 2 [the Jammy build default] is 112 bits, while
SECLEVEL 1 is 80 bits.)

I went ahead and set SECLEVEL=0, but still get the 
  Bogus data received from tinc_xenial
  Closing connection with tinc_xenial
log messages on the Jammy node....


As far as I can tell, the EVP_aes_*_cfb() algorithms used by the later
versions of Tinc are available on the Xenial node
=====
ubuntu at xenial:~$ openssl list-cipher-algorithms | grep "AES.*CFB"
AES-128-CFB
AES-128-CFB1
AES-128-CFB8
AES-192-CFB
AES-192-CFB1
AES-192-CFB8
AES-256-CFB
AES-256-CFB1
AES-256-CFB8
AES-128-CFB
AES-128-CFB1
AES-128-CFB8
AES-192-CFB
AES-192-CFB1
AES-192-CFB8
AES-256-CFB
AES-256-CFB1
AES-256-CFB8
=====

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?


Thanks.

							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


More information about the tinc mailing list