Bug 202156 – [GTK][WPE] Unable to load page due TLS errors on a website that doesn't support anything better than TLS1.0/3DES

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

[Sergio Villar Senin]

- 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.

[Carlos Alberto Lopez Perez]

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]

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]

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]

Created attachment 379541 [details]
Patch

[Carlos Alberto Lopez Perez]

(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]

(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]

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]

(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]

(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]

(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]

(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]

I've just found out another example of the same issue https://www.todoconsolas.com

[Michael Catanzaro]

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.