Task #3187
closedCrashReport: Handshake failure
0%
Description
When LibreOffice crashes in a release build, it asks the user to send a crashreport the next time LibreOffice is launched. Once the crashreport is sent, the dialog displays the crash's url. For a couple of months now, this url is never displayed in my case, although crashreports from other users are still sent to the server. Surprisingly, it works with an older version of LibreOffice ( version 5.3.7.2 ) but not with a more recent one ( version 6.4.2.2 ). I'm using Win 7 on virtualbox
Attach you can see the wireshark logs from both versions.
Files
Updated by Guilhem Moulin about 4 years ago
Surprisingly, it works with an older version of LibreOffice ( version 5.3.7.2 )
This works because older releases used plaintext HTTP.
but not with a more recent one ( version 6.4.2.2 ). I'm using Win 7 on virtualbox
$ ssldump -r /tmp/failure.pcapng New TCP connection #1: 10.0.2.15(49218) <-> vm171.documentfoundation.org(443) 1 1 0.0509 (0.0509) C>S Handshake ClientHello Version 3.3 cipher suites TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_MD5 compression methods NULL extensions server_name host_name: crashreport.libreoffice.org signature_algorithms […]
Seems cipher negotiation fails. We're using the “intermediate” suite suggested by Mozilla ( https://ssl-config.mozilla.org/#server=nginx&version=1.14.2&config=intermediate&openssl=1.1.1d&guideline=5.4 ):
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
Weirdly enough your SSL/TLS library speaks only GCM with ECDSA certificates, not RSA. RC4 is insecure and we removed support from CBC (per Mozilla profile) on March 5; this was done after a 1 month long analysis to ensure it would cause minimal disruption:
Metrics results based on 14 days worth of requests show the old profile is in fact not really required: 3 TLSv1.1 (0.00%) 52 TLSv1 (0.02%) 18793 cleartext (6.25%) 40057 TLSv1.3 (13.31%) 242011 TLSv1.2 (80.42%) 95 insecure (0.03%) 300916 total
So in the course of this 14 days test period, only 95/300916 (0.03%) clients (maybe all yours? :-P) would fail to connect using the new Intermediated profile (removing support for TLS <1.2 and lecacy ciphers).
Given Windows 7 is EOL now I'm unsure it's worth trying to find a workaround; that said since your SSL/TLS library can speak modern modes (GCM) there might be a way to enable it for RSA, not only ECDSA. Maybe the Antivirus is messing around with the SSL handshake? At least Qualys SSL labs claims it should work with Windows 7. (Also clients not able to speak recent enough TLS versions — 1.2 is from 2008 — or modern ciphers will have more and more trouble to browse websites.)
Anyway, keeping support for <12 year old TLS versions and/or legacy ciphers is a security nightmare and given the above metrics I'm tempted to call this wontfix on the infra side.
Updated by Florian Effenberger over 3 years ago
- Status changed from New to Rejected
Rejecting this one, as proposed