keepalived website might offer TLS cipher suite incorrectly

[linkvt]

Hi,

to give you some background how I noticed this problem: While trying to build keepalived in a github actions build running with docker buildx and a qemu arm64 environment my builds always got stuck during the source download.

Describe the issue When using curl to download the sources in a QEMU arm64 environment it chooses the cipher suite TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 which seems to be broken there.

After reading more about this topic I found out that this Cipher Suite seems to be part of TLS 1.3, see e.g. https://ciphersuite.info/cs/TLS_CHACHA20_POLY1305_SHA256/ . I'm really not into this topic so if you guys have a better plan I appreciate more infos but right now I don't understand why it is offered for TLS 1.2 communications. Edit: I checked the wrong cipher suite, it is correct that it is part of TLS 1.2: https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256/

nmap also shows the following when scanning the ciphers:

$ nmap --script ssl-enum-ciphers -p 443 keepalived.org
...
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A...

To Reproduce See https://github.com/linkvt/curl-buildx-problem/runs/1450192430?check_suite_focus=true , it works on my Raspberry Pi 4 running on ARM so it seems to be QEMU specific, but still wondering why this is used when using TLS 1.2.

Expected behavior curl is not getting stuck when using it to download keepalived sources from the keepalived website.

A workaround for me would be to simply download the sources from their tags on Github but unfortunately the sources are not equal to the sources linked on keepalived.org and I don't want to risk anything by choosing the source code of a different version - is there a reason for this? Another workaround is to use TLS 1.1 or specify another cipher suite when using curl but I was really wondering why this cipher suite is offered for TLS 1.2 when I read about it being part of TLS 1.3.

Thanks for your feedback, Vincent

[pqarmitage]

I have just done a quick check of the source files in the 2.1.5 tarbal from keepalived.org and the tarball that is downloaded from github.com, and the files that are in both tarballs are all identical.

The reason that the tarballs are different is that the tarballs are generated for slightly different purposes. The tarball from github simply contains all the files in the git repo. The tarball from keepalived.org has the files that are needed to build keepalived, without various housekeeping files such as .gitignore files, files for building snaps, travis-ci integration.

The keepalived.org tarball has some files generated by the automake/autoconf process, so that all that is needed to build keepalived from this tarball is ./configure; make. To build keepalived from the gihub tarball it is necessary to have automake and autoconf installed and to run autogen.sh before running ./configure; make.

Whichever tarball you use to build keepalived should build exactly the same keepalived binary.

A third way to build keepalived is to clone the github repo, checkout v2.1.5 or whichever version you want, and build from that.

The only difference between the binaries may be the first line of output of keepalived -v.

[acassen]

Will double check keepalived.org website conf

[linkvt]

I only had a rough look and am mostly unfamiliar with C and its build tools, but the explanation makes totally sense to me, thanks @pqarmitage ! Also thanks for checking that quickly!

[linkvt]

@acassen , Edit: I checked the wrong cipher suite, it is correctly part of TLS 1.2, my bad. It seems that it is somehow correct to have this cipher suite with TLS 1.2 but every major site I checked didn't have it at first position, see e.g. for Github: https://www.ssllabs.com/ssltest/analyze.html?d=github.com&hideResults=on I guess there is a reason they did it like that.

Edit: I found this list of recommended priorities for each Cipher Suite, https://wiki.mozilla.org/Security/Cipher_Suites the cipher suite TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 has prio 4, others should be above this one I guess.

[linkvt]

Hi @acassen, I don't want to sound too pushy but have you been able to check in this? It is probably only a minor configuration of the cipher suite order. Thanks!

[acassen]

was a certbot issue. I did update conf to only support TLSv1.2 & TLSv1.3 which are the new TLS recommanded and upgraded version present into certbot. testing with ssllabs.com sounds nice.

[linkvt]

Thanks looks great now, my build in Github Actions also works!

nmap --script ssl-enum-ciphers -p 443 keepalived.org
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-14 10:14 WET
Nmap scan report for keepalived.org (91.121.30.175)
Host is up (0.15s latency).
rDNS record for 91.121.30.175: ns300325.ip-91-121-30.eu

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 5.11 seconds