Bug 300584 – TLS handshake fails in Epiphany (WebKitGTK) when connecting to specific HTTPS servers after upgrading OpenSSL from 3.5.4 to 3.6.0

• Status: RESOLVED
• Resolution: MOVED
• Component: WebKitGTK

[Óscar]

After upgrading OpenSSL from version 3.5.4 to 3.6.0 on Arch Linux, Epiphany fails to establish HTTPS connections with some servers due to a TLS handshake error.
The issue does not occur with other browsers (e.g. Firefox or Chromium), and it only affects Epiphany / WebKitGTK-based clients.
The same server works perfectly when the system is rolled back to OpenSSL 3.5.4.

This suggests a possible interoperability or regression issue between WebKitGTK’s TLS layer (potentially via GnuTLS or OpenSSL provider bindings) and OpenSSL 3.6.0.

Steps to reproduce:

1. Use Arch Linux (up to date as of October 2025).
2. Ensure OpenSSL 3.6.0 is installed.
3. Install and configure nginx with a simple self-signed TLS certificate.
4. Launch Epiphany (version 49.1, using WebKitGTK 2.50.1).
5. Open https://localhost/ in Epiphany.

Actual result:
Epiphany shows an SSL/TLS error 'Peer failed to perform TLS handshake: Error decoding the received TLS packet.'

Expected result:
Epiphany should successfully load the test page as it does when OpenSSL 3.5.4 is used.

Additional information:
Distro: Arch Linux (up-to-date)
Epiphany: 49.1
WebKitGTK: 2.50.1
OpenSSL: 3.6.0 (regression compared to 3.5.4)
nginx: latest Arch package, linked against OpenSSL 3.6.0
Other browsers tested:
  Firefox / Chromium → OK
  Epiphany (WebKitGTK) → handshake fails

[Michael Catanzaro]

The TLS backend is provided by glib-networking. glib-networking supports use of both GnuTLS and OpenSSL, but the OpenSSL backend isn't good enough for most users and therefore is not built by default. Arch follows upstream defaults: it builds only the GnuTLS backend. So, did you build your own glib-networking? So somehow manually install it? Try `ls /usr/lib64/gio/modules`, you should see libgiognutls.so and no libgioopenssl.so.

If you report a bug on https://gitlab.gnome.org/GNOME/glib-networking/issues then it's worth debugging to see what has gone wrong, since the OpenSSL backend ought to work. But I also strongly recommend using GnuTLS unless you have a reason to not do so.

Also worth checking to see whether OpenSSL works when used directly without glib-networking involved: `openssl s_client -connect localhost:443`

[Óscar]

No, I haven't compiled anything myself. I use all official Arch Linux packages. The test I did was simply to roll back the OpenSSL package from 3.6.0 to 3.5.4 on my server, restart nginx, and everything works. If I update OpenSSL back to 3.6.0, restart nginx, and test it, the issue mentioned above reappears.

Updating OpenSSL affects the nginx server in some way and causes the handshake to not work correctly in WebKitGTK (tested in Epiphany and with applications such as Cinny, which also uses WebKitGTK).

From here on, I can't tell you whether OpenSSL, nginx, WebKitGTK, or something else is to blame. The only thing I can guarantee is that with the other browsers I've tried (mainly Firefox and Chromium), or with tools like curl, everything works correctly.

[Michael Catanzaro]

OK, so WebKit isn't using OpenSSL at all, but the problem is caused by the *server* is using OpenSSL. Which is not ideal, since that's surely most of the web....

[Adrian Perez]

(In reply to Michael Catanzaro from comment #3)
> OK, so WebKit isn't using OpenSSL at all, but the problem is caused by the
> *server* is using OpenSSL. Which is not ideal, since that's surely most of
> the web....

But note that the reporter indicates that other browsers (Firefox, Chromium) work
fine and can connect to that server after it started using OpenSSL 3.6.0 -- so it
looks like we have a libsoup, or glib-networking, or WebKit bug.

I've added Patrick in CC, as he's been maintaining libsoup / glib-networking,
in case he has something to add.

[Michael Catanzaro]

I think this is probably a bug in either GnuTLS or OpenSSL. A bug in glib-networking is also possible, but less likely.

Next step here is to figure out what changed in OpenSSL. I don't see anything suspicious in the release notes. We'll probably need to bisect it, but unfortunately this is going to require running a web server and building OpenSSL, steps that I'm not familiar with. If this problem starts to affect websites, then we'll have a pretty strong incentive to learn how. :D

[Óscar]

I've been running various tests with different browsers and utilities, and the results are interesting:

- Epiphany: KO (which we already knew)
- Firefox: Work
- Chromium/e: Work
- curl: Work
- wget: KO!
- aria2: KO!
- Simple rust code with reqwest (uses OpenSSL): Work
- Another simple rust code with ureq (rustls): Work
- httpie: Work
- nmap is capable of listing ciphers

The fact that it fails with wget and aria2 makes me suspect that it may be a conflict between OpenSSL and GnuTLS, since in Arch wget is compiled with the latter.

[Michael Catanzaro]

And aria2 is also using GnuTLS. So we can be pretty confident the problem is either in GnuTLS or in OpenSSL, one or the other.

[Óscar]

(In reply to Michael Catanzaro from comment #7)
> And aria2 is also using GnuTLS. So we can be pretty confident the problem is
> either in GnuTLS or in OpenSSL, one or the other.

Yes, it looks like what you're saying. I've opened a bug report in GnuTLS [1], commenting on it to see what they say.

[1]: https://gitlab.com/gnutls/gnutls/-/issues/1746

[Michael Catanzaro]

Conclusion is: OpenSSL bug, see https://github.com/openssl/openssl/issues/28902#issuecomment-3407052303

[Óscar]

Yes, it seems that the problem is finally in OpenSSL. Thank you all very much for your help!