inspircd / inspircd

A modular C++ IRC server (ircd).
https://www.inspircd.org
1.17k stars 266 forks source link

Support verifying links (spanningtree) by CA instead of fingerprint #2029

Open kylef opened 1 year ago

kylef commented 1 year ago

Description

Currently to verify a linked host with TLS, fingerprints are used. This feature request would allow using a certificate authority to verify instead.

This could look something like:

<link ...
  cacert="my-ca.pem">

If the hosts certificate validates with the ca, then it is deemed valid (i.e, the certificate is not expired, etc). Revocation should ideally be supported.

The design of the feature must allow multiple CA roots to facilitate root rotations. A subject filter may be desirable if using a CA that is not isolated to the InspIRCd setup. For example:

<link ...
  cacert="my-ca.pem"
  casubject="*.example.net">

Why this would be useful

Routine certificate renewals require updating the fingerprints in all hosts which makes certificate rotation more complicate, CAs are the standard in which most PKI operates.

Further, it would be nice to not even have to declare servers via a link block and fully trust PKI. Currently servers must share information about each other out of bound.

SadieCat commented 1 year ago

FWIW you can define multiple <sslprofile> tags so you have one that uses a longer lasting self-signed certificate with fingerprint pinning for server connections and another that uses a CA-verified certificate for user connections. I'll look into this though.

henk84 commented 4 months ago

I think this is more of a bug than an enhancement. In times where certs are free and very widespread through all different kinds of services, my expectation was that without my explicit say-so, any TLS connection will verify the cert presented or warn if it cannot verify the cert. Breaking this expectation by simply not doing verification at all without informing the user should be considered a bug, nowadays, when "security by design" is a widely accepted design principle. Please make it a priority to change this behaviour, at the very least by adding a warning whenever a cert is encountered that cannot be verified against a fingerprint or a CA.