202156 2019-09-24 12:29:10 -0700 [GTK][WPE] Unable to load page due TLS errors on a website that doesn't support anything better than TLS1.0/3DES 2019-09-27 08:24:52 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED WONTFIX https://bugs.webkit.org/show_bug.cgi?id=172154 https://clientes.tautoradio.com/tracking/localizadorweb.aspx P2 Normal --- 1 svillar clopez bugs-noreply cgarcia clopez ddkilzer mcatanzaro ross.kirsling oldest_to_newest 1573748 0 svillar 2019-09-24 12:29:10 -0700 - Steps to reproduce: Load https://clientes.tautoradio.com/tracking/localizadorweb.aspx - Expected result: Page loads - Actual result: Error page is shown with the error "Peer failed to perform TLS handshake" This is pretty bad, we are not loading pages because a very basic thing like https negotiation is not working as expected. I filed a similar bug recently (https://bugs.webkit.org/show_bug.cgi?id=201380) although in that case the page was "loaded" although it was blank because the subresources could not be loaded. In this case not even the main document is loaded. The problem is very likely located in the underlying networking/cryptographic libraries. I guess we should reevaluate at some point our networking stack choices. 1574010 1 clopez 2019-09-25 03:44:19 -0700 That website has very insecure TLS settings. Firefox shows a warning, but connects fine. Chrome connects without showing any warning (I'm surprised about that) This is what the site provides: $ nmap --script ssl-enum-ciphers -p 443 clientes.tautoradio.com Starting Nmap 7.70 ( https://nmap.org ) at 2019-09-25 12:38 CEST Nmap scan report for clientes.tautoradio.com (91.117.124.94) Host is up (0.0085s latency). rDNS record for 91.117.124.94: 94.124.117.91.static.reverse-mundo-r.com PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E | compressors: | NULL | cipher preference: server | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher DES vulnerable to SWEET32 attack | 64-bit block cipher RC2 vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | CBC-mode cipher in SSLv3 (CVE-2014-3566) | Ciphersuite uses MD5 for message integrity | TLSv1.0: | ciphers: | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_DES_CBC_SHA (rsa 2048) - C | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA - D | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA - D | TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E | TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E | compressors: | NULL | cipher preference: server | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher DES vulnerable to SWEET32 attack | 64-bit block cipher RC2 vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity |_ least strength: E Nmap done: 1 IP address (1 host up) scanned in 1.27 seconds So basically: TLS-1.0 and SSLv3 with weak ciphers (3DES/DES/RC2) On a modern distro (Debian 10) All the tools I tried refuse to connect with that site due to that insecure settings. To enumerate them: $ curl https://clientes.tautoradio.com curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to clientes.tautoradio.com:443 $ wget https://clientes.tautoradio.com --2019-09-25 12:40:55-- https://clientes.tautoradio.com/ Resolving clientes.tautoradio.com (clientes.tautoradio.com)... 91.117.124.94 Connecting to clientes.tautoradio.com (clientes.tautoradio.com)|91.117.124.94|:443... connected. GnuTLS: The TLS connection was non-properly terminated. Unable to establish SSL connection. $ gnutls-cli -p 443 clientes.tautoradio.com Processed 124 CA certificate(s). Resolving 'clientes.tautoradio.com:443'... Connecting to '91.117.124.94:443'... *** Fatal error: The TLS connection was non-properly terminated. $ openssl s_client -CApath /etc/ssl/certs/ -showcerts -connect clientes.tautoradio.com:443 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 325 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- However on an old version of Debian (Debian 8) the tools work because Debian 8 was released years ago when such TLS setting were still considered acceptable This is what gnutls-cli and openssl s_client say about that site when ran from Debian 8: $ gnutls-cli -p 443 clientes.tautoradio.com Processed 152 CA certificate(s). Resolving 'clientes.tautoradio.com'... Connecting to '91.117.124.94:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `L=CORUÑA (A),serialNumber=A15080773,OU=SISTEMAS,O=TRANSPORTES AUTO-RADIO S.A.,CN=*.tautoradio.com,C=ES', issuer `C=ES,OU=AC CAMERFIRMA,O=AC Camerfirma S.A.,serialNumber=A82743287,L=Madrid (see current address at https://www.camerfirma.com/address),CN=Camerfirma Corporate Server II - 2015', RSA key 2048 bits, signed using RSA-SHA256, activated `2018-12-27 13:55:18 UTC', expires `2019-12-27 13:55:18 UTC', SHA-1 fingerprint `4c5dbce981e460303b2f7050da2dd7903f37d039' Public Key ID: 47566945cd16d0e43840bf65a5eeb98a21164291 Public key's random art: +--[ RSA 2048]----+ | .. .o.=*=o| | E. .= oo=| | . o. +.= | | . o .= | | . S . .. | | . o . . | | o . o | | . . o . | | . ... | +-----------------+ - Certificate[1] info: - subject `C=ES,OU=AC CAMERFIRMA,O=AC Camerfirma S.A.,serialNumber=A82743287,L=Madrid (see current address at https://www.camerfirma.com/address),CN=Camerfirma Corporate Server II - 2015', issuer `C=EU,L=Madrid (see current address at www.camerfirma.com/address),serialNumber=A82743287,O=AC Camerfirma S.A.,CN=Chambers of Commerce Root - 2008', RSA key 4096 bits, signed using RSA-SHA256, activated `2015-01-15 09:21:16 UTC', expires `2037-12-15 09:21:16 UTC', SHA-1 fingerprint `fe727a78ea0c0335cdda9c2ed75fd4d46f35c2ef' - Status: The certificate is trusted. - Description: (TLS1.0)-(RSA)-(3DES-CBC)-(SHA1) - Session ID: 8A:18:00:00:8C:47:2B:53:AB:99:85:DF:40:07:CE:14:15:D7:EA:15:A1:04:55:30:4B:04:2A:39:6E:2A:DB:88 - Version: TLS1.0 - Key Exchange: RSA - Cipher: 3DES-CBC - MAC: SHA1 - Compression: NULL - Options: safe renegotiation, - Handshake was completed - Simple Client Mode: $ openssl s_client -CApath /etc/ssl/certs/ -connect clientes.tautoradio.com:443 CONNECTED(00000003) depth=2 C = EU, L = Madrid (see current address at www.camerfirma.com/address), serialNumber = A82743287, O = AC Camerfirma S.A., CN = Chambers of Commerce Root - 2008 verify return:1 depth=1 C = ES, OU = AC CAMERFIRMA, O = AC Camerfirma S.A., serialNumber = A82743287, L = Madrid (see current address at https://www.camerfirma.com/address), CN = Camerfirma Corporate Server II - 2015 verify return:1 depth=0 L = CORU\C3\91A (A), serialNumber = A15080773, OU = SISTEMAS, O = TRANSPORTES AUTO-RADIO S.A., CN = *.tautoradio.com, C = ES verify return:1 --- Certificate chain 0 s:/L=CORU\xC3\x91A (A)/serialNumber=A15080773/OU=SISTEMAS/O=TRANSPORTES AUTO-RADIO S.A./CN=*.tautoradio.com/C=ES i:/C=ES/OU=AC CAMERFIRMA/O=AC Camerfirma S.A./serialNumber=A82743287/L=Madrid (see current address at https://www.camerfirma.com/address)/CN=Camerfirma Corporate Server II - 2015 1 s:/C=ES/OU=AC CAMERFIRMA/O=AC Camerfirma S.A./serialNumber=A82743287/L=Madrid (see current address at https://www.camerfirma.com/address)/CN=Camerfirma Corporate Server II - 2015 i:/C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008 --- Server certificate -----BEGIN CERTIFICATE----- MIIIsTCCBpmgAwIBAgIJHKrTNSgZfHNRMA0GCSqGSIb3DQEBCwUAMIHTMQswCQYD VQQGEwJFUzEWMBQGA1UECwwNQUMgQ0FNRVJGSVJNQTEbMBkGA1UECgwSQUMgQ2Ft ZXJmaXJtYSBTLkEuMRIwEAYDVQQFEwlBODI3NDMyODcxSzBJBgNVBAcMQk1hZHJp ZCAoc2VlIGN1cnJlbnQgYWRkcmVzcyBhdCBodHRwczovL3d3dy5jYW1lcmZpcm1h LmNvbS9hZGRyZXNzKTEuMCwGA1UEAwwlQ2FtZXJmaXJtYSBDb3Jwb3JhdGUgU2Vy dmVyIElJIC0gMjAxNTAeFw0xODEyMjcxMzU1MThaFw0xOTEyMjcxMzU1MThaMIGL MRQwEgYDVQQHDAtDT1JVw5FBIChBKTESMBAGA1UEBRMJQTE1MDgwNzczMREwDwYD VQQLDAhTSVNURU1BUzEkMCIGA1UECgwbVFJBTlNQT1JURVMgQVVUTy1SQURJTyBT LkEuMRkwFwYDVQQDDBAqLnRhdXRvcmFkaW8uY29tMQswCQYDVQQGEwJFUzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Qicpr4IhifY75VpzT6POvpwR/ nfIBduYZ3gZJnsRoeagGErBeqDAIrCDSksXxu0xVwwP70LFApEZweG5e6sqtjkD1 i8vsa1+y9ysjnC3J4U42a04k6pfSMAIxuaPMiSkAv7AvvlGAgZm16rBKpKQSepm3 QJ65Liz3lqH6c4OFSNeWvf+yBa962ywgOpTpMJtOnw19YdICiyhlnM8geFgEs3Yk E3fmLJK+as7hGXzDkr6FmXdIdVG+z6PKZj0K8P385RNYYmdMm51/GvDqg9uONhsl d6SQ3h/PiGc6ix+iqXupEF6RhMVh78+g6u8Lbwo9p3XjqGOkKryKQG5PIp8CAwEA AaOCA8wwggPIMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUkxpxebPVujXlcnm5Q5+n eyTLssIwggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdgCkuQmQtBhYFIe7E6LMZ3AK PDWYBPkb37jjd80OyA3cEAAAAWfv8rJLAAAEAwBHMEUCIE3tUPOhtwx7NkPDY11W WFmfk+hpUZcwLuWMZF83x0yyAiEAjPCNjTyButuPnVjNbeUNI+v/adglClclB97W 10A09KgAdgBvU3asMfAxGdiZAKRRFf93FRwR2QLBACkGjbIImjfZEwAAAWfv8ra/ AAAEAwBHMEUCICEdPL27xtjd/CKEd26tQPx6mX0d5Jy7EjeDrcDu3rjCAiEAsAbp q5mUxNXd/BTLWJwy75XJg7xya4x0eFW1InDImIMwgYEGCCsGAQUFBwEBBHUwczBJ BggrBgEFBQcwAoY9aHR0cDovL3d3dy5jYW1lcmZpcm1hLmNvbS9jZXJ0cy9jYW1l cmZpcm1hX2NzZXJ2ZXJpaS0yMDE1LmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29j c3AuY2FtZXJmaXJtYS5jb20wgeIGA1UdIwSB2jCB14AUY+nw8FYAaGWwIWwOXNcZ CJ0INGWhgbSkgbEwga4xCzAJBgNVBAYTAkVVMUMwQQYDVQQHEzpNYWRyaWQgKHNl ZSBjdXJyZW50IGFkZHJlc3MgYXQgd3d3LmNhbWVyZmlybWEuY29tL2FkZHJlc3Mp MRIwEAYDVQQFEwlBODI3NDMyODcxGzAZBgNVBAoTEkFDIENhbWVyZmlybWEgUy5B LjEpMCcGA1UEAxMgQ2hhbWJlcnMgb2YgQ29tbWVyY2UgUm9vdCAtIDIwMDiCCGIf 8xxIm6E2MIGJBgNVHR8EgYEwfzA9oDugOYY3aHR0cDovL2NybC5jYW1lcmZpcm1h LmNvbS9jYW1lcmZpcm1hX2NzZXJ2ZXJpaS0yMDE1LmNybDA+oDygOoY4aHR0cDov L2NybDEuY2FtZXJmaXJtYS5jb20vY2FtZXJmaXJtYV9jc2VydmVyaWktMjAxNS5j cmwwGwYDVR0RBBQwEoIQKi50YXV0b3JhZGlvLmNvbTBQBgNVHSAESTBHMDsGDCsG AQQBgYcuCgsCATArMCkGCCsGAQUFBwIBFh1odHRwczovL3BvbGljeS5jYW1lcmZp cm1hLmNvbTAIBgZngQwBAgIwDQYJKoZIhvcNAQELBQADggIBAKzBctG5m7Ihp5Cd Wvozkzvd8uMpFx89I2iw6SjHWZFwTGb2x1Ad4lgSARmbMEPezLyjuBbrL8CDMbYH s5CqBCmsMTZBy5RAIZOtbEnFQK9HhATx9ZKmoj/lUrVaXP3uQUI0ofhBvgciwFdv zcV2tZ/BLHYHQe6x5LgH1ZYoPL7Z/+eXIGSGFkYpCTXAdb0md/gB9cYehuzbUkWW ugOQb49RcAhXpXfTOnzR/8k9Ey9N93+q/e1RO/cFhQc6CSAuElAjYEj8eSubaous kPB/7634oyNOEORAscwSxFLAx0bHFmggGU9kmXGzZjCxYgT8E1FBt+zdf7xbh0+h YwA8Eac8nExCYkRokgvslTWNAqFkyuE6jqGTwMxaRPmrP7jq9cxWpzt9edORjSBB p7Y7kTuwVR6BG3vWQ2/P6pnCwNW/qoU9h8MCAVOWR29Zko9+k3rGgPuj7PJ1SKdT /unk5qrMM75ATzJj8nGBfJGCZF8GvxZ8ScrP/20nDfV+7LfN5CWRxrakdnFMZJWL g19aYXjsZrydBsFto67dw7l8dp83aoEmAtaPWoJNGsWvHDkpnD4NWWl8qiK88irG l7/mDnVXVsHbiM1uPw1Y+8tJSj+/ui+tL4Arhp3C5FGHZ7tK88bB7tZRFA2p6gZ2 pxh99udQkYHI8c5CNkxO/l2+3YQF -----END CERTIFICATE----- subject=/L=CORU\xC3\x91A (A)/serialNumber=A15080773/OU=SISTEMAS/O=TRANSPORTES AUTO-RADIO S.A./CN=*.tautoradio.com/C=ES issuer=/C=ES/OU=AC CAMERFIRMA/O=AC Camerfirma S.A./serialNumber=A82743287/L=Madrid (see current address at https://www.camerfirma.com/address)/CN=Camerfirma Corporate Server II - 2015 --- No client certificate CA names sent --- SSL handshake has read 4567 bytes and written 599 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: FE160000438F54E0E2E501B145C749FB9E9414682855C2252F8C0DA976A471A0 Session-ID-ctx: Master-Key: 178A30C532D2D5AC313EB91DE446A4D14DB94DE00366C22B9C01C830174CB7BCBA7AD33ECE53E55571B490C220873FB6 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1569408199 Timeout : 300 (sec) Verify return code: 0 (ok) --- 1574013 2 clopez 2019-09-25 03:48:44 -0700 Summarizing: * That site uses very insecure TLS settings, the best thing it supports its TLS-1.0 with 3DES (which is completely insecure nowadays). * I think this is not a webkitgtk issue. WebKit is simply using the system-wide crypto policy which nowadays forbid to use such insecure cipher suites. WebKit would work on an old distro with outdated crypto policy. * Not even curl on my system wants to connect to that site due to that poor TLS settings. * However, chrome and firefox still accept connecting with such settings. Not sure why. It will be better if they refused so the webmaster is forced to upgrade that server. 1574017 3 clopez 2019-09-25 04:26:25 -0700 Ok. It seems that I came to conclusions too fast. We do still support TLS-1.0 as you can check by opening the site: https://tls-v1-0.badssl.com:1010/ The issue is this site uses 3DES which gnutls has decided to disable long time ago by default: Check: https://gitlab.com/gnutls/gnutls/issues/120 By enabling it back I get gnutls-cli to connect. $ gnutls-cli --priority "NORMAL:+3DES-CBC" -p 443 clientes.tautoradio.com Processed 124 CA certificate(s). Resolving 'clientes.tautoradio.com:443'... Connecting to '91.117.124.94:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=ES,CN=*.tautoradio.com,O=TRANSPORTES AUTO-RADIO S.A.,OU=SISTEMAS,serialNumber=A15080773,L=CORUÑA (A)', issuer `CN=Camerfirma Corporate Server II - 2015,L=Madrid (see current address at https://www.camerfirma.com/address),serialNumber=A82743287,O=AC Camerfirma S.A.,OU=AC CAMERFIRMA,C=ES', serial 0x1caad33528197c7351, RSA key 2048 bits, signed using RSA-SHA256, activated `2018-12-27 13:55:18 UTC', expires `2019-12-27 13:55:18 UTC', pin-sha256="e2KHpkroiqqX4eM+6L8h+LWipNBpurEdmYYNY6RolNs=" Public Key ID: sha1:47566945cd16d0e43840bf65a5eeb98a21164291 sha256:7b6287a64ae88aaa97e1e33ee8bf21f8b5a2a4d069bab11d99860d63a46894db Public Key PIN: pin-sha256:e2KHpkroiqqX4eM+6L8h+LWipNBpurEdmYYNY6RolNs= - Certificate[1] info: - subject `CN=Camerfirma Corporate Server II - 2015,L=Madrid (see current address at https://www.camerfirma.com/address),serialNumber=A82743287,O=AC Camerfirma S.A.,OU=AC CAMERFIRMA,C=ES', issuer `CN=Chambers of Commerce Root - 2008,O=AC Camerfirma S.A.,serialNumber=A82743287,L=Madrid (see current address at www.camerfirma.com/address),C=EU', serial 0x621ff31c489ba136, RSA key 4096 bits, signed using RSA-SHA256, activated `2015-01-15 09:21:16 UTC', expires `2037-12-15 09:21:16 UTC', pin-sha256="m6nepCtxe9G9HhpXqQbCc7VSQX41KwYqD6LqFDqntKk=" - Status: The certificate is trusted. - Description: (TLS1.0)-(RSA)-(3DES-CBC)-(SHA1) - Session ID: 5E:22:00:00:5C:2D:07:33:9D:25:D4:0B:94:34:1D:69:1B:D5:26:8E:53:B8:D4:09:BD:24:08:74:49:76:1E:3D - Options: safe renegotiation, - Handshake was completed - Simple Client Mode: So, this is indeed something we can patch on WebKitGTK to override gnutls default policy in this regard. That Website seems to be running Microsoft-IIS/6.0 as webserver, which I imagine is running on some very old version of Windows. I'm a bit horrified. 1574028 4 379541 clopez 2019-09-25 06:03:35 -0700 Created attachment 379541 Patch 1574029 5 clopez 2019-09-25 06:10:58 -0700 (In reply to Carlos Alberto Lopez Perez from comment #4) > Created attachment 379541 [details] > Patch Ok. Seems patch doesn't apply because I had a checkout older than r250217 But I'm unsure if I should upload a new patch after reading the commit log of r250217 Michael: Are we OK with overriding GnuTLS settings in order to make WebKitGTK compatible with websites that Chrome and Firefox still support or not? 1574079 6 mcatanzaro 2019-09-25 09:33:19 -0700 (In reply to Carlos Alberto Lopez Perez from comment #5) > Michael: Are we OK with overriding GnuTLS settings in order to make > WebKitGTK compatible with websites that Chrome and Firefox still support or > not? Yes, we can consider it on a case-by-case basis as needed. But: * I'd rather do this at the glib-networking level. (You just noticed that I've removed the code that you patched here.) * Let's not do it for this website: this one should stay broken. If you can find a site that requires 3DES but doesn't require TLS 1.0, then we could consider restoring 3DES, but I'd really rather not. As of now, this is the only website I know to require 3DES. There's no point in trying to make this one work though, because we are disabling TLS 1.0, following all other major browsers. I just committed that change to glib-networking a couple days ago. Give it a couple months and you shouldn't be able to load this website anywhere anymore. So WONTFIX for this one. P.S. I can't load this site in Firefox; maybe Fedora's system crypto policy has 3DES disabled. It does work for me in Chrome, which probably ignores system policy. P.S.S. I've seen a lot, but I'm sure this is the very worst I've ever seen: https://www.ssllabs.com/ssltest/analyze.html?d=clientes.tautoradio.com. It still allows SSLv2 from Netscape Navigator era. :D 1574080 7 mcatanzaro 2019-09-25 09:39:56 -0700 Chrome: TLS 1.0 to be disabled January 2020: https://security.googleblog.com/2018/10/modernizing-transport-security.html Safari: March 2020: https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/ We will also be March 2020 (with glib-networking 2.64), or perhaps a bit later if this change moves to GnuTLS instead. It's theoretically possible some obscure website using TLS 1.2 accepts only 3DES, but it's sufficiently-unlikely that I'd rather not consider this unless we actually find one. 1574086 8 mcatanzaro 2019-09-25 09:50:43 -0700 (In reply to Sergio Villar Senin from comment #0) > This is pretty bad, we are not loading pages because a very basic thing like > https negotiation is not working as expected. I filed a similar bug recently > (https://bugs.webkit.org/show_bug.cgi?id=201380) although in that case the > page was "loaded" although it was blank because the subresources could not > be loaded. In this case not even the main document is loaded. That bug is on my TODO, but it is not a quick project and it depends on another large project. See the glib-networking bug I linked to for details. I'm really hoping to have it solved by the end of the year, but whether that happens depends on (a) how much longer I have to work on glib-networking, and (b) how well I use my time. > The problem is very likely located in the underlying > networking/cryptographic libraries. I guess we should reevaluate at some > point our networking stack choices. We just did this and decided to stick with libsoup. You can ask Patrick for his slides if you want details. If you switch to libcurl, we give up control over the TLS backend and have to support different backends on different distros (OpenSSL on Fedora, GnuTLS for freedesktop-sdk, etc.) and will need to solve the same bugs multiple times for 12 different curl backends. With libsoup/glib-networking, we have two backends and continue to control the entire stack. 1574090 9 clopez 2019-09-25 10:00:16 -0700 (In reply to Michael Catanzaro from comment #6) > (In reply to Carlos Alberto Lopez Perez from comment #5) > > Michael: Are we OK with overriding GnuTLS settings in order to make > > WebKitGTK compatible with websites that Chrome and Firefox still support or > > not? > > Yes, we can consider it on a case-by-case basis as needed. But: > > * I'd rather do this at the glib-networking level. (You just noticed that > I've removed the code that you patched here.) > * Let's not do it for this website: this one should stay broken. > Ok > If you can find a site that requires 3DES but doesn't require TLS 1.0, then > we could consider restoring 3DES, but I'd really rather not. As of now, this > is the only website I know to require 3DES. > From https://sweet32.info/#usage : > Firefox Telemetry Telemetry data from Mozilla Firefox show that Triple-DES is used for close to 1% of HTTPS connections from Firefox browsers (0.76% with beta 49). And Firefox 49 was released 3 years ago. Nowadays this number should be much lower. > There's no point in trying to make this one work though, because we are > disabling TLS 1.0, following all other major browsers. I just committed that > change to glib-networking a couple days ago. Give it a couple months and you > shouldn't be able to load this website anywhere anymore. So WONTFIX for this > one. > Ok. I agree with that. > P.S. I can't load this site in Firefox; maybe Fedora's system crypto policy > has 3DES disabled. It does work for me in Chrome, which probably ignores > system policy. > > P.S.S. I've seen a lot, but I'm sure this is the very worst I've ever seen: > https://www.ssllabs.com/ssltest/analyze.html?d=clientes.tautoradio.com. It > still allows SSLv2 from Netscape Navigator era. :D The server of this website seems to be running Windows XP / Windows Server 2003 or something even older. I'm surprised it has still not been hacked :\ 1574377 10 svillar 2019-09-26 00:52:21 -0700 (In reply to Michael Catanzaro from comment #7) > Chrome: TLS 1.0 to be disabled January 2020: > https://security.googleblog.com/2018/10/modernizing-transport-security.html > > Safari: March 2020: > https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/ > > We will also be March 2020 (with glib-networking 2.64), or perhaps a bit > later if this change moves to GnuTLS instead. > > It's theoretically possible some obscure website using TLS 1.2 accepts only > 3DES, but it's sufficiently-unlikely that I'd rather not consider this > unless we actually find one. Fair enough, I raised the issue because both Firefox and Chromium were loading it without any issue (nor even warning here in Debian). It's weird that none of them is showing at least a warning knowing that the deprecation is happening basically in a few months. Thanks for taking care! 1574449 11 mcatanzaro 2019-09-26 08:08:49 -0700 (In reply to Michael Catanzaro from comment #7) > Chrome: TLS 1.0 to be disabled January 2020: > https://security.googleblog.com/2018/10/modernizing-transport-security.html > > Safari: March 2020: > https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/ > > We will also be March 2020 (with glib-networking 2.64), or perhaps a bit > later if this change moves to GnuTLS instead. Firefox is also March 2020: https://groups.google.com/forum/#!msg/mozilla.dev.platform/8EFRYDR3N1c/gPh6v01ABAAJ Convenient that this just happens to align perfectly with our release schedule. 1574762 12 svillar 2019-09-27 02:02:04 -0700 I've just found out another example of the same issue https://www.todoconsolas.com 1574813 13 mcatanzaro 2019-09-27 08:24:52 -0700 Same situation: https://www.ssllabs.com/ssltest/analyze.html?d=www.todoconsolas.com It will soon be broken everywhere, so not worth worrying about at this point. 379541 2019-09-25 06:03:35 -0700 2019-09-25 09:23:09 -0700 Patch bug-202156-20190925150334.patch text/plain 3589 clopez U3VidmVyc2lvbiBSZXZpc2lvbjogMjUwMDM5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IDljNmVlN2VhMmE0MTlmMDJk YjljMDQxNzA0ZTQ4NmI1NjlkYjk5Y2UuLjM1Yzc1NWI2ZDRkYTMzZmM1MDNlYTY0MDhhOGFjMWY3 YzNkYjZiY2YgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMjcgQEAKKzIwMTktMDktMjUgIENhcmxvcyBB bGJlcnRvIExvcGV6IFBlcmV6ICA8Y2xvcGV6QGlnYWxpYS5jb20+CisKKyAgICAgICAgW0dUS11b V1BFXSBVbmFibGUgdG8gbG9hZCBwYWdlIGR1ZSBUTFMgZXJyb3JzIG9uIGEgd2Vic2l0ZSB0aGF0 IGRvZXNuJ3Qgc3VwcG9ydCBhbnl0aGluZyBiZXR0ZXIgdGhhbiBUTFMxLjAvM0RFUworICAgICAg ICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjAyMTU2CisKKyAgICAg ICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgQWx0b3VnaCBUTFMtMS4w IGlzIGRlcHJlY2F0ZWQgYW5kIGNvbnNpZGVyZWQgaW5zZWN1cmUgd2UgZG8gc3RpbGwgc3VwcG9y dCBpdCwKKyAgICAgICAgYW5kIHdlIHNob3VsZCBzdGlsbCB0cnkgdG8gc3VwcG9ydCBpdCBtZWFu d2hpbGUgdGhlIG1ham9yIGJyb3dzZXJzIGRvLgorCisgICAgICAgIEhvd2V2ZXIsIHdlIGRvbid0 IHN1cHBvcnQgdGhlIDNERVMgY2lwaGVyIGZvciBUTFMtMS4wIGJlY2F1c2UgR251VExTIGRpc2Fi bGVzCisgICAgICAgIGl0IGJ5IGRlZmF1bHQgKGl0cyBhbHNvIGNvbnNpZGVyZWQgaW5zZWN1cmUp LgorCisgICAgICAgIEJ1dCBpdCBzZWVtcyBvbGQgd2luZG93cyBzZXJ2ZXJzIChydW5uaW5nIGZv ciBleGFtcGxlIE1pY3Jvc29mdC1JSVMvNi4wKSBhcmUKKyAgICAgICAgdW5hYmxlIHRvIGVuY3J5 cHQgd2l0aCBhbnl0aGluZyBiZXR0ZXIgdGhhbiB0aGF0LgorCisgICAgICAgIFNpbmNlIENocm9t ZSBhbmQgRmlyZWZveCBzdGlsbCBzdXBwb3J0IFRMUy0xLjAvQUVTLCB3ZSBzaG91bGQgdHJ5IHRv IGRvIGFzIHdlbGwuCisgICAgICAgIFRoaXMgcGF0Y2ggb3ZlcnJpZGVzIEdudVRMUyBkZWZhdWx0 IHNldHRpbmdzIGluIG9yZGVyIHRvIGVuYWJsZSAzREVTIGZvciBUTFMtMS4wLgorCisgICAgICAg ICogTmV0d29ya1Byb2Nlc3MvRW50cnlQb2ludC91bml4L05ldHdvcmtQcm9jZXNzTWFpbi5jcHA6 CisgICAgICAgIChtYWluKToKKyAgICAgICAgKiBXZWJQcm9jZXNzL0VudHJ5UG9pbnQvdW5peC9X ZWJQcm9jZXNzTWFpbi5jcHA6CisgICAgICAgIChtYWluKToKKwogMjAxOS0wOS0xOCAgQ2FybG9z IEFsYmVydG8gTG9wZXogUGVyZXogIDxjbG9wZXpAaWdhbGlhLmNvbT4KIAogICAgICAgICBbR1RL XVtXUEVdIGJ1YmJsZXdyYXAgc2FuZGJveCBzaG91bGQgYmUgZGlzYWJsZWQgd2hlbiBydW5uaW5n IGluc2lkZSBkb2NrZXIKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvTmV0d29ya1Byb2Nlc3Mv RW50cnlQb2ludC91bml4L05ldHdvcmtQcm9jZXNzTWFpbi5jcHAgYi9Tb3VyY2UvV2ViS2l0L05l dHdvcmtQcm9jZXNzL0VudHJ5UG9pbnQvdW5peC9OZXR3b3JrUHJvY2Vzc01haW4uY3BwCmluZGV4 IDczNmMwMTcwOGE0NjY5ODY5OWEwODM5YTcxNDc3ZTJhNGE0ODNkYTcuLmRmMmI5MWI1YTJlMzNm ZTUwMmU2MjdjZmI2ZTE2YTZmNThlZGU5ZjMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvTmV0 d29ya1Byb2Nlc3MvRW50cnlQb2ludC91bml4L05ldHdvcmtQcm9jZXNzTWFpbi5jcHAKKysrIGIv U291cmNlL1dlYktpdC9OZXR3b3JrUHJvY2Vzcy9FbnRyeVBvaW50L3VuaXgvTmV0d29ya1Byb2Nl c3NNYWluLmNwcApAQCAtNDMsNyArNDMsOCBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhcioqIGFy Z3YpCiAgICAgLy8gb3ZlcndyaXRlIHRoaXMgcHJpb3JpdHkgc3RyaW5nIGlmIGl0J3MgYWxyZWFk eSBzZXQgYnkgdGhlIHVzZXIuCiAgICAgLy8gaHR0cHM6Ly9idWd6aWxsYS5nbm9tZS5vcmcvc2hv d19idWcuY2dpP2lkPTczODYzMwogICAgIC8vIFdBUk5JTkc6IFRoaXMgbmVlZHMgdG8gYmUgS0VQ VCBJTiBTWU5DIHdpdGggV2ViUHJvY2Vzc01haW4uY3BwLgotICAgIHNldGVudigiR19UTFNfR05V VExTX1BSSU9SSVRZIiwgIk5PUk1BTDolQ09NUEFUOiFWRVJTLVNTTDMuMDohQVJDRk9VUi0xMjgi LCAwKTsKKyAgICAvLyBOT1RFOiArM0RFUy1DQkMgaXMgZm9yIHN1cHBvcnRpbmcgb2xkIFdpbmRv d3Mgc2VydmVycyB3aXRoIFRMUzEuMDogU2VlIGh0dHBzOi8vd2Via2l0Lm9yZy9iLzIwMjE1Ngor ICAgIHNldGVudigiR19UTFNfR05VVExTX1BSSU9SSVRZIiwgIk5PUk1BTDolQ09NUEFUOiFWRVJT LVNTTDMuMDohQVJDRk9VUi0xMjg6KzNERVMtQ0JDIiwgMCk7CiAKICNpZiBVU0UoR0NSWVBUKQog ICAgIFBBTDo6R0NyeXB0Ojppbml0aWFsaXplKCk7CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0 L1dlYlByb2Nlc3MvRW50cnlQb2ludC91bml4L1dlYlByb2Nlc3NNYWluLmNwcCBiL1NvdXJjZS9X ZWJLaXQvV2ViUHJvY2Vzcy9FbnRyeVBvaW50L3VuaXgvV2ViUHJvY2Vzc01haW4uY3BwCmluZGV4 IGVlZGQ0NDI1YjdmZWY2OGJlODc2OWM5OTBkMTU3NWZkNWZjZWU2NjcuLmEwZjQxMGNlZDkzMzFm Nzg0MWFiNDk3OTcyNDJhN2U1OGExMTk5OTQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvV2Vi UHJvY2Vzcy9FbnRyeVBvaW50L3VuaXgvV2ViUHJvY2Vzc01haW4uY3BwCisrKyBiL1NvdXJjZS9X ZWJLaXQvV2ViUHJvY2Vzcy9FbnRyeVBvaW50L3VuaXgvV2ViUHJvY2Vzc01haW4uY3BwCkBAIC00 Miw4ICs0Miw5IEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyKiogYXJndikKICAgICAvLyBHbnVU TFMgb3Igc2ltcGx5IHN0b3BzIHBhcnNpbmcgdGhpcyB2YXJpYWJsZS4gV2UgaW50ZW50aW9uYWxs eSBkbyBub3QKICAgICAvLyBvdmVyd3JpdGUgdGhpcyBwcmlvcml0eSBzdHJpbmcgaWYgaXQncyBh bHJlYWR5IHNldCBieSB0aGUgdXNlci4KICAgICAvLyBodHRwczovL2J1Z3ppbGxhLmdub21lLm9y Zy9zaG93X2J1Zy5jZ2k/aWQ9NzM4NjMzCi0gICAgLy8gV0FSTklORzogVGhpcyBuZWVkcyB0byBi ZSBLRVBUIElOIFNZTkMgd2l0aCBXZWJQcm9jZXNzTWFpbi5jcHAuCi0gICAgc2V0ZW52KCJHX1RM U19HTlVUTFNfUFJJT1JJVFkiLCAiTk9STUFMOiVDT01QQVQ6IVZFUlMtU1NMMy4wOiFBUkNGT1VS LTEyOCIsIDApOworICAgIC8vIFdBUk5JTkc6IFRoaXMgbmVlZHMgdG8gYmUgS0VQVCBJTiBTWU5D IHdpdGggTmV0d29ya1Byb2Nlc3NNYWluLmNwcC4KKyAgICAvLyBOT1RFOiArM0RFUy1DQkMgaXMg Zm9yIHN1cHBvcnRpbmcgb2xkIFdpbmRvd3Mgc2VydmVycyB3aXRoIFRMUzEuMDogU2VlIGh0dHBz Oi8vd2Via2l0Lm9yZy9iLzIwMjE1NgorICAgIHNldGVudigiR19UTFNfR05VVExTX1BSSU9SSVRZ IiwgIk5PUk1BTDolQ09NUEFUOiFWRVJTLVNTTDMuMDohQVJDRk9VUi0xMjg6KzNERVMtQ0JDIiwg MCk7CiAKICNpZiBVU0UoR0NSWVBUKQogICAgIFBBTDo6R0NyeXB0Ojppbml0aWFsaXplKCk7Cg==