Re: ircd development ideas (was Re: Re: RFC: ircd choice vote)

Andy Smith wrote:

>On Sun, Aug 07, 2005 at 01:45:20AM +0200, Philipp Kern wrote:
>  
>
>>On Aug 7, 2005, at 1:31 AM, Andy Smith wrote:
>>    
>>
>>>But it isn't possible for every ircd to rehash simultaneously and
>>>any users who connect while the net is in an inconsistent state
>>>would have different hosts on different servers.
>>>      
>>>
>>Well I don't think that there is an inconsistent state. All server  
>>admins get those keys and enter it into the config file before they  
>>link. And they don't get changed. (Without a change there is also no  
>>race condition.) By the way: When you change the cloak keys new users  
>>could get the same hosts as existing users as the former are not  
>>getting new hostmasks.
>>    
>>
>
>Sure, but the point is, isn't the fact that you need to put 3 strings
>into a conf file and then NEVER CHANGE THEM EVER kind of sucky?
>Especially when the strings are effectively a password, so any
>former admin or anyone who ever looked at a conf file knows them?
>  
>
>  
>
This has been my issue with it. Our current implementation is exactly
this way.
I really dont want it to stay that way, and I have been thinking
(moreso, lately) on how
to strengthen it a bit.
There are a couple of ideas:
1. Let services do it.
2. Let the hub(s) do it.

Basically, if a server cannot get a keyset, disallow the mode change
required to get a hashed hostname.
Let it learn this keyset from the hub its connecting to.
A server admin would never know the keys, never need to know the keys,
and would not
need to even care about the keys. It puts the burden on the hub
operators at that point.
If there are 2, 3, 4, or more hub operators its a far cry from 10 server
admins PLUS those 1+ hub operators.

If you know the keys, you can easily write a program from the already
public source code to spit
out possible ip matches. I think at last try it would narrow it down to
some trivial number of
possible addresses, of which some number of them would be invalid...
thus widdling it down more.
I think the average number last time we took a stab at it was around 500
possible addresses (still pretty anonymous)
We all would probably be better off disallowing use of it unless the
correct conditions were met.

As I write this I had another thing come to mind.
There is an event in the module loading that fires when a module is
actually loaded.
Suppose... a module was written to contain these keys and when the ircd
starts, it loads the module
and the module sets the appropriate variables in the ircd that contain
the keys.
Most servers im sure are *bsd, linux, ect.
So, when a new server joins give them a precompiled module.
I dont know if you can just open up the module object code and find the
strings, tho.
Anyone that knows gcc and related compilers care to chime in?
I bet its possible to obfuscate it somehow in this case.


Sounds more like a discussion on implementation, rather than choosing an
ircd. :)
Turned into a security discussion, but everyone has good points and
ideas I think :D

>------------------------------------------------------------------------
> 
>_______________________________________________
>public mailing list
>public-Hb7ITwsGSD4lroQnaJEqWdi2O/[email protected]
>http://lists.blitzed.org/listinfo/public
>  
>