Forums Bug Reports $serverip returns 255.255.255.255

When using my perl Simple SOCKS Server as a firewall in mIRC it seems to return the $serverip as 255.255.255.255.

Why does mIRC return 255.255.255.255 instead of either the irc server I am connected to?

How does mIRC gather the $serverip value?

Thanks.

Probably from RAW 001-005:

Your host is irc.igs.ca[205.210.145.3/6667], running version ircd-ratbox-2.2.8

Odd. Is that SOCKS4, SOCKS4a or SOCKS5?


SOCKS5 (and less notably SOCKS4a) doesn't require DNS to be done at the client side. Same goes for HTTP proxies. My guess is: the domain hasn't been resolved at clientside and thus $serverip can't be determined.


Providing it connects via SOCKS4 (not sure about mIRC's implementation for SOCKS4a, but somehow I doubt...) or directly, it needs to resolve the IP first. I agree, it's awkward that $serverip doesn't return correct values and perhaps the algorithm for connecting to proxies needs to be reviewed for next release.


I doubt it. Raw 002 specifies the host, but there is no specific format to the message and many IRCds don't actually give an IP address within raw 001-005. I'm talking large networks, too, for example undernet, dalnet and freenode. In fact getting an IP from undernet would be most incorrect since they specify version of ircu in form uX.X.X.X where x are digits. $serverip is most likely determined if the domain name is resolved, before a connection is established.

@argv0 I'm not sure it does.

Feel free to try for yourself...

Just setup this on your server and connect to it...
https://ssspl.svn.sourceforge.net/svnroot/ssspl/sss.pl

I think @s00p might actually be on to something. I doubt it gathers it from the IRCd, but rather using DNS. But why it's failing to resolve it, I don't know, I can't work it out.

It doesn't fail to DNS the hostname at all. You're using SOCKS5, so it doesn't have to DNS the hostname. The problem is, it isn't DNSing the hostname. How is mIRC supposed to know $serverip if it doesn't DNS the hostname or the SOCKS5 proxy doesn't tell it... iirc the SOCKS5 proxy doesn't have to tell it accurately either.

The following is a rough procedure that describes the way mIRC appears to be connecting via SOCKS5 (and HTTPS?):
1. Connect to the proxy server.
2. Authenticate.
3. Connect the proxy server to the hostname provided.

The modification that's required to accurately fill in $serverip follows the same algorithm as the SOCKS4 connections:
1. DNS the hostname.
2. Pick an IP. Save it as $serverip.
3. Connect to the proxy server.
4. Authenticate.
5. Connect the proxy server to $serverip.
In reality, steps 1-2 and 3-4 could be performed independently, so they could be swapped or performed on different threads.

DNSing the hostname on your own would create a DNS information leak, which could potentially defeat the purpose of using a proxy if the intent is anonymity (a fair use case for a proxy). I'm no anonymity evangelist but I wouldn't recommend changing the existing behaviour-- there's a reason the DNS isn't done locally for these protocols.

@s00p

I don't think you really speak as an authority on this subject.

@argv0

Transparent proxies aren't designed for anonymity.

However, you seem to be implying that this is by design and in fact not a bug. Is this an accurate conclusion?

SOCKS4a and SOCKS5 are designed to be used in environments where, in addition to direct connections, DNS also does not work.

There is no point in making the user wait for the DNS request to time out, when the user already specified to be in such an environment by selecting SOCKS5.

It seems that you are saying that using SOCKS by nature means DNS won't work.

If this was the case, when connecting directly to the server ip, eg: 66.225.225.225, $serverip would return 66.225.225.225, because it wouldn't need to resolve the server hostname.

However, it does not, it returns 255.255.255.255.

I'm not convinced the issue has been properly identified.

I am still interested to know exactly where $serverip pulls the ip address from.

I believe this has been alluded to above, if not explicitly stated-- mIRC is not filling in $serverip in the case where it is not DNSing, and the default placeholder is apparently "255.255.255.255"... that seems to fit.

So I assume I can safely file this as a bug with mIRC, not my socks server.

Further more, you're saying it's not a bug in mIRC, it is in fact by design.

Do we expect that this may be developed further or is this a persistent feature (or deliberate bug)?

Otherwise, do you have any advice for users who use a socks server and wish to use $serverip?

Thanks.

That's right: 255.255.255.255 is in fact the default value for a non-resolved address (INADDR_NONE). As someone mentioned in an earlier post, when using SOCKS5 mIRC does not need to resolve the address since 1) It is not connecting directly to that address, 2) The SOCKS5 server is performing the name resolution, and 3) The client may not be able to perform name resolutions.

That said, does anyone see any issues with making mIRC independently attempt a name resolution when connecting through a SOCKS5 server? On a secure/closed network that limits access through a SOCKS5 server, the worst that can happen is that the DNS fails. On the other hand, a separate DNS may show that address in your connection logs, whereas connecting through the SOCKS5 server and letting it perform the name resolution will not. Just a thought.

Thanks for your input Khaled, that makes more sense now.

Perhaps you can gather the server ip (if required) when $serverip is called rather than at connect time, that way the user has a choice.

That wouldn't be too difficult to impliment right?

Thanks.

Thankyou for confirming my belief.

You've named the section "firewall settings". Most IRCd administrators are thoroughly anti-anonymous proxy, as they allow ban evasions and fun stuff like flooding. Thus, I assume the idea behind naming it "firewall" is to imply that it should be used for application layer firewalls only. In this case, DNS may fail. IRC is also likely to fail.

If you have a look at the SOCKS4a/5 draft iirc it's slightly suggestive that the DNS features of the proxies are only to be used in the case where DNS resolution has failed locally. The most sensible way of handling this would be to add a checkbox to the "firewall settings" dialog that has the caption "resolve DNS locally", and allow input for SOCKS4a, SOCKS5 and HTTP since SOCKS4 alone has no mechanism for remote DNS resolution. The rest is self-explanitary.



That would be impossible to implement accurately in some cases. Take for example, irc.quakenet.org. DNS it using the command line:

The proxy server will pick an IP by it's own means (which is implementation defined) and connect to it. The server may tell your client the correct IP, if it has a mechanism to do so, or it may simply tell your client 0.0.0.0 (as many SOCKS4a proxies do). Your suggestion is trash, and you have no authority either. Stop treating me like I'm some idiot.

SOCKS5 can be used for UDP communication. Another option may be to use SOCKS5 to send DNS packets over UDP.

I assume the DNS would occur in a separate thread? Otherwise I would see a useless delay in the worst case scenario-- the worst case scenario being common for someone using a proxy. I also think the DNS leak should also be a concern to people using a proxy.

An extra option for DNSing would probably be the best idea here, if the behaviour is changed.

In the meantime, what's wrong with /dns'ing the server manually? Why do you really need $serverip? It seems to be merely a convenience identifier.

It's not a useless delay, because someone still needs to do the DNS resolution. In order to obtain $serverip accurately, DNS resolution needs to be done before the tunnel is established so that the client can specify exactly which IP to connect to in the connection request. Windows uses the nameserver found in your adapter settings to query domains, then the query follows DNS RFC behaviour. Nameservers don't forward the IP of their clients.

Your argument regarding anonymity is silly, because proxies don't make you anonymous. I would be far more worried about who is running my public "anonymous" proxy, if I used one: your neighbour, the police, my IRC administrators (maybe they want to know who is flooding their network with proxies?), some hacker who wants to take advantage of vulnerable scripts that use $read insecurely...? Who do you think runs most "anonymous" proxies? Why do you think people run them, because they want people they don't know to be "anonymous"? No, they run them because they have something to gain, or because they want to secure their network using an application layer firewall (in which case they're not "anonymous").

The purpose of mIRC's proxy implementation appears to be for "application layer firewalls" (thus the word "firewall" used throughout), so there aren't many options. These, in order:
1. In most cases, a client can resolve locally.
2. In the case where a proxy implements UDP (SOCKS5), a simple DNS client can be layered on top. You'd need to find out which DNS server to query in the first place, which could result in more information disclosure than step 1. At least you'd have an IP to store for $serverip.
3. In the case where a proxy does not implement UDP, the client can send the hostname in the connection request and trust the proxy to choose an IP. The proxy may, or may not respond accurately with the IP it chose. This is the current behaviour for SOCKS5, where it should probably start at step 1 (as the SOCKS documentation suggests, IIRC). You could use the IP it responded with for $serverip (which may be the current behaviour), but that's guaranteed to be more inaccurate than the above methods.

I agree.

I've had a number of users ask me about why $serverip returns 255.255.255.255 instead of the server IP when using my socks server, so I guess some people would find it useful.

I think you missed the point. The proxy server will typically be able to do the DNS resolution -- the client may or may not. If the client is not, a client-side attempt at resolution incurs a delay. That is the worst case, and a realistic one at that.


Nobody argued that anonymity is only relevant when using a public proxy. Did you know that TOR comes with a SOCKS interface? I'm not saying that mIRC should cater to TOR users, but the argument is certainly valid. And no, if you really care about anonymity, you will not be willing to trust your ISP's nameserver either.


Assumptions. I think the only legitimate proxy users will suffer from the delay caused by this assumption. And that just for $serverip? Feel free to disagree, but I think all this is just not worth it.

*One* purpose of proxies is indeed to deal with firewall restrictions.

*Another* perfectly valid purpose of proxies is anonymity. You may not agree with the use case (I generally don't), but it happens to be one. Just because you believe the vast majority of "anonymous proxies" are hackers doesn't justify removing behaviour for the valid use cases. A discussion about how many people use proxies responsibly is as irrelevant as a discussion about how many people use /fserve for legal content-- they're both features that should be properly implemented with the responsible users in mind. Anonymity happens to be a use case for some proxy users, and it's hardly your place to make any judgement on their behalf.

The rest was answered quite succinctly by Sat.

PS. it seems you don't quite understand what DNS Information Leak is and why it can be an issue, so here.

That diagram doesn't explain the DNS heirarchy sufficiently for you to understand why this isn't an anonymity issue. If that site suggests that anonymity is an issue, that site is wrong. See the second comment on that page. Also see the 7th comment on that page. The reason the leak is a "leak" is because it forces you to use a local nameserver, instead of the proxy's nameserver.

Here's a diagram that explains domain resolution for a typical Windows box:
Note, there's a local nameserver standing between you and the remote nameserver, and that local nameserver doesn't pass your IP on.

I do agree that it would be convenient for firefox (edit: and mIRC) to have a method of choosing (and forcing) between local and remote lookup, however, because proxies are sometimes used as application level firewalls. As I said earlier, the original SOCKS docs from socks.permeo.org (which has been down for years now so you'll have to trust me when I quote them) recommended that the DNS be done locally if possible, then remotely as an alternative.



See how it says, "if the client can not resolve ..."? Now, the relevant part of the SOCKS5 docs:



It then barely mentions domain resolution at all, aside from specifying where a domain name would belong. While perhaps you are correct in that it could incur an unwelcome delay (that wouldn't be much) for actual application level firewalls, a checkbox would remedy this. There's no security risk. In the very likely event that the client can resolve the name, I'd suggest there would be no comparable delay. As a result, $serverip would be far more likely to evaluate accurately.