View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003325 | unreal | ircd | public | 2007-05-09 00:59 | 2019-01-21 16:25 |
Reporter | Stealth | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | * | OS | * | OS Version | * |
Product Version | 3.3-alpha0 | ||||
Summary | 0003325: Multiple ways to authenticate to the same thing | ||||
Description | An 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; }; }; | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
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. |
|
> 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> |
|
>> 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. |
|
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; }; }; |
Date Modified | Username | Field | Change |
---|---|---|---|
2007-05-09 00:59 | Stealth | New Issue | |
2007-05-09 04:36 |
|
Status | new => closed |
2007-05-09 04:36 |
|
Note Added: 0014059 | |
2007-05-09 04:36 |
|
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 |
|
Note Added: 0014072 | |
2007-05-10 05:07 |
|
Note Added: 0014073 | |
2007-05-10 05:09 |
|
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 |