Support client certificate authentication (certfp) & SASL EXTERNAL

[Mikaela]

I thought there was an issue about this already, but I cannot find it. Client certificates would allow passwordless login to IRC server and generally IRC services allow multiple certificate fingerprints to be configured so users could upload (or have the bridge generate) unique SSL certificate which the users then cert add and if the private key got compromised, users would just remove that fingerprint from their IRC accounts and generate a new one.

Client certificates are also the only way to identify to OFTC automatically as far as I am aware.

I couldn't find technical details on how to implement it so I imagine it's the same certificate authentication that web browsers and everything else support and in some wider specification.

Instructions by IRC networks:

• OFTC: Automatically Identifying Using SSL + CertFP
• freenode: CertFP
• LiberaChat: Using CertFP

[Mikaela]

In case it's of any interest/use here, TheLounge.chat v4.2.0-pre.1 (selfhosted IRC webclient) has implemented this while also being written in JavaScript (which I hope makes the code easier to take inspiration from).

In their implementation, client certificates are automatically generated and what the user needs to do is message cert add to NickServ supporting certfp.

• thelounge/thelounge@f8f692a

[qguv]

It would be super nice to have automatic nickserv identification on the matrix.org OFTC bridge. OFTC doesn't support using server password to identify to services, which means currently there's no way to automatically reidentify after connection blips between the oftc bridge and their network. OFTC does support cert auth.

[eternaleye]

(Originally left this comment on #459 by mistake)

Something I'd like to bring up - #1128 chose a workflow where the Matrix user hands the bridge a private key, but it'd likely be more sensible to have a command to generate a key (and certificate), which the user then registers with the network. This avoids passing private key material around, which is generally frowned upon.

Another option might be to use a single bridge key, and generate a distinct certificate, with a different distinguished name, per user. This hugely simplifies the storage of private key material, as it's a singleton.

[solson]

Adding to the links above, Libera.Chat also has a support page for CertFP: https://libera.chat/guides/certfp

[Mikaela]

I edited the issue quickly to add the Libera.Chat link and append "& SASL EXTERNAL" to the end as when certfp is supported and certificate exists, I think using SASL EXTERNAL should be as simple as AUTHENTICATE + or something like that, so I think it should be easy to implement.

[TLATER]

Was this implemented on libera.chat? After using !reconnect I got a PM from "SaslServ".

[eli-schwartz]

It shouldn't have anything to do with a specific network, and anyway this issue is not about SASL, it is about certfp (which can optionally be combined together with SASL).

libera.chat supports:

• SASL, via password auth. You may very well (probably did) use password auth + SASL.
• SASL, via certfp auth
• password auth via the PASS command on connection (but without SASL)
• certfp auth on connection (but without SASL)
• entering a chat with NickServ and using the IDENTIFY command

OFTC does not support SASL
It does support:

• certfp auth on connection (but without SASL)
• entering a chat with NickServ and using the IDENTIFY command

Since SASL is not actually connected to certfp, the fact that libera indicated the presence of SASL is not an indicator that certfp auth was implemented. It might have been implemented anyway, I don't know...

Have you at any point knowingly set up certfp, anyway? e.g. messaged cert add to NickServ?

[TLATER]

No, sorry, thanks for the explanation. I was just mildly confused at the message from that bot when I believed the bridges had no support for that yet, I hadn't realized it has more general applications.

[eli-schwartz]

Sure, no problem. This whole situation is not exactly the clearest, I had my own frustrated confusion back when I originally tried to figure out just what the heck all this meant. :D

(A lot of this was tied into my eventual realization that OFTC doesn't support SASL no matter what you do, and therefore it will never ever support joining +r i.e. registered-only channels on connection.)

[valpackett]

Very confusingly on OFTC you can currently end up in a state where you are not nickserv identified but you are in a (room that's bridged to a) channel that only lets registered nicks speak and all your messages appear in matrix but not on IRC >_<

[DemiMarie]

In the case of CertFP, would it be possible to use the same certificate for all users of the bridge?

[progval]

That would make all users connect to the same account on IRC, are you sure this is what you want?

[DemiMarie]

That would make all users connect to the same account on IRC, are you sure this is what you want?

I thought that there was a list of authorized certificates for an account, and that the same certificate could be authorized for multiple accounts.

[progval]

That's technically possible, but I don't know any IRC service implementation that allows certificate fingerprints to be shared by multiple accounts. (And in particular with SASL EXTERNAL, there is no way to tell what account should be used if more than one allowed the same cert)

[aaronmdjones]

in particular with SASL EXTERNAL, there is no way to tell what account should be used if more than one allowed the same cert

One could abuse its provision for transferring an authzid in order to transfer an authcid instead, but this would be in violation of the spec.

[DemiMarie]

in particular with SASL EXTERNAL, there is no way to tell what account should be used if more than one allowed the same cert

One could abuse its provision for transferring an authzid in order to transfer an authcid instead, but this would be in violation of the spec.

Would it work?

[Mikaela]

I seriously don't think sharing the certificate across all users is the right way, while I guess it can be helpful to have multiple accounts belonging to the same user have the same cert, which I hope gets resolved by decentralised accounts instead.

In my opinion, the TheLounge method is the right idea #747 (comment)

[aaronmdjones]

Would it work?

In theory? Yes.

In practice, on extant networks? No.

[DemiMarie]

I would prefer for the bridge to generate its own certificates. Do not worry about encrypting the private keys; that is what full disk encryption is for.