Support for SNI (client→ZNC side) #514

New Issue

2026-10-05T04:26:23+02:00

adam commented

2026-10-05 04:26:23 +02:00

ZNC should use SSL_set_tlsext_host_name and the related OpenSSL APIs to indicate the expected server name, so TLS can work as expected with DNS round robins (assuming properly-configured servers, which is a big assumption… but hey, can't hurt to be some of the first ones to be well-behaved)

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/11700800-support-for-sni-client-znc-side?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

ZNC should use `SSL_set_tlsext_host_name` and the related OpenSSL APIs to indicate the expected server name, so TLS can work as expected with DNS round robins (assuming properly-configured servers, which is a big assumption… but hey, can't hurt to be some of the first ones to be well-behaved) ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/11700800-support-for-sni-client-znc-side?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:26:24 +02:00

What would be the use of it in IRC?
With HTTP, this is needed, because HTTP servers support multiple sites one the same IP.

Round robins work already. E.g. all servers of irc.freenode.net have valid certificate for *.freenode.net

What would be the use of it in IRC? With HTTP, this is needed, because HTTP servers support multiple sites one the same IP. Round robins work already. E.g. all servers of `irc.freenode.net` have valid certificate for `*.freenode.net`

adam commented

2026-10-05 04:26:25 +02:00

An IRC server might accept connections on multiple hostnames. For instance, one very common practice is to have one master hostname (irc.<network>.net or the like) that routes to any of a network's servers, and also have each individual server have its own hostname. SNI support would allow servers to return either a cert for the round-robin domain, or for their individual name, depending on what the client's asking for.

An IRC server might accept connections on multiple hostnames. For instance, one very common practice is to have one master hostname (`irc.<network>.net` or the like) that routes to any of a network's servers, and also have each individual server have its own hostname. SNI support would allow servers to return either a cert for the round-robin domain, or for their individual name, depending on what the client's asking for.

adam commented

2026-10-05 04:26:26 +02:00

Why would client want to sometimes connect to any server in the network, and sometimes to some specific server, which has a different hostname, so that wildcard cert doesn't work for such different hostname?

Why would client want to sometimes connect to any server in the network, and sometimes to some specific server, which has a different hostname, so that wildcard cert doesn't work for such different hostname?

adam commented

2026-10-05 04:26:26 +02:00

On Apr 21, 2015, at 14:31, Alexey Sokolov notifications@github.com wrote:

What would be the use of it in IRC?
With HTTP, this is needed, because HTTP servers support multiple sites one the same IP.

—
Reply to this email directly or view it on GitHub.

There is no need for it.

SNI is a web server thing. IRC servers are only permitted to serve the one hostname/cert combo if I remember right.

And for ZNC webadmin there is no need for it as znc.pem is a singular file, and it could only serve one very (if I am wrong on that let me know).

> On Apr 21, 2015, at 14:31, Alexey Sokolov notifications@github.com wrote: > > What would be the use of it in IRC? > With HTTP, this is needed, because HTTP servers support multiple sites one the same IP. > > — > Reply to this email directly or view it on GitHub. There is no need for it. SNI is a web server thing. IRC servers are only permitted to serve the one hostname/cert combo if I remember right. And for ZNC webadmin there is no need for it as znc.pem is a singular file, and it could only serve one very (if I am wrong on that let me know).

adam commented

2026-10-05 04:26:27 +02:00

And to answer the parts that only just hit my email, @DarthGandalf, there are some IRC networks with disjointed hostname a which end up having different certs, or private networks which have no wildcard, and other 'edge cases'.

I still don't see a value in enabling SNI which is a web server thing usually.

And to answer the parts that only just hit my email, @DarthGandalf, there are some IRC networks with disjointed hostname a which end up having different certs, or private networks which have no wildcard, and other 'edge cases'. I still don't see a value in enabling SNI which is a web server thing usually.

adam commented

2026-10-05 04:26:28 +02:00

I think this should possibly be reconsidered based on https://github.com/ircv3/ircv3-specifications/pull/155.

I think this should possibly be reconsidered based on https://github.com/ircv3/ircv3-specifications/pull/155.

adam commented

2026-10-05 04:26:28 +02:00

IPv4 address scarcity is one reason someone might do this. ZNC already has a web server in it, so it's already serving the purpose of multiplexing multiple services on a single port, so it seems to me it should be obvious why someone would want to do more of that. Another reason is, let's say you've deployed two ZNC instances, each of which serves a workgroup, and you are merging the workgroups together; telling 30 people to update their client configurations - and of course everybody uses a different client - to use a different hostname so that their clients don't pop up annoying cert-error connection failures is a lot harder than just updating one bouncer's configuration.

IPv4 address scarcity is one reason someone might do this. ZNC already _has_ a web server in it, so it's already serving the purpose of multiplexing multiple services on a single port, so it seems to me it should be obvious why someone would want to do more of that. Another reason is, let's say you've deployed two ZNC instances, each of which serves a workgroup, and you are merging the workgroups together; telling 30 people to update their client configurations - and of course everybody uses a different client - to use a different hostname so that their clients don't pop up annoying cert-error connection failures is a lot harder than just updating one bouncer's configuration.

adam commented

2026-10-05 04:26:29 +02:00

SNI is in no way only a "web server thing" (although as I mentioned, it shouldn't matter, because znc is already a web server). It is a basic part of supporting a modern TLS feature suite and should be supported by ZNC just as part of normal SSL configuration, the same way you just can't skip supporting certificate chains or cipher suite configuration, even though neither of those really has anything to do with IRC specifically.

SNI is in no way only a "web server thing" (although as I mentioned, it shouldn't matter, because znc is already a web server). It is a basic part of supporting a modern TLS feature suite and should be supported by ZNC just as part of normal SSL configuration, the same way you just can't skip supporting certificate chains or cipher suite configuration, even though neither of those really has anything to do with IRC specifically.

adam commented

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

Heh, I intended this to be for client-side support (which is relatively simple with OpenSSL), but I can just as easily see the case for server support.

Heh, I intended this to be for client-side support (which is relatively simple with OpenSSL), but I can just as easily see the case for server support.

adam commented

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

@rcombs - Oh. Well, same deal: as a TLS client, ZNC doesn't get to say how the server it wants to talk to is configured. Unless it wants to be in the same camp as Windows XP and Android 1.0 security-wise, support for SNI is just a must-have ;).

@rcombs - Oh. Well, same deal: as a TLS client, ZNC doesn't get to say how the server it wants to talk to is configured. Unless it wants to be in the same camp as Windows XP and Android 1.0 security-wise, support for SNI is just a must-have ;).

adam commented

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

Yup.

Yup.

adam commented

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

Unless it wants to be in the same camp as Windows XP and Android 1.0 security-wise, support for SNI is just a must-have

Does Android 1.0 support TLS 1.2?

What is the attack vector without SNI support?

SNI is in no way only a "web server thing" (although as I mentioned, it shouldn't matter, because znc is already a web server)

Even though ZNC has a web server in it, the primary function of ZNC is IRC. Maybe HTTP browsers support SNI, but that doesn't matter. IRC clients need to support it if you're going to have several servers on the same port. And that's not going to happen anyway, because IRC is not SSL-only.

> Unless it wants to be in the same camp as Windows XP and Android 1.0 security-wise, support for SNI is just a must-have Does Android 1.0 support TLS 1.2? What is the attack vector without SNI support? > SNI is in no way only a "web server thing" (although as I mentioned, it shouldn't matter, because znc is already a web server) Even though ZNC has a web server in it, the primary function of ZNC is IRC. Maybe HTTP browsers support SNI, but that doesn't matter. IRC clients need to support it if you're going to have several servers on the same port. And that's not going to happen anyway, because IRC is not SSL-only.

adam commented

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

I'm not opposed to adding SNI. But it just doesn't add any value.
On either (client or server) side.

I'm not opposed to adding SNI. But it just doesn't add any value. On either (client or server) side.

adam commented

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

If I understand correctly, https://github.com/hexchat/hexchat/pull/1478 adds SNI support for HexChat if it gets merged and it doesn't look very big change.

If I understand correctly, https://github.com/hexchat/hexchat/pull/1478 adds SNI support for HexChat if it gets merged and it doesn't look very big change.

adam commented

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

Rather than re-paste my argument here, refer to my comment with arguments for SNI in this issue:
https://github.com/ircv3/ircv3-specifications/pull/155#issuecomment-140081841

Rather than re-paste my argument here, refer to my comment with arguments for SNI in this issue: https://github.com/ircv3/ircv3-specifications/pull/155#issuecomment-140081841

adam commented

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

It appears that the current version of STS proposal adds optional SNI requirement for the sub key and based on the previous comment I see no reason why ZNC wouldn't implement it regardless of will STS happen or not. https://github.com/attilamolnar/ircv3-specifications/commit/8af78c830eb748c2ad517d3a9397b7957282cc5c

It appears that the current version of STS proposal adds optional SNI requirement for the sub key and based on the previous comment I see no reason why ZNC wouldn't implement it regardless of will STS happen or not. https://github.com/attilamolnar/ircv3-specifications/commit/8af78c830eb748c2ad517d3a9397b7957282cc5c

adam commented

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

My (share-)hoster uses SNI to serve more than one certificate per IP address (multiple customers share one IP address). Unfortunately I wasn't able to use the SSL option of ZNC with my signed certificates. My guess would be, that the missing SNI is the cause for it?

$ openssl s_client -showcerts -connect mydomain.tld:ZNC_PORT -servername mydomain.tld

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 272 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

My (share-)hoster uses SNI to serve more than one certificate per IP address (multiple customers share one IP address). Unfortunately I wasn't able to use the SSL option of ZNC with my signed certificates. My guess would be, that the missing SNI is the cause for it? ``` shell $ openssl s_client -showcerts -connect mydomain.tld:ZNC_PORT -servername mydomain.tld CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 272 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ```

adam commented

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

@johannesvogel errno 104 is ECONNRESET, could you start znc with the --debug flag and see what it complaints above? I don't think that this is related to this issue at all (by the time that ZNC gets the connection, SNI cannot be used any more to "also" hand it to some other customer on the same IP)

@johannesvogel errno 104 is `ECONNRESET`, could you start znc with the `--debug` flag and see what it complaints above? I don't think that this is related to this issue at all (by the time that ZNC gets the connection, SNI cannot be used any more to "also" hand it to some other customer on the same IP)

adam commented

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

The log says:

@40000000565c62b4329e5dcc [2015-11-30 15:52:26.849192] src/Csocket.cpp:1679 Error with PEM file [/home/USER/.znc/znc.pem]

There was a new line missing between my certificate and the startssl intermediate certificate. I fixed that and now it works.

Thanks for the help!

The log says: ``` bash @40000000565c62b4329e5dcc [2015-11-30 15:52:26.849192] src/Csocket.cpp:1679 Error with PEM file [/home/USER/.znc/znc.pem] ``` There was a new line missing between my certificate and the startssl intermediate certificate. I fixed that and now it works. Thanks for the help!

adam commented

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

Done by https://github.com/znc/znc/pull/1200 and this could be closed.

Done by https://github.com/znc/znc/pull/1200 and this could be closed.

adam commented

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

No, only half of it is done by #1200

No, only half of it is done by #1200

adam commented

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

Thanks for the clarification of changing issue title.

In other news, the PR to make SNI part of core IRCv3.3 was merged https://github.com/ircv3/ircv3-specifications/blob/master/core/sni-3.3.md .

Thanks for the clarification of changing issue title. In other news, the PR to make SNI part of core IRCv3.3 was merged https://github.com/ircv3/ircv3-specifications/blob/master/core/sni-3.3.md .

adam commented

2026-10-05 04:26:39 +02:00

holy crap some ppl are arrogant and narrow minded. having sni support on irc clients and servers should be a requirement not an option. besides the obvious it allows hosting multiple irc networks on the same ip which is great for balancers and ircds that virtualise multiple independent networks. since the irc protocol doesn't support a host specifier it is the only way determine exactly which service the client wants.

holy crap some ppl are arrogant and narrow minded. having sni support on irc clients and servers should be a requirement not an option. besides the obvious it allows hosting multiple irc networks on the same ip which is great for balancers and ircds that virtualise multiple independent networks. since the irc protocol doesn't support a host specifier it is the only way determine exactly which service the client wants.

adam commented

2026-10-05 04:26:40 +02:00

@GaryMatthews let's not offend people, ok?
As I said, I'm not opposed to adding this. That said, where is the patch?

@GaryMatthews let's not offend people, ok? As I said, I'm not opposed to adding this. That said, where is the patch?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#514