Difficult to debug ssl/tls alert handshake failure for servers using old ciphers #1054

New Issue

2026-10-05T05:00:41+02:00

adam commented

2026-10-05 05:00:41 +02:00

When a remote IRC server is using old SSLCiphers, connections fail only with a ssl/tls alert handshake failure message and none of the SSL/TLS options in the network's web config UI are able to workaround it. The only way to workaround this is to manually modify SSLCiphers in the global ZNC configuration which is both opaque and unnecessarily reduces the security of connections to most other servers.

While most servers support modern and "intermediate" ciphers, it's not rare for a user's required use case to involve connecting to old IRC networks whose servers do not; IRC is an old protocol after all. One can connect to these servers using $ irssi by setting tls_verify = "no"; on a per-server basis, but none of ZNC's per-network SSL/TLS options can workaround this. I don't know if that's because $ irssi tolerates less secure ciphers for all servers, but regardless it would be better if ZNC provided some per-network or per-server way to expand the list of accepted ciphers. Perhaps when TrustAllCerts = true, ZNC should use a more expansive set of ciphers for just that network? Or maybe just all the ciphers supported by whatever library ZNC uses? Then even for less technical users they can have the less surprising experience of seeing a message about SSL/TLS and just checking the Trust all certs checkbox to workaround it.

Without such an option, the only remaining workaround for users who must connect to such old servers is the global SSLCiphers option. While that option is documented, there's nothing to point users there from the errors encountered. I'm not an expert in SSL/TLS but I'm not unfamiliar and it took way too long to get to the bottom of this. I tried all the combinations of the per-network SSL/TLS options including fingerprints. It's especially confusing if a server does any load balancing and some the back-ends support different cipher sets, because then the error is intermittent. I tried various googling and finally stumbled on a reddit reply that pointed me to the root cause and workaround. So I would call it a first priority to give more details when an SSL/TLS handshake fails, certainly when the --debug CLI option is used. At the very least something somewhere should connect the ssl/tls alert handshake failure message to the SSLCiphers option even if just in documentation.

When a remote IRC server is using old `SSLCiphers`, connections fail only with a `ssl/tls alert handshake failure` message and none of the SSL/TLS options in the network's web config UI are able to workaround it. The only way to workaround this is to [manually modify `SSLCiphers` in the global ZNC configuration](https://www.reddit.com/r/irc/comments/1fkw6zj/comment/lo0gzhb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) which is both opaque and unnecessarily reduces the security of connections to most other servers. While most servers support modern and "intermediate" ciphers, it's not rare for a user's required use case to involve connecting to old IRC networks whose servers do not; IRC is an old protocol after all. One can connect to these servers using `$ irssi` by setting `tls_verify = "no";` on a per-server basis, but none of ZNC's per-network SSL/TLS options can workaround this. I don't know if that's because `$ irssi` tolerates less secure ciphers for all servers, but regardless it would be better if ZNC provided some per-network or per-server way to expand the list of accepted ciphers. Perhaps when `TrustAllCerts = true`, ZNC should use [a more expansive set of ciphers](https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility) for just that network? Or maybe just all the ciphers supported by whatever library ZNC uses? Then even for less technical users they can have the less surprising experience of seeing a message about SSL/TLS and just checking the `Trust all certs` checkbox to workaround it. Without such an option, the only remaining workaround for users who must connect to such old servers is the global `SSLCiphers` option. While [that option is documented](https://wiki.znc.in/Configuration#Global), there's nothing to point users there from the errors encountered. I'm not an expert in SSL/TLS but I'm not unfamiliar and it took way too long to get to the bottom of this. I tried all the combinations of the per-network SSL/TLS options including fingerprints. It's especially confusing if a server does any load balancing and some the back-ends support different cipher sets, because then the error is intermittent. I tried various googling and finally stumbled on [a reddit reply that pointed me to the root cause and workaround](https://www.reddit.com/r/irc/comments/1fkw6zj/comment/lo0gzhb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button). So I would call it a first priority to give more details when an SSL/TLS handshake fails, certainly when the `--debug` CLI option is used. At the very least something somewhere should connect the `ssl/tls alert handshake failure` message to the `SSLCiphers` option even if just in documentation.

adam commented

2026-10-05 05:00:42 +02:00

For others working around this, I ended up copying the "Old backward compatibility" set of ciphers and that seems to workaround all the instances of this issue I've run into so far. At the time of writing that is:

SSLCiphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA

Shutdown ZNC, add that line to the global section of **/znc.conf, and restart ZNC.

For others working around this, I ended up copying the ["Old backward compatibility" set of ciphers](https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility) and that seems to workaround all the instances of this issue I've run into so far. At the time of writing that is: ``` SSLCiphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA ``` Shutdown ZNC, add that line to the global section of `**/znc.conf`, and restart ZNC.

adam commented

2026-10-05 05:00:43 +02:00

Concretely, I ran into this yesterday with the slashnet server while using weechat, after upgrading from 1.7.5 to 1.10.1

17:53:44 *status | Disconnected from IRC (error:0A000410:SSL routines::ssl/tls alert handshake failure). Reconnecting..
17:53:44 *status | Disconnected from IRC. Reconnecting...
17:54:13 *status | Disconnected from IRC (error:0A000410:SSL routines::ssl/tls alert handshake failure). Reconnecting..
17:54:13 *status | Disconnected from IRC. Reconnecting...

I've also documented on my own site for visibility (1) for others, as it took a wee while to find @rpatterson's excellent and well-referenced issue here with the workaround- thanks for doing so 🙂

Concretely, I ran into this yesterday with the [slashnet](https://www.slashnet.org/) server while using weechat, after upgrading from 1.7.5 to 1.10.1 ```log 17:53:44 *status | Disconnected from IRC (error:0A000410:SSL routines::ssl/tls alert handshake failure). Reconnecting.. 17:53:44 *status | Disconnected from IRC. Reconnecting... 17:54:13 *status | Disconnected from IRC (error:0A000410:SSL routines::ssl/tls alert handshake failure). Reconnecting.. 17:54:13 *status | Disconnected from IRC. Reconnecting... ``` I've also documented on my own site for visibility ([1]) for others, as it took a wee while to find @rpatterson's excellent and well-referenced issue here with the workaround- thanks for doing so 🙂 [1]: https://blog.roberthallam.org/2025/08/solved-ssl-tls-alert-handshake-failure-in-znc/

adam commented

2026-10-05 05:00:43 +02:00

+1 from me too. the workaround works fine.
though if this could be done via the web interface (so without shutdown), that would be great. :)

(one more thing: it would be great to set these via network only as obviously this concerns just a few networks, not all)

+1 from me too. the workaround works fine. though if this could be done via the web interface (so without shutdown), that would be great. :) (one more thing: it would be great to set these via network only as obviously this concerns just a few networks, not all)

adam commented

2026-10-05 05:00:44 +02:00

Just ran into this recently too. I just updated my box to the latest Debian which subsequently upgraded my ZNC and openssl libraries. Since updating I can no longer connect to GeekShed IRC. They run an older ircd version. I would rather not connect via plaintext, as before the update my ZNC connected via SSL just fine.

Just ran into this recently too. I just updated my box to the latest Debian which subsequently upgraded my ZNC and openssl libraries. Since updating I can no longer connect to GeekShed IRC. They run an older ircd version. I would rather not connect via plaintext, as before the update my ZNC connected via SSL just fine.

adam commented

2026-10-05 05:00:45 +02:00

@GTAXL : you dont have to use plaintext, just use the workaround provided above.
( the znc.conf - SSLCiphers one )

@GTAXL : you dont have to use plaintext, just use the workaround provided above. ( the znc.conf - SSLCiphers one )

adam commented

2026-10-05 05:00:46 +02:00

@GTAXL : you dont have to use plaintext, just use the workaround provided above. ( the znc.conf - SSLCiphers one )

I know, I'm going to do that. I'm just saying it still would be nice that I didn't have to do that and an option existed on a per-network basis. It'd also be nice if all networks upgraded their ircd after a certain amount of time, but we don't live in a perfect world.

> [@GTAXL](https://github.com/GTAXL) : you dont have to use plaintext, just use the workaround provided above. ( the znc.conf - SSLCiphers one ) I know, I'm going to do that. I'm just saying it still would be nice that I didn't have to do that and an option existed on a per-network basis. It'd also be nice if all networks upgraded their ircd after a certain amount of time, but we don't live in a perfect world.

adam commented

2026-10-05 05:00:46 +02:00

ah yeah, i see.
exactly my comment from 01Oct2025 :)

ah yeah, i see. exactly my comment from 01Oct2025 :)

adam commented

2026-10-05 05:00:47 +02:00

/me is getting real frustrated

/me is getting real frustrated

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#1054

Difficult to debug ssl/tls alert handshake failure for servers using old ciphers #1054

Difficult to debug `ssl/tls alert handshake failure` for servers using old ciphers #1054