Vivaldi not syncing

DoctorG

@LazyLama said in Vivaldi only syncing when on VPN:

Or can TLSv1.3 be disabled somewhere in the settings?

Not in Vivaldis normal settings.

Have you changed something in vivaldi://flags ?

LazyLama

@DoctorG said in Vivaldi only syncing when on VPN:

Have you changed something in vivaldi://flags ?

No. I didn't even know that existed

DoctorG

@LazyLama OK, nothing changed. Fine.

Why i asked? Some users change there and forget after a while they did a change.

DoctorG

@irz said in Vivaldi only syncing when on VPN:

It's not about Vivaldi. It's about Chromium-based

Then there is a startup setting made by a program (not Vivaldi!) in folder /etc/chromium which could causes the forced TLS 1.3.

irz

@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

LazyLama

@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 :).

DoctorG

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

irz

Finally I have found the culprit
Just turn chrome://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 )

LazyLama

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

kaleh

@DoctorG
I installed Vivaldi Snapshot through the AUR, after I discovered the problem with Vivaldi stable. The problem occurs with stable and snapshot.

irz

@LazyLama If you set the flag to default and sync works perfectly, don't

kaleh

@irz Thank you so much! This seems to solve it!
@LazyLama For me, it is only working with TLS1.3-Kyber disabled.

DoctorG

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

Pathduck

@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/CSCwj82736

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

DoctorG

Appliances (and software?) from SonicWall and Palo Alto have similar issues with broken TLS.

DoctorG

@irz Nice find. you get a

Pathduck

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.

mib2berlin

@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

Pathduck

@mib2berlin Yes, that's why I wrote:
"as long as the server supports it"

Bifrost does not support TLS1.3.

DoctorG

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