[bug] Broken TLS 1.2 ciphers: ECDHE-RSA-CHACHA20-POLY1305 and ECDHE-ECDSA-CHACHA20-POLY1305
Apologies if I do not report this correctly. This is my first contribution to Alpine.
Alpine version: 3.10
Package & version: openssl 1.1.1d
Summary: Using cipher ECDHE-RSA-CHACHA20-POLY1305 or ECDHE-ECDSA-CHACHA20-POLY1305 in the cipher list (it is one of the defaults) causes SSL handshake to timeout after initial client write- even if there are other valid ciphers further down in the list.
Reproduce:
openssl s_client -connect google.com:443 -state -nbio -tls1_2
hangs after
CONNECTED(00000003)
Turned on non blocking io
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:error in SSLv3/TLS write client hello
write R BLOCK
Removing ECDHE-RSA-CHACHA20-POLY1305 & ECDHE-ECDSA-CHACHA20-POLY1305 from the list causes openssl to connect successfully.
openssl s_client -connect google.com:443 -state -nbio -tls1_2 -cipher ALL:!ECDHE-RSA-CHACHA20-POLY1305:!ECDHE-ECDSA-CHACHA20-POLY1305
Google.com supports both of these ciphers (I can connect with them via openssl 1.1.1 on Ubuntu 18.04.2). Experiments with other servers that do not support them leads me to believe that IF the openssl client 1.1.1d on Alphine 3.10 offers one of these ciphers AND the server chooses one of them THEN the connection will hang after streaming "write R BLOCK" to stderr.
(Note that I'm providing openssl examples because they are simple to run. Our actual issue is with PHP curl requests timing out and I've narrowed it down to this TLS handshake problem. Forcing curl to use TLS 1.2 with Google also shows the issue: curl https://google.com --tls-max 1.2 -v
)