Project

General

Profile

Actions

Task #3187

closed

CrashReport: Handshake failure

Added by Xisco Fauli Tarazona almost 4 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Tags:

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

wireshark.tar.gz (24 KB) wireshark.tar.gz Xisco Fauli Tarazona, 2020-04-16 19:25
Actions #1

Updated by Guilhem Moulin almost 4 years ago

  • Assignee set to Guilhem Moulin
Actions #2

Updated by Guilhem Moulin almost 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.

Actions #3

Updated by Florian Effenberger over 3 years ago

  • Status changed from New to Rejected

Rejecting this one, as proposed

Actions

Also available in: Atom PDF