This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.


For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.

Crypted hostnames and [maskhost ] error

Old posts that have not been replied to for several years.
Locked
p
piranha

Crypted hostnames and [maskhost ] error

Post by piranha »

Some IRCDs (like: UltimateIRCd(Tsunami)-3.0(00).a29) started using function hide host or crypt host.

Regular Ip numbers are represented as:
*!*@3d6b14e3.15ce2659.52eef1c.2e099bf0X
The numeric representation of ip is crypted, but it still has ip sections.
Hosts will look like: *!*@4e929bd.25a73dd4.in-addr.btopenworld.com

In this case [maskhost] will create masks that completely make no sense:
*!*@*.15ce2659.52eef1c.2e099bf0X
instead:
*!*@3d6b14e3.15ce2659.52eef1c.*

Will this issue be resolved somehow?

Currently I use: 1.6.12 but I haven't seen any note about this issue in 1.6.13 readme.
p
ppslim
Revered One
Posts: 3914
Joined: Sun Sep 23, 2001 8:00 pm
Location: Liverpool, England

Post by ppslim »

There is no way to resolve this issue.

The masking functions are doing there jobs correctly, the problem lie with the servers.

The idea behind these masked hosts, is to hide connection information. If packet flooders can obtain the information via other means, then there is no point in maksing the host in the first place.

If they can't get the information, other people can't too.

A persons userhost, is supposed to be exactly that, and not one masked using hash functions. As such, in reality it's breaking the RFC. Soemthing which, can't be balmmed on eggdrop.
p
piranha

Post by piranha »

It's not about blaming anyone about anything.
I just wanted to signal that irc networks start using it.

The question is if eggdrop team wants to notice it and try to adapt the code to work properly.

I don't believe it's a big change tho, as you see segments *!*@xx.xx.xx.xx are still there. The problem may be how to recognise it for proper masking (*!*@xx.xx.xx.* instead of *!*@*.xx.xx.xx)
p
ppslim
Revered One
Posts: 3914
Joined: Sun Sep 23, 2001 8:00 pm
Location: Liverpool, England

Post by ppslim »

Not all networks/IRCD follow the same guide for masking.

As such, making one for one type, doesn't cover all types. Thus you start having to add code for 3 or 4 types, bloating it.
e
egghead
Master
Posts: 481
Joined: Mon Oct 29, 2001 8:00 pm
Contact:

Post by egghead »

piranha wrote: It's not about blaming anyone about anything. I just wanted to signal that irc networks start using it.
The question is if eggdrop team wants to notice it and try to adapt the code to work properly.
I don't believe it's a big change tho, as you see segments *!*@xx.xx.xx.xx are still there. The problem may be how to recognise it for proper masking (*!*@xx.xx.xx.* instead of *!*@*.xx.xx.xx)
As you indicated: it is not trivial and like ppslim said, different networks encrypt the hostname/ip differently.

In your case it seems that the network leaves the top level domain intact. One can check for that by comparing the tld of the hostname with a list of tlds.
It also seems that the encryption always introduces a number when it does the encryption. Consequently, if the tld part does not contain a number than it is a hostname and an ip otherwise.

If your only concern is the [maskhost] procedure, it is possible to redefine it with a tcl proc. Below you can find a first attempt to such tcl.

http://members.fortunecity.com/eggheadt ... st.tcl.txt
g
guppy
eggdrop engineer
Posts: 199
Joined: Mon Sep 24, 2001 8:00 pm
Location: Canada
Contact:

Post by guppy »

You only mask hosts to *!*@something.* when dealing with IPs -- Eggdrop's maskhost is still doing the correct thing. I suggest you blame your IRCd instead of blaming Eggdrop.

The people who write IRCds should be held accountable by their users instead of their users blaming the client writers.
p
piranha

Post by piranha »

@egghead
If your only concern is the [maskhost] procedure, it is possible to redefine it with a tcl proc. Below you can find a first attempt to such tcl.
Thank you, yes - that will solve most of the problems.

@guppy
The people who write IRCds should be held accountable by their users instead of their users blaming the client writers.
Why people always look for someone to blame?
I didn't blame anyone. I was trying to find a solution to specific problem.
And I signalled that this becomes very popular, so you may expect increasing number of posts. Even DALnet is considering crypting.
Now question is if I can change DALnet and other networks, or some nice guys from eggdrop team are gonna help me?
I have got my answer and thank you guys for your support.
p
ppslim
Revered One
Posts: 3914
Joined: Sun Sep 23, 2001 8:00 pm
Location: Liverpool, England

Post by ppslim »

Guppy is one of the head figures in eggdrop development, so pretty much most of what he says, is usualy what happens.

I agree that the masking functions, are a little weak. They have room for developent. However, this doesn't mean crypted hostmasks should be supported.

OK, lets take 3 fake networks,

NetA - Doesn't use crypted masks.
NetB - Uses crypted masks in the format
nick!ident@d54v5ds21z.isp.com & nick!ident@12451.21254.12542.65214
NetC - Uses crypted masks in the format
nick!ident@user124512.NetC.isp.com & nick!ident@user4124.12541.12541.12541.12511

As it's also been pointed out, not all networks use the same crypting functions, as shown int he example above.

The behaviour is different for each userhost above. Some will work correctly with the masking functions while other won't.

It's not the fault of the masking functions, and it is acting correctly. it's the way the user perceives the output that is incorrect.

If the masking function where to work as you request (please search the forum. You may note this topic has not been talked about for some time, and it's not as comon as you claim), then the code would be very long, as would need to parse, and deal with each scenario, on a case by case basis.

This will increase load times, code size and will likely cause a administration nightmare.
Locked