Vivaldi not syncing

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.

Pathduck

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

DoctorG

@Pathduck Yes, i believe it is hardware router/appliance issue.

Zalex108

Hi,
Check about this:
https://forum.vivaldi.net/topic/101158/vivaldi-sync-wont-work-after-using-a-vpn-linux/7

genosensor

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!

DoctorG

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

genosensor

I worked at this .org for 24 years
Network access is very open here in comparison with most large companies.
I have NO other issues with access to other public sites and services from the corporate net.

There may well be something here that is not standards compliant, but, I suspect, this breakage is very common.

I'm willing to help pinpoint the issue if you can provide some tests to run at my end.

Weirdly, I found that sync would NOT connect even if tethering to my T-Mobile phone.