Vivaldi not syncing

irz

@DoctorG sorry I forgot to click the reply button, please see my last post.

DoctorG

@irz said in Vivaldi only syncing when on VPN:

So I suspect that Chromium-based browsers on my devices (Debian 12) are forcing TLSv1.3 for any connection

I do not know that Debian 12 forces TLSv1.3.
And i do not know that Vivaldi forces TLSv1.3 for Sync connects.

DoctorG

@irz @kaleh @LazyLama How have you installed Vivaldi?
Snap-, Deb- or Flatpak-package?

irz

@DoctorG It's not about Vivaldi. It's about Chromium-based
I install and upgrade Vivaldi via .deb and apt upgrade

LazyLama

@DoctorG said in Vivaldi only syncing when on VPN:

@irz said in Vivaldi only syncing when on VPN:

So I suspect that Chromium-based browsers on my devices (Debian 12) are forcing TLSv1.3 for any connection

I do not know that Debian 12 forces TLSv1.3.
And i do not know that Vivaldi forces TLSv1.3 for Sync connects.

I installed Vivaldi from a deb package downloaded from the Vivaldi website.

@irz, great detective work. For now, I have an sh script on my computer that runs the curl command before running Vivaldi. I could update the script to call Vivaldi using the command-line options you suggested. Or can TLSv1.3 be disabled somewhere in the settings?

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.