In message <200912080939.nB89dIXn090157@aurora.sol.net>, Joe Greco writes:
In message <200912080332.nB83WKSo037049@aurora.sol.net>, Joe Greco writes:
IMHO there is no need for any sort of DNS redirection after user authentication has taken place.
It may be hazardous even before user authentication has taken place. Even given a very low TTL, client resolvers may cache answers returned during that initial authentication.
We of course redirect UDP/TCP 53 to one of our servers along with 80 (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any authentication has occurred, but once this is completed the only reason any guest would use the local DNS server is if they were assigned a DHCP address.
Which, presumably, many/most of them are. Supplying a functional DNS server shouldn't be that difficult, but real world experience shows just how well some operators run these services.
As far as our Routerboard/Mikrotik setup works, it'll masquerade for any non standard IP addresses that appear on the network (guests with static ip's assigned, corporate laptops etc) but once again after the authentication stage anything is allowed to pass unhindered.
The only redirection that is used after authentication is for port 25 as 90% of user trying to send mail out via port 25 have no idea how to change their mail server, let alone why they might need to. It can be an issue as some systems use authentication on port 25.
Sounds like an opportunity for a custom proxy. Clients that can successfully authenticate to an external mailserver on 25 are probably by definition nonproblematic. The remainder probably deserve to get jammed through an aggressive spam, virus, and other-crap filter, with in-line notification of rejections. You can do some other sanity stuff like counting the number of hosts contacted by a client; anything in excess of a small number would seem to be a good indicator to stop.
This really should be a DHCP option which points to the authentification server using ip addresses. This should be return to clients even if they don't request it. Web browers could have a hot-spot button that retrieves this option then connects using the value returned.
No need to compromise the DNS or intercept http.
But that doesn't change the fact that there's a need; it's a part of the flawed design of the various components, because this problem wasn't envisioned and solved and now we have a mess. Even the hotspot vendors cannot agree on a unified way to do things; this means that each network you try to connect to will implement its own set of unique brokenness, ranging from requirements for a particular OS/browser, use of reserved/ allocated IP spaces for stupid reasons (hi, 1.1.1.1!), various DNS/HTTP attempts at redirection, blocking, etc.
I know what you're saying, but seriously, haven't we just repeated all the same mistakes in IPv6? And of course it'd be a nightmare to cover all the edge cases, this is why nobody tries to figure it out, so in the end we end up with many really cruddy hatchet jobs.
Why would "web browsers" have a hot-spot button?
Because that would be a easy way to implement this sort of thing. You could have a command line tool or a seperate widget that that launched the browser.
What if I want to just use ssh?
You still need to authenticate. It's better if we can reduce the amount of collateral damage required to authenticate. The interception is being done today because there is no standard way to say "go here to authenticate" and the hotspot provider has to do a man in the middle attack to get you to the authentication page.
And where's the web browser on my VoIP telephony adapter, etc? :-)
Does you VoIP telephony adapter work today in hotspots that require authentication? It isn't that hard to build in a display. Having a DHCP option is better than the mess we have now. To go further requires agreement on how to present terms, pricing etc. in a standardised way.
It's gotta be difficult for the hotspot networks. Even at&t can't seem to make it all work right even when they control both sides; I've seen iPhones just hang when connecting to attwifi (and I can say I've seen it not work in some way maybe even more often than I've seen it actually work). At least the iPhone seems to have some built-in support for this sort of thing. (Anybody know anything more about that?)
... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org