View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003325unrealircdpublic2007-05-09 00:592019-01-21 16:25
ReporterStealth Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionno change required 
Platform*OS*OS Version*
Product Version3.3-alpha0 
Summary0003325: Multiple ways to authenticate to the same thing
DescriptionAn interesting idea I came up with today, is to allow wildcards in SSL cert paths for passwords. Some may think this is useless, but it does have a use. Unreal would be able to detect if an sslclientcert auth line has a wildcard (* or ?), and then match the request to the list of certs matching the wildcard provided. If the client has one of the matching certs, grant access. If not, deny. Same as it is now, but with the ability to use multiple certs in 1 block.

Consider a network that has clients provide a password, but wishes to have them just connect via SSL and auth with their cert. With the way Unreal is now, they would need an allow block for each user. If they were able to use wildcards for the cert path, they would be able to have 1 allow block for all SSL clients.

allow {
  ip *;
  host *;
  class SSLAuth;
  password certs/users/* { sslclientcert; };
}



Another example would be a network which each global operator has the same flags in their O:Line. Instead of creating many oper blocks that are the same with different credentials, why not just have one and link in everyones cert?

oper GlobOp {
  from { userhost *; };
  password certs/opers/*.global.pem { sslclientcert; };
  class Opers;
  flags { Global; };
};
TagsNo tags attached.
3rd party modules

Activities

stskeeps

2007-05-09 04:36

reporter   ~0014059

This reduces accountability / ability to find out who's private key has gotten compromised, and then it gets to be an issue to add this to whois/oper messages, yadda yadda. Also, the userhost protection is a very good thing(TM) to have on seperate oper blocks.

Stealth

2007-05-09 12:29

reporter   ~0014061

Last edited: 2007-05-09 14:38

 > This reduces accountability / ability to find out who's private key has gotten compromised
Have Unreal put which key was used in the log, and possibly an extra output notice. If someone gets their key compromised, they don't need to be opered.

> and then it gets to be an issue to add this to whois/oper messages
Leave them, if someone sets this up in such a way, they shouldn't mind having the whois and oper notices all be the same.

> Also, the userhost protection is a very good thing(TM) to have on seperate oper blocks.
It is, but I honestly don't see the reason to maintain userhost settings when someone is using a cert. If they think their cert gets compromised, they should let someone know to get the issue handled asap.

EDIT: Another note about using userhost restrictions, the oper block allows for multiple userhosts, so there still can be restrictions on userhosts.

> yadda yadda
If there's more that you have to say, say it and allow me to reply.

<EDIT>Added/removed some things</EDIT>

stskeeps

2007-05-10 05:04

reporter   ~0014072

>> This reduces accountability / ability to find out who's private key has >gotten compromised
>Have Unreal put which key was used in the log, and possibly an extra output >notice. If someone gets their key compromised, they don't need to be opered.
Honestly, this would just lead to more code bloat to keep track of a special case that is just really.. laziness.

stskeeps

2007-05-10 05:07

reporter   ~0014073

And for the sake of argument, I would much rather prefer multiple password possibilities, lets say, multiple ways to authenticate to the same thing

Idiotic syntax:

password { "homecert.pem" { sslclientcert; }; "workcert.pem" { sslclientcert; }; };

Issue History

Date Modified Username Field Change
2007-05-09 00:59 Stealth New Issue
2007-05-09 04:36 stskeeps Status new => closed
2007-05-09 04:36 stskeeps Note Added: 0014059
2007-05-09 04:36 stskeeps Resolution open => wont fix
2007-05-09 12:29 Stealth Status closed => feedback
2007-05-09 12:29 Stealth Resolution wont fix => reopened
2007-05-09 12:29 Stealth Note Added: 0014061
2007-05-09 14:38 Stealth Note Edited: 0014061
2007-05-10 05:04 stskeeps Note Added: 0014072
2007-05-10 05:07 stskeeps Note Added: 0014073
2007-05-10 05:09 stskeeps Summary Wildcards in SSL Cert paths => Multiple ways to authenticate to the same thing
2019-01-21 16:25 syzop Status feedback => closed
2019-01-21 16:25 syzop Resolution reopened => no change required