Vivaldi not syncing
-
@irz said in Vivaldi only syncing when on VPN:
@LazyLama Or you could add the curl command as a crontab running per 5 mins or 10 mins or more longer, so that you don't need any scripts
Genius
Maybe I'll do that :). -
Vivaldi Sync server bifrost.vivaldi.com connects now with TLSv1.2 and TLSv1.3.
A few hours ago its was only TLSv1.2 – weird servers.//EDIT: Now, no connect with TLSv1.3 again
Perhaps i accidentally checked bifrost.vivaldi.net instead bifrost.vivaldi.com. -
Finally I have found the culprit
Just turnchrome://flags/#enable-tls13-kyber
to disabled if you have encountered this issue
From https://www.reddit.com/r/sysadmin/comments/1carvpd/chrome_124_breaks_tls_handshake/
(And yes, I'm also one of the poor soul ) -
@irz said in Vivaldi only syncing when on VPN:
Just turn chrome://flags/#enable-tls13-kyber to disabled if you have encountered this issue
Does this still need to be done even though @DoctorG said the following?
️Vivaldi Sync server bifrost.vivaldi.com connects now with TLSv1.2 and TLSv1.3.
A few hours ago its was only TLSv1.2 – weird servers. -
-
@LazyLama If you set the flag to default and sync works perfectly, don't
-
-
@kaleh said in Vivaldi only syncing when on VPN:
it is only working with TLS1.3-Kyber disabled
Strangeness on your Linuxes. Vivaldi Browser should downgrade to TLSv1.2 if TLSv1.3 is not available.
-
@irz Great detective work
I tried running the Py script linked to from the https://tldr.fail document. It seems to work fine with Bifrost:
$ python tldr_fail_test.py bifrost.vivaldi.com About to send a large TLS ClientHello (1482 bytes) to bifrost.vivaldi.com:443. The server should respond with a TLS ServerHello, which will be some byte string beginning with b'\x16\x03\x03'. If it closes the connection or sends something else, the server is misbehaving. Sending the ClientHello in a single write: b"\x16\x03\x03\x00E\x02\x00\x00A\x03\x03\xaf\n\x0b\x0c\xccB@;$S\x99&*\x82\x13:\xe1l&\xce\xbd\x94\x0e\x05\x85A\t\x01S\xa1\x1c\x9d\x00\xc00\x00\x00\x19\xff\x01\x00\x01\x00\x00\x00\x00\x00\x00\x0b\x00\x04\x03\x00\x01\x02\x00#\x00\x00\x00\x17\x00\x00\x16\x03\x03\n\x0f\x0b\x00\n\x0b\x00\n\x08\x00\x04\xf90\x82\x04\xf50\x82\x03\xdd\xa0\x03\x02\x01\x02\x02\x12\x04\xf9\xa4\xb4\xe9\\aM\x10\xd0\x9b\xe3\xd2\xc8\xd5.\xa5\xfe0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x00031\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x160\x14\x06\x03U\x04\n\x13\rLet's Encrypt1\x0c0\n\x06\x03U\x04\x03\x13\x03R100\x1e\x17\r240825054037Z\x17\r241123054036Z0\x1e1\x1c0\x1a\x06\x03U\x04\x03\x13\x13bifrost.vivaldi.com0\x82" Sending the ClientHello in two separate writes: b"\x16\x03\x03\x00E\x02\x00\x00A\x03\x03\x87N\x1d\xcc\xc2\x7f\x83\xba\x1d\xb1\x1c\x12\xc2\xe9D$\x04\xc1\xd4\xf2\x97\x052`w\xbe\x0e\x1d\xa0\x8e\x9e%\x00\xc00\x00\x00\x19\xff\x01\x00\x01\x00\x00\x00\x00\x00\x00\x0b\x00\x04\x03\x00\x01\x02\x00#\x00\x00\x00\x17\x00\x00\x16\x03\x03\n\x0f\x0b\x00\n\x0b\x00\n\x08\x00\x04\xf90\x82\x04\xf50\x82\x03\xdd\xa0\x03\x02\x01\x02\x02\x12\x04\xf9\xa4\xb4\xe9\\aM\x10\xd0\x9b\xe3\xd2\xc8\xd5.\xa5\xfe0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x00031\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x160\x14\x06\x03U\x04\n\x13\rLet's Encrypt1\x0c0\n\x06\x03U\x04\x03\x13\x03R100\x1e\x17\r240825054037Z\x17\r241123054036Z0\x1e1\x1c0\x1a\x06\x03U\x04\x03\x13\x13bifrost.vivaldi.com0\x82" Repeating the process with a smaller ClientHello (260 bytes). This ClientHello would usually be sent in a single packet, but it demonstrates that the bug is not triggered by the size of the ClientHello, but whether it comes in across multiple reads. (Note this ClientHello is smaller than a ClientHello from browsers today. This script does not reproduce some padding behavior.) Sending the ClientHello in a single write: b"\x16\x03\x03\x00E\x02\x00\x00A\x03\x03k\xd3b\x8b\x90=\xc2\x15\xeb<\xac\x84e\xb3\t\x88\xbbj\x81ac\xdc\x9f\x95\xc1[\xf7}?\xde\x1d\xd6\x00\xc00\x00\x00\x19\xff\x01\x00\x01\x00\x00\x00\x00\x00\x00\x0b\x00\x04\x03\x00\x01\x02\x00#\x00\x00\x00\x17\x00\x00\x16\x03\x03\n\x0f\x0b\x00\n\x0b\x00\n\x08\x00\x04\xf90\x82\x04\xf50\x82\x03\xdd\xa0\x03\x02\x01\x02\x02\x12\x04\xf9\xa4\xb4\xe9\\aM\x10\xd0\x9b\xe3\xd2\xc8\xd5.\xa5\xfe0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x00031\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x160\x14\x06\x03U\x04\n\x13\rLet's Encrypt1\x0c0\n\x06\x03U\x04\x03\x13\x03R100\x1e\x17\r240825054037Z\x17\r241123054036Z0\x1e1\x1c0\x1a\x06\x03U\x04\x03\x13\x13bifrost.vivaldi.com0\x82" Sending the ClientHello in two separate writes: b"\x16\x03\x03\x00E\x02\x00\x00A\x03\x03Jz\xa7W4\xf2\xb6\xef\xb5\xbb\x80\x99\x82\xa1\xdb\x82:R.\x08r\x95/2\xfd\x91*w|HX\x99\x00\xc00\x00\x00\x19\xff\x01\x00\x01\x00\x00\x00\x00\x00\x00\x0b\x00\x04\x03\x00\x01\x02\x00#\x00\x00\x00\x17\x00\x00\x16\x03\x03\n\x0f\x0b\x00\n\x0b\x00\n\x08\x00\x04\xf90\x82\x04\xf50\x82\x03\xdd\xa0\x03\x02\x01\x02\x02\x12\x04\xf9\xa4\xb4\xe9\\aM\x10\xd0\x9b\xe3\xd2\xc8\xd5.\xa5\xfe0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x0b\x05\x00031\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x160\x14\x06\x03U\x04\n\x13\rLet's Encrypt1\x0c0\n\x06\x03U\x04\x03\x13\x03R100\x1e\x17\r240825054037Z\x17\r241123054036Z0\x1e1\x1c0\x1a\x06\x03U\x04\x03\x13\x13bifrost.vivaldi.com0\x82"
My guess this is caused by faulty firewalls/routers, most likely Cisco as per the document.
https://quickview.cloudapps.cisco.com/quickview/bug/CSCwj82736Users here are also reporting TIMEOUTs not connection close/resets. So the connection gets "stuck" in the router, the connection never completes and times out.
As to why the connection works for some time after triggering a curl request, I have no idea...
-
Appliances (and software?) from SonicWall and Palo Alto have similar issues with broken TLS.
-
@irz Nice find. you get a
-
Using a newer version (7.80) of curl it should be possible to force a TLS1.3 connection with these "Post-Quantum" ciphers as long as the server supports it.
Ref: https://daniel.haxx.se/blog/2021/10/04/post-quantum-curl/
$ curl -V curl 8.10.1 (x86_64-pc-cygwin) libcurl/8.10.1 OpenSSL/3.0.15 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.61.0 libgsasl/2.2.1 OpenLDAP/2.6.8 Release-Date: 2024-09-18 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd $ curl -Iv4 --tlsv1.3 --curves X25519 https://www.vivaldi.com/ * Host www.vivaldi.com:443 was resolved. * IPv6: (none) * IPv4: 172.67.21.227, 104.22.59.199, 104.22.58.199 * Trying 172.67.21.227:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
If people with this problem could try the above, it might show the same issue of a timed out connection. Bifrost of course, does not support TLS1.3.
-
@Pathduck
Hi, if you do this with https://bifrost.vivaldi.com you get an error:* TLSv1.3 (IN), TLS alert, handshake failure (552): * OpenSSL/3.1.4: error:0A000410:SSL routines::sslv3 alert handshake failure
-
@mib2berlin Yes, that's why I wrote:
"as long as the server supports it"
Bifrost does not support TLS1.3.
-
@mib2berlin The bifrost.vivaldi.com has no TLSv1.3 enabled, i already reported this in internal tracker.
You can check with sslscan which server is able to connect with.
-
@DoctorG said in Vivaldi only syncing when on VPN:
The bifrost.vivaldi.com has no TLSv1.3 enabled, i already reported this in internal tracker.
Even if Bifrost had enabled TLS1.3 it wouldn't help these users with timeouts, as I believe the problem is not on the server but incompatible firewall/router with these new ciphers.
-
@Pathduck Yes, i believe it is hardware router/appliance issue.
-
ZZalex108 moved this topic from Vivaldi for Linux on
-
Hi,
Check about this:
https://forum.vivaldi.net/topic/101158/vivaldi-sync-wont-work-after-using-a-vpn-linux/7 -
I ran into the same problem where sync under Linux works from my home but not from my office or public cellular networks. Running Vivaldi 7.0 downloaded from the website.
Disabling TLS 1.3 post-quantum key agreement
allowed sync to work from all networks.Thanks for the detective work!
-
@genosensor said in Vivaldi not syncing:
Disabling TLS 1.3 post-quantum key agreement
Already known and caused by very bad hardware (router, security appliances, hardware firewalls in companies).