2015-10-02 08:04:15 +02:00
---
2015-02-24 08:40:49 +01:00
layout: post
comments: true
title: "ZNC 1.6.0 & SSL certificate verification"
category: [english]
tags: [irc, english]
2024-06-03 08:48:19 +02:00
sitemap: false
2018-11-25 23:51:24 +01:00
redirect_from:
- /zncssl.html
- /english/2015/02/24/znc160-ssl.html
2015-02-24 08:40:49 +01:00
---
**TL;DR: if you don't verify SSL certificates, don't use SSL!**
2024-06-19 07:19:44 +02:00
ZNC 1.6.0 was released on 2015-02-12 21:05:48Z. It brings multiple improvements
such as taking IP addresses from round-robins randomly instead of always
resolving them into same IP and most notably it actually verifies SSL
certificates.
2015-02-24 08:40:49 +01:00
2023-02-22 19:28:38 +01:00
- [Changelog ](https://wiki.znc.in/ChangeLog/1.6.0 )
2015-02-24 08:40:49 +01:00
2024-06-19 07:19:44 +02:00
ZNC 1.6.0 also doesn't have option to blindly accept certificates, which would
be stupid, but sadly
2015-02-24 08:40:49 +01:00
[Quakenet is right about most of people just accepting certificates blindly ](https://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless )
2024-06-19 07:19:44 +02:00
as people are asking how to disable the SSL certificate verification on \#znc a
lot.
2015-02-24 08:40:49 +01:00
2024-06-19 07:19:44 +02:00
Some people even wrote
[a patch and scripts to disable the verification. ](https://gist.github.com/KindOne-/52cfade7b937ee8b4c37 )
2015-05-27 10:02:55 +02:00
This isn't a good idea as patching ZNC can cause all kinds of issues as
2024-06-19 07:19:44 +02:00
sometimes seen with zncstrap
[1 ](https://github.com/ProjectFirrre/zncstrap/issues/16 )
[2 ](https://github.com/ProjectFirrre/zncstrap/issues/18 )
[3 ](https://github.com/znc/znc/issues/384 ). See also
[contributing (reporting bugs) guidelines of ZNC. ](https://github.com/znc/znc/issues/384 )
2015-05-27 10:02:55 +02:00
2024-06-19 07:19:44 +02:00
I believe same policy should apply to patching ZNC as to config files, patch ZNC
or edit config file and you will forfeit all support.
2015-02-24 08:40:49 +01:00
2023-02-22 19:28:38 +01:00
## And to the subject
2015-02-24 08:40:49 +01:00
2024-06-19 07:19:44 +02:00
If you don't verify SSL certificates, you only have a false sense of security as
you let anyone between your ZNC and the IRC network. This is called as
[Man-in the middle (or shortly MITM) attack. ](https://en.wikipedia.org/wiki/Man-in-the-middle_attack )
There are also people asking for ZNC to trust the certificate for the first time
and then be alerted if the certificate changes. What if the MITM is there during
your first connection attempt and then you are alerted when the real IRC server
gives you wrong certificate?
2015-02-24 08:40:49 +01:00
2023-02-22 19:28:38 +01:00
## So what is the correct way?
2015-02-24 08:40:49 +01:00
2024-06-19 07:19:44 +02:00
- Check the website of your IRC network in case the fingerprints are listed on
their website.
- Try asking the operators of your IRC network somewhere else if you know them
(like another network or email).
2023-02-22 19:28:38 +01:00
- This might not be so recommended, but also check the fingerprints from
2015-02-24 08:40:49 +01:00
multiple locations.
> But the IRC network has hundreds of servers with different certificates!
2024-06-19 07:19:44 +02:00
In this case do what was recommened before ZNC 1.6.0, check some of the servers
that are geographically close to you and use them.
2015-02-24 08:40:49 +01:00
## Checking the fingerprint from multiple locations
2024-06-19 07:19:44 +02:00
I have shell function (which you can find later on this page) which I run from
multiple places:
2015-02-24 08:40:49 +01:00
2023-02-22 19:28:38 +01:00
- my home, Kotka, Finland
- [Kapsi (shell) ](https://www.kapsi.fi/english.html ), somewhere in Finland
- my VPS, DigitalOcean, London, the UK
2015-02-24 08:40:49 +01:00
```bash
# Get server SSL certificate fingerprint in MD5, SHA1 and SHA256.
# Note that OpenSSL doesn't support IPv6 at time of writing (2015-01-13).
2024-06-08 08:08:36 +02:00
serversslcertfp() {
SSSLCFFN=$(openssl s_client -showcerts -connect $1 < /dev/null)
# To see all validity information
echo "$SSSLCFFN"
# For getting the fingerprints
echo "$SSSLCFFN" | openssl x509 -md5 -fingerprint -noout
echo "$SSSLCFFN" | openssl x509 -sha1 -fingerprint -noout
echo "$SSSLCFFN" | openssl x509 -sha256 -fingerprint -noout
echo "$SSSLCFFN" | openssl x509 -sha512 -fingerprint -noout
unset SSSLCFFN
2015-02-24 08:40:49 +01:00
}
```
I hope this article has helped you to understand the issues with blindly
2024-06-19 07:19:44 +02:00
accepting SSL certificates or at least to understand that _if you don't want to
verify SSL certificates, don't use SSL._
2015-02-27 11:44:09 +01:00
2024-06-19 07:19:44 +02:00
- _Updated on 2015-02-26 10:43Z: just use environment variables in the function
like suggested by @DarthGandalf on \#znc._
2015-09-03 12:21:15 +02:00
## I am asked to verify fingerprint for network with valid certificate
2023-02-22 19:28:38 +01:00
_Added on 2015-09-03. 4. added on 2016-01-26._
2015-09-03 12:21:15 +02:00
2024-06-19 07:19:44 +02:00
There are usually four causes for this. Lets use liberachat as example network.
2015-09-03 12:21:15 +02:00
2024-06-19 07:19:44 +02:00
1. You don't have the `ca-certificates` package installed (`ca_root_nss` on
FreeBSD), so your system trusts no certificate authority. Install it and try
again.
2021-05-23 13:10:38 +02:00
2. You are connecting to wrong address. liberachat's certificate is valid for
2024-06-19 07:19:44 +02:00
\*.libera.chat, but there are CNAMEs pointing there. If you connect to CNAME
and the certificate isn't valid for that CNAME, the certificate is invalid.
2023-02-22 19:28:38 +01:00
- You should always connect to `irc.libera.chat` .
2024-06-19 07:19:44 +02:00
3. There is MITM which is unlikely, but unlikely is not impossible. Validating
the certificates either by trusted certificates or verifying the fingerprints
securely manually protect you from this. If MITM is the case, you shouldn't
connect.
4. You have `ca-certificates` installed, but the remote certificate is signed by
CA that is not included in it. You could try installing system updates in
case `ca-certificates` have been updated or you will have to treat the
certificate as invalid until ZNC starts supporting it's own CA storage. See
(and comment if you encounter this)
2016-01-26 17:14:07 +01:00
[znc/znc#909 ](https://github.com/znc/znc/issues/909 ).
2023-02-22 19:28:38 +01:00
---
2018-11-10 19:06:55 +01:00
Section added on 2018-11-10: I have started using the new option to allow
invalid SSL certificates in some cases as this post is only written with
clearnet in mind.
2024-06-19 07:19:44 +02:00
I am on some networks over Yggdrasil or Cjdns which already have E2EE like Tor
hidden services so as long as they are accessed directly, all benefits of TLS
are there already and TLS certificates are an additional burden as with
LetsEncrypt they will change often and LetsEncrypt doesn't support any network I
mentioned.
2015-09-21 14:48:08 +02:00
2023-02-22 19:28:38 +01:00
---
2015-09-21 14:48:08 +02:00
2023-02-22 19:28:38 +01:00
_As I seem to be updating this page more than I originally thought I should
2024-06-19 07:19:44 +02:00
probably add
[this link to changelog here. ](https://github.com/Mikaela/mikaela.github.io/commits/master/_posts/2015-02-24-znc160-ssl.md )_