Support STARTTLS between ZNC and server. [$10] #363

New Issue

2026-10-05T04:15:30+02:00

adam commented

2026-10-05 04:15:30 +02:00

After a few days of researching, I've found out that ZNC while it does act on the numeric for STARTTLS.

It actually never sends the "STARTTLS" Command to start the connection. If the server reports "tls" in CAP LS, znc should send "STARTTLS" to the IRC server and then the IRC server will respond with the raw numeric and znc should in theory finish it from there.

There is a $10 open bounty on this issue. Add to the bounty at Bountysource.

After a few days of researching, I've found out that ZNC while it does act on the numeric for STARTTLS. It actually never sends the "STARTTLS" Command to start the connection. If the server reports "tls" in CAP LS, znc should send "STARTTLS" to the IRC server and then the IRC server will respond with the raw numeric and znc should in theory finish it from there. ## <bountysource-plugin> There is a **[$10 open bounty](https://www.bountysource.com/issues/3337817-support-starttls-between-znc-and-server-10?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

2026-10-05 04:15:30 +02:00

adam commented

2026-10-05 04:15:31 +02:00

AFAIK ZNC does NOT support STARTTLS, because we can't really make sure that nothing else sends anything between STARTTLS and the reply to STARTTLS. If that were to happen, the SSL connection would break.

(Why do we handle that numeric at all? :-/)

AFAIK ZNC does NOT support STARTTLS, because we can't really make sure that nothing else sends anything between STARTTLS and the reply to STARTTLS. If that were to happen, the SSL connection would break. (Why do we handle that numeric at all? :-/)

adam commented

2026-10-05 04:15:32 +02:00

because we can't really make sure that nothing else sends anything between STARTTLS and the reply to STARTTLS.

Other clients must be able to handle this.

> because we can't really make sure that nothing else sends anything between STARTTLS and the reply to STARTTLS. Other clients must be able to handle this.

adam commented

2026-10-05 04:15:33 +02:00

@md-5 ZNC is the client in this case. Perhaps need a separate bug for the other side.

What ZNC can send to server in between:

some modules can send anything
some client sends ZNC message to a channel, and core passes it through to server
PING if ZNC didn't get anything from server for a while
PONG if server pinged ZNC before replying to STARTTLS
etc

@md-5 ZNC is the client in this case. Perhaps need a separate bug for the other side. What ZNC can send to server in between: - some modules can send anything - some client sends ZNC message to a channel, and core passes it through to server - PING if ZNC didn't get anything from server for a while - PONG if server pinged ZNC before replying to STARTTLS - etc

adam commented

2026-10-05 04:15:33 +02:00

@DarthGandalf my point being, STARTTLS must be possible, otherwise it wouldn't exist. ZNC just needs the necessary changes :)

@DarthGandalf my point being, STARTTLS must be possible, otherwise it wouldn't exist. ZNC just needs the necessary changes :)

adam commented

2026-10-05 04:15:34 +02:00

Given the tls spec which contains the STARTTLS command is deprecated, perhaps this feature request should be closed.

As per https://ircv3.net/specs/extensions/tls-3.1:

This specification has been deprecated. We do not recommend implementing this specification or the features described here.

This extension has been deprecated in favour of encouraging IRC networks to use implicit TLS and deploy Strict Transport Security instead. This is in alignment with the recommendations given in RFC 8314.

Given the tls spec which contains the STARTTLS command is deprecated, perhaps this feature request should be closed. As per https://ircv3.net/specs/extensions/tls-3.1: > This specification has been deprecated. We do not recommend implementing this specification or the features described here. > This extension has been deprecated in favour of encouraging IRC networks to use implicit TLS and deploy Strict Transport Security instead. This is in alignment with the recommendations given in RFC 8314.

adam commented

2026-10-05 04:15:35 +02:00

support STARTTLS or no, what is this than:

https://github.com/znc/znc/commit/a25316710d807019f99e3407ffda2e4a87a1f913

support STARTTLS or no, what is this than: https://github.com/znc/znc/commit/a25316710d807019f99e3407ffda2e4a87a1f913

adam commented

2026-10-05 04:15:36 +02:00

That's a partial implementation of it.

That's a partial implementation of it.

adam commented

2026-10-05 04:15:36 +02:00

Ok good. Got confused about the deprecation comment. I do not understand how-to be able to send the STARTTLS to server if even actually possible? If the response is implemented.

I tried around with the send_raw module to send STARTTLS command to IRC server but does not upgrade connections to secure connection..

Ok good. Got confused about the deprecation comment. I do not understand how-to be able to send the `STARTTLS` to server if even actually possible? If the response is implemented. I tried around with the send_raw module to send **STARTTLS** command to IRC server but does not upgrade connections to secure connection..

adam commented

2026-10-05 04:15:37 +02:00

Probably something else is missing?

Note that STARTTLS support was never finished, so it's not supported. Feel free to debug it though. But even if you manage to make it work, we probably won't accept the patch, due to this in the spec:

We do not recommend implementing this specification or the features described here.

Probably something else is missing? Note that STARTTLS support was never finished, so it's not supported. Feel free to debug it though. But even if you manage to make it work, we probably won't accept the patch, due to this in the spec: > We do not recommend implementing this specification or the features described here.

adam commented

2026-10-05 04:15:38 +02:00

Probably something else is missing?

I guess I do it wrong way. Not sure how-to get that enabled. Also this Ideally should be the first that is send to server before anything else get send before connection upgrade to TLS.

Sad. would rather try the connection to optimistically encryption wherever possible than no encryption at all where cleartext.

Than unfortunately this security feature is dead.

BUT THANKS ANYWAY FOR CONFIRMING.

> Probably something else is missing? > I guess I do it wrong way. Not sure how-to get that enabled. Also this Ideally should be the first that is send to server before anything else get send before connection upgrade to TLS. Sad. would rather try the connection to optimistically encryption wherever possible than no encryption at all where cleartext. Than unfortunately this security feature is dead. BUT THANKS ANYWAY FOR CONFIRMING.

adam commented

2026-10-05 04:15:38 +02:00

May be worth considering sts - strict transport security instead, there is a potential module included in the comments of https://github.com/znc/znc/issues/1647 which may be used for ZNC<>Client upgrades.

May be worth considering [sts - strict transport security](https://ircv3.net/specs/extensions/sts.html) instead, there is a potential module included in the comments of https://github.com/znc/znc/issues/1647 which may be used for ZNC<>Client upgrades.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#363