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