WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
202156
[GTK][WPE] Unable to load page due TLS errors on a website that doesn't support anything better than TLS1.0/3DES
https://bugs.webkit.org/show_bug.cgi?id=202156
Summary
[GTK][WPE] Unable to load page due TLS errors on a website that doesn't suppo...
Sergio Villar Senin
Reported
Tuesday, September 24, 2019 8:29:10 PM UTC
- 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.
Attachments
Patch
(3.50 KB, patch)
2019-09-25 06:03 PDT
,
Carlos Alberto Lopez Perez
mcatanzaro
: review-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Carlos Alberto Lopez Perez
Comment 1
Wednesday, September 25, 2019 11:44:19 AM UTC
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) ---
Carlos Alberto Lopez Perez
Comment 2
Wednesday, September 25, 2019 11:48:44 AM UTC
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.
Carlos Alberto Lopez Perez
Comment 3
Wednesday, September 25, 2019 12:26:25 PM UTC
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.
Carlos Alberto Lopez Perez
Comment 4
Wednesday, September 25, 2019 2:03:35 PM UTC
Created
attachment 379541
[details]
Patch
Carlos Alberto Lopez Perez
Comment 5
Wednesday, September 25, 2019 2:10:58 PM UTC
(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?
Michael Catanzaro
Comment 6
Wednesday, September 25, 2019 5:33:19 PM UTC
(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
Michael Catanzaro
Comment 7
Wednesday, September 25, 2019 5:39:56 PM UTC
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.
Michael Catanzaro
Comment 8
Wednesday, September 25, 2019 5:50:43 PM UTC
(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.
Carlos Alberto Lopez Perez
Comment 9
Wednesday, September 25, 2019 6:00:16 PM UTC
(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 :\
Sergio Villar Senin
Comment 10
Thursday, September 26, 2019 8:52:21 AM UTC
(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!
Michael Catanzaro
Comment 11
Thursday, September 26, 2019 4:08:49 PM UTC
(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.
Sergio Villar Senin
Comment 12
Friday, September 27, 2019 10:02:04 AM UTC
I've just found out another example of the same issue
https://www.todoconsolas.com
Michael Catanzaro
Comment 13
Friday, September 27, 2019 4:24:52 PM UTC
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug