curl SSLv3 alert handshake failure when accessing the website from Ubuntu 20.04

[hpages]

Hi,

This fails with Ubuntu 20.04:

curl https://rfam.xfam.org
#curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

but works fine with Ubuntu < 20.04 and on Windows and macOS Mojave.

This seems to happen with some websites because of a combination of three reasons: server misconfiguration, increased TLS security level in Ubuntu 20.04 by default, and a bug in OpenSSL 1.1.1. See https://github.com/Ensembl/ensembl-rest/issues/427 for a similar issue with the Ensembl server.

FWIW this breaks Bioconductor package rfaRm: https://bioconductor.org/checkResults/3.12/bioc-LATEST/rfaRm/nebbiolo1-install.html

Internally the package tries to access rfam.xfam.org with the following R code:

> library(xml2)

> read_xml("https://rfam.xfam.org/clans")
Error in open.connection(x, "rb") :
  error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

> sessionInfo()
R version 4.0.2 Patched (2020-08-04 r78971)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS

Matrix products: default
BLAS:   /home/hpages/R/R-4.0.r78971/lib/libRblas.so
LAPACK: /home/hpages/R/R-4.0.r78971/lib/libRlapack.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] xml2_1.3.2

loaded via a namespace (and not attached):
[1] compiler_4.0.2 curl_4.3      

Thanks! H.

[AntonPetrov]

Thank you for reporting this! Judging by Ensembl/ensembl-rest#427 there is not a whole lot we can do at Rfam right now to fix this issue.

If you are interested, I can point you to alternative ways of accessing the data that do not rely on rfam.xfam.org, such as the public MySQL database, the EBI Search, or the FTP archive (ftp://ftp.ebi.ac.uk/pub/databases/Rfam). Please let me know if we can help. Thanks again!

[hpages]

There is a certificate problem for the xfam.org domain:

hpages@spectre:~$ gnutls-cli -p 443 xfam.org | grep -B1 broken
- Certificate[3] info:
 - subject `C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority', issuer `C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority', RSA key 2048 bits, signed using RSA-SHA1 (broken!), activated `2004-06-29 17:06:20 UTC', expires `2034-06-29 17:06:20 UTC', SHA-1 fingerprint `2796bae63f1801e277261ba0d77770028f20eee4'

I don't control how Bioconductor packages or other software access the rfam website. Just reporting that all the tools that access it via curl are now broken on Ubuntu 20.04 because of this certificate problem. Addressing this on the server side would be much easier than refactoring a bunch of existing code.

Thanks, H.

[AntonPetrov]

Thank you for this info - I will look into this and update this issue with my progress. Many thanks for providing the detailed error report!

[hpages]

Hi @AntonPetrov , have you been able to look into this? Thanks!

[AntonPetrov]

@hpages I am sorry, there is no progress on this yet. I will update the issue once I hear back from the folks maintaining the Rfam SSL certificates. Thank you!

[AntonPetrov]

@hpages I was informed that adding the --ciphers DEFAULT@SECLEVEL=1 option to curl should fix the problem in Ubuntu 20.04. Sorry that it took so long to get a potential solution.

[hpages]

Hi @AntonPetrov ,

Thanks for the suggestion. Yes, there are a few workarounds that are available on the client side. However, as mentioned previously, I don't control how Bioconductor packages or other software access the rfam website which is why addressing the problem on the server side would be great.

Anyway, it seems that the rfaRm maintainer has managed to implement a workaround in their package so as far as Bioconductor is concerned, the problem is solved.

Thanks!