CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

If your UnrealIRCd is up and running but you have a question about it, then use this forum.
(NOT for installation or connecting issues! Use the other forum instead.)

Moderator: Supporters

Locked
HeXiLeD
Posts: 51
Joined: Mon Jan 16, 2017 8:07 pm
Location: online

CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

Post by HeXiLeD »

I just decided to test this new feature and maybe there are a few things to consider:

info:
Authentication
https://unrealircd.org/docs/Authentication
https://unrealircd.org/docs/Require_aut ... tion_block
https://unrealircd.org/docs/Set_block#s ... ion-prompt

CertFP
https://unrealircd.org/docs/Set_block#s ... clientcert

The new authprompt module is indeed handy, but I just stumbled upon a few delicate details and perhaps with some feedback, somethings can be enhanced having in mind a few situations/configurations in consideration:

Situation 1:
The point of using sasl/authprompt is to kinda close the server to all sorts of unwanted connections. However for such security and privacy, certFP fail-if-no-clientcert is a much better option. It's downside is not being as simple to setup on the client side and not discriminating by connection origin such has *@*.tld, *@*, etc

Situation 2:
Given that sasl/authprompt is in a way less restrictive than certFP fail-if-no-clientcert. Anyone who has a certFP fail-if-no-clientcert enabled server may want to allow sasl/authprompt connections, while maintaining the server closed but more flexible to clients. However, both features are not compatible.
The moment a certFP fail-if-no-clientcert server is enabled, the use of sasl/authprompt makes things more complicated.

In other words, either use fail-if-no-clientcert or the authprompt feature.

Situation 3: My testing case
I connect using certFP while the server does not have fail-if-no-clientcert and allows and features sasl functionality but the moment the server admin activates authprompt requirements for my ip or in this case (127.0.0.1) localhost (since I ssh to boxes and connect locally to the ircd) or when I use TOR, the use of certFP becomes useless even tho is a much better security option.

In other words, don't use authprompt.

In the light of these situations, a few enhancements could be looked into:

Require authentication could now include fail-if-no-clientcert in similar fashion and allowing to specify the type of connection and or origin, such has *@*.tld, *@*, etc, with the use of certFP and authprompt.
(This for example, could and should be applied by default to server admins/ircops)

Allowing fail-if-no-clientcert option to play with a mask <hostmask>; will make it much more versatile for fail-if-no-clientcert and even for clients of specific connectivity origin to be requested for a certFP.

Regardless of above proposed feature, should certFP client authentication be blocked if the server, although not having fail-if-no-clientcert enabled, decides to enable sasl/authprompt or should it allow certFP clients to bypass the sasl/authprompt auth since certFP is much more secure?
I propose that if a client is using certFP for authetication, that the server should allow the client to bypass the sasl/authprompt.
I do recognize that a spam attacker can simply make a cert for all bots and still connect, as well as it can make the same sasl login for all the bots but then in the light of enhancements a related topic is bellow:

( Related: viewtopic.php?f=52&t=8745 & https://bugs.unrealircd.org/view.php?id=5002)

Right now there is an incompatibility between clients using certFP and servers using authprompt while sasl should not overide the use of certFP.

Ultimately in the evolutionary chain of things, sooner or later, authentication by certFP not only is the way to go as well as it is the end goal. The use of sasl/authprompt intends only to mitigate some current issues that can be eliminated by other already default implemented methods.
Still a good feature but it should not supersede certFP possibilities and right now it should allow a certFP client to connect by default.
Last edited by HeXiLeD on Fri Dec 28, 2018 7:41 pm, edited 1 time in total.
Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We are not in the 90's IRC world anymore.
CertFP: d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
Syzop
UnrealIRCd head coder
Posts: 2112
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: fail-if-no-clientcert vs sasl/authprompt login auth

Post by Syzop »

You are entitled to your own opinion but IMHO saying fail-if-no-clientcert "is a much better security option" than doing authentication is really a strange statement to make.

Let's see:
  • SASL/authprompt: The user authenticates against their services account.
  • fail-if-no-clientcert: No authentication. All you need is ANY client certificate. This is something a client can generate easily.
I take it you currently have positive experiences from fail-if-no-clientcert because (again, presumably) you don't have much drones attacking your server. However, once more drone software adds support for SSL/TLS and client certs then your server will have the same set of problems as a server without it and you're back to square one. This is not a future proof solution.

Again, SASL and authprompt provide authentication. This gives you lots of opportunities to do things against bad users:
  • The user has to register their account first
  • It's up to the admin how easy or hard registration is but it allows the opportunity for things like email confirmation, anti spam bot countermeasures, manual admin approval of the account, etc.
  • In case of abuse an admin can disable or delete the account
  • An admin can temporarily disable registration or increase/decrease registration difficulty depending on the circumstances (eg: an attack)
  • You can set a maximum number of sessions per authenticated user (in anope this currently defaults to 10, which is quite high IMO)
  • And more...
It's much more flexible and expandable.
Syzop
UnrealIRCd head coder
Posts: 2112
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: fail-if-no-clientcert vs sasl/authprompt login auth

Post by Syzop »

I see you are someone who is really in favor of client certificates (and thus certificate fingerprints). That is great and certificate fingerprints are indeed good, but I think you are misunderstanding WHY they are good.

The real benefit of a certificate fingerprint (certfp) is that it can be used as an authentication method instead of a password. We all know why passwords are bad. Passwords can be intercepted, cracked, they are often weak, etc.. while certificate fingerprints don't have this problem.

That is where the real power of certfp lies: the power to use a certfp instead of a password. And that is what admins who follow good security practices do: they use them in oper blocks and link blocks (as recommended by the UnrealIRCd documentation) and other configuration directives.
Users can set a certfp in their services account which can then be used by SASL (UnrealIRCd sends the certificate fingerprint to services when a user tries to do SASL). This is by the way what someone would do in your 'situation 3'. See also this freenode tutorial which describes it for end-users (except they grab the sha1 hash, and we use sha256).

It seems like you have learned about client certificates but somehow missed "the other part": that certificate fingerprints are meant to be used for authentication of servers, opers and users at services.
Perhaps you got confused by the set::ssl::options::fail-if-no-clientcert feature. That option was never meant to be used standalone as then it provides pretty much no security, as described in my previous forum post. If so, then I apologize because it should be documented better. In fact, I will do that right now.
HeXiLeD
Posts: 51
Joined: Mon Jan 16, 2017 8:07 pm
Location: online

Re: CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

Post by HeXiLeD »

Thanks for your very dedicated reply :D
I will address a few points and I agree with most of what you said, except one detail and I must state that at the time, I felt I did not expressed what I suggested properly given the complexity of this matter.
I take it you currently have positive experiences from fail-if-no-clientcert because (again, presumably) you don't have much drones attacking your
server.
On s side note and topic, I actually I don't really use this option to prevent drones and similar attacks.
What I have done is to only allow high security ciphers that only the clients I allow to connect are actually able to work with.
It took some time to test each of the most popular clients and see where the connection would fail once a certain cipher was not supported by certain client.
Not only I filter drones as I filter weak secure clients (depreciated). SSL and TLS tend to be the last thing most legit admins consider to work with in order to secure ircd's and attackers don't spend time coding their bots with ssl/tls features.

I also filter client connection by deny/allow rules based on how the clients work and secure features they support.
In 13 years of operation and allowing TOR as well as hidden services, I have no successful connection attacks.

However my experience with fail-if-no-clientcert also confirms your inference in regards to drones.

But in regards to
fail-if-no-clientcert No authentication. All you need is ANY client certificate. This is something a client can generate easily.
I agree and hence my suggestion, some time ago and the server can mitigate a possible attack by only allowing specific confirmed certFP's (enhancement to the feature that can work with the feature)
Again, SASL and authprompt provide authentication. This gives you lots of opportunities to do things against bad users:
Agreed and confirmed.
It's much more flexible and expandable.
Agreed, confirmed and hence the proposition is similar enhancements to certFP features.

For example, certFP can work with the services such as anope in order to only allow a services admin to use the services only when the admin certFP services block matches the certFP used by the client admin, which you addressed well in the reply and I agree.
The real benefit of a certificate fingerprint (certfp) is that it can be used as an authentication method instead of a password. We all know why passwords are bad. Passwords can be intercepted, cracked, they are often weak, etc.. while certificate fingerprints don't have this problem.

That is where the real power of certfp lies: the power to use a certfp instead of a password. And that is what admins who follow good security practices do: they use them in oper blocks and link blocks (as recommended by the UnrealIRCd documentation) and other configuration directives.
Users can set a certfp in their services account which can then be used by SASL (UnrealIRCd sends the certificate fingerprint to services when a user tries to do SASL). This is by the way what someone would do in your 'situation 3'. See also this freenode tutorial which describes it for end-users (except they grab the sha1 hash, and we use sha256).
Also agreed and I have done tutorials similar to the one of freenode but for several irc clients in linux and windows environment and I only use certFP for legit or trusted networks.
...somehow missed "the other part": that certificate fingerprints are meant to be used for authentication of servers, opers and users at services.
This is the detail I disagree having missed. I did not, but I can confirm that I may have by misunderstood or explained myself poorly due to:
Perhaps you got confused by the set::ssl::options::fail-if-no-clientcert feature
..and your added clarification improved my inference. :D

I think that what I am trying to aim is two things:

1: Enhance certFP features to be more flexible as sasl (if possible) and or work in the same fashion.
2: Since I only use certFP to connect everywhere, once I turned on authprompt provide authentication on a server which I only connect using certFP, was not able to connect anymore and had to manually use the password.

This last experience will probably discourage users to use certFP and what I would like to see is more flexibility in regards to this second problem in order to keep authprompt active for those that prefer sasl while at the same time, not to get certFP users to hit the door with their nose.

I confess I have not tested extensively but I did bump into this second problem. Perhaps I am missing a setting or there is limitation that perhaps could be lifted or improved.

This part may seem confusing in the way I am expressing it, but basically if I want to turn authprompt for sasl users and or add the improved security and flexibility of sasl, the certFP users can't login without manually input their password.
This is a bit of a bummer... :)
Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We are not in the 90's IRC world anymore.
CertFP: d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
Syzop
UnrealIRCd head coder
Posts: 2112
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

Post by Syzop »

Sorry for only replying in part below: :)
HeXiLeD wrote: Fri Dec 28, 2018 7:32 pm basically if I want to turn authprompt for sasl users and or add the improved security and flexibility of sasl, the certFP users can't login without manually input their password. This is a bit of a bummer.
If an end-user uses a client certificate and hence likes to use a client certificate fingerprint (certfp) instead of a password, then this user should use /NS CERT to set his certfp for his services account. If the user then connects they are allowed straight in without seeing an authprompt (provided the user has SASL enabled in their client, of course).

Or, am I missing something? :)
HeXiLeD
Posts: 51
Joined: Mon Jan 16, 2017 8:07 pm
Location: online

Re: CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

Post by HeXiLeD »

Here is my testing example using weechat and unrealircd 4.2.1

I created conf/authentication_block.conf which is loaded in unrealircd.conf

Added a block:

Code: Select all

require authentication {
        mask *@127.0.0.1;
        reason "Too many abusers from this ip, please authenticate";
};
Created a user with netadmin permissions, registered the user and added a certificate to the irc client.
Added the certificate FP of the user to the nickserv account and confirmed it is in the services with /ns cert list

Code: Select all

./unrealircd rehash 
Reconnected the irc client to localhost (no TOR used) and:

Code: Select all

Too many abusers from this ip, please authenticate
The server requires clients from this IP address to authenticate with a registered nickname and password.
Please reconnect using SASL, or authenticate now by typing: /QUOTE AUTH nick:password
Can't connect

A few other notes on the client.
Has sasl enabled
It has the user and password saved on regular nickserv parameters which is ignored in favor of client certificate
It has the username saved in sasl login parameters but i also tested without having it there.
Uses a plain sasl mechanism
It will disconnect by default if sasl fails but note that this setting does not interfere with normal login using certFP and the authprompt is not active.
(side note: I wonder if sasl only activates when the client detects a password set in the parameters)

After this, new test and added the password to the sasl parameters or manually. That is when it ends up by connecting.

So either the sasl password is added manually or is set on the client.
So the sasl password is always needed to establish connection, or the client will never connect even if it uses certFP and is on the nickserv certificate list of the user.

One other downside of this is having to leave passwords saved on clients that run remotely or keep setting them and unsettling them and when people use long complex passwords (like: aWwMPE8Fi<9E5E4g;^]q5'7yd`>SL9~mfD!tgS&5oF`B^ud>6~) things become messy.
Most clients store passwords in clear text.
A certificate can have and should have restrictive reading permissions and loading a certificate temporarily is easy for the moment session.


So maybe I missed the password set detail, but the proposal is to have certFP to work in similar fashion of sasl or do the same but independently of sasl.


There is also the detail of how clients work with sasl and certFP.
While weechat is very flexible but hexchat is way less intuitive and clear about it and some others probably even less.
Constructive criticism leads to evolution and progress. Negative criticism leads to obsolescence. We are not in the 90's IRC world anymore.
CertFP: d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
Syzop
UnrealIRCd head coder
Posts: 2112
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

Post by Syzop »

Sorry for the delay, I was doing other stuff and had to test your issue first.
So what I did was:
  1. Connect over SSL/TLS (duh)
  2. Use "/NS CERT ADD" to add the certificate fingerprint to my account.
  3. Reconfigure mIRC 7.54 to use the login method "SASL External (/CAP)" and then (re)connect over SSL/TLS
  4. I am then correctly identified as myself
I then placed a soft-gline (%*@192.168.*) and tried again. It allowed me in without having to type anything.

So just to be clear, this is all without any password stored anywhere or any password being typed.

I think if something is not working, you should check your client settings. And I agree, most clients are not so nice in this respect :(
Syzop
UnrealIRCd head coder
Posts: 2112
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Re: CertFP vs fail-if-no-clientcert vs sasl/authprompt login auth

Post by Syzop »

So, the previous post was about fixing SASL on the client (configure them to use SASL EXTERNAL if you want to authenticate by certfp).

I suppose we could also enhance authprompt to attempt SASL EXTERNAL authentication for any clients with a client certificate. So, for clients that do not use SASL. If you want this, could you then create a feature request on bugs.unrealircd.org? :)
Locked