[wd-isf] Captive DNS, and auth server bypass

[Mina Naguib]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Alexandre Carmel-Veilleux wrote:
| On Sun, Feb 06, 2005 at 01:50:04PM -0500, Mina Naguib wrote:
|
|>I think that alone is worth the extra effort.  It also opens the door
|>for many "neato" fake servers built-into wifidog, such as pop3 server
|>that delivers a message "Please use a web browser first to log in at
|>http://foo.bar", etc...
|
|
| 	Well, the issue with that one is that we'd then have to deal
| with forcing the client to send username and passwords in clear text to
| the gateway...

We're not asking the client to do anything they would not do anyways.
If they are using regular unencrypted POP3 then the credentials will be
sent in cleartext anyways when they check their mail after a successful
login.

The proposed fake POP3 server I had in mind would not do any real
authentication. The arguments to the "user" and "pass" commands from the
client would always result in "OK" and the actual parameters would be
ignored. "list" would always produce 1 message id, and "retr" would
always send the same hardcoded message.

This is, of course, icing on the cake.  I'm just projecting some ideas
once wifidog is very stable and we're all bored :)

An extrapolation on the fake POP3 service is a real, secure-to-nonsecure
POP3S proxy server where we can offer (privileged?) users a secure POP3S
connection between them and the router to prevent sniffing.  From the
router outwards to their pop3 server is still unencrypted, but it
addresses part of the "wifi is easy to sniff and my email is sensitive"
issue.

|
|
|>1. Attempting to resolve anything will point back to the router until
|>the user is authenticated.  This will definitely interfere with
|>pass-through services like teliphone.
|>
|>Possible solution: "Adaptive" fake DNS where, for certain hostnames, it
|>will reply with the real IP instead of the internal IP.  This is already
|>done for the auth server hostname, so it's simple a matter of a config
|>file section of "hostnames to be truly resolved" by the captive dns
server.
|
|
| 	Some sort of way to integrate that with the firewall would be
| desirable.

I read on slashdot a while ago that there was a layer-7 filtering of
traffic available in the netfilter framework.  It could be done that way.

I'm not really sure that's worth it though, especially under the CPUs of
the WRT54Gs. I think wifidog.conf would allow more flexibility in
configuring the adaptive captive DNS server than implementing it in kernel.

Regarding DNS/TCP, as far as I know this for large replies to overcome
the maximum size of 512 bytes.  Considering this is mainly to forward
clients to the captive http, should we bother ?

|
|
|>2. Once the user receives the IP of the router as the answer to
|>www.homepage.com, they then make an http call http://x.x.y.y:80 - this
|>call must then be intercepted by captive HTTP system instead of by any
|>web server on the router.  In other words, a web server that runs on
|>router (admin/config/etc) needs to run on a port different than port 80
|
|
| 	Clients that run their own DNS servers and connect to the root
| server would have caching issues. We need to make sure we use very short
| TTLs in those DNS replies. We should also implement DNS over TCP.

The TTL for the replies from the fake DNS server are all set to 10
seconds right now.

|
|
|>The ideal solution is to, of course, have multiple
|>geographically-redundant auth servers so we'd never need this, but
|>reality (as we've seen this morning) is not the case. And even if it is
|>the case for ISF, it may not be the case for all wifidog adopters.
|
|
| 	Heh. There ain't no such thing as 100% geographically-redundant
| always up system, I know that for a fact *EG*. I prefer fail open
| systems for most things. We're not guarding a bank vault here.
|
| Alex

I agree, which is why I'd like to pick the brains of everyone regarding
wifidog making certain decisions if it knows it can access the internet
but not the auth server, while keeping in mind the usability of wifidog
to other groups besides IleSansFil.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCBrrkeS99pGMif6wRAn2pAJ9ETW122BQ9PXpXd1Z0iSa3+ju+1gCdFl7I
QgbNXeyRjPa7GX7CE6lbrnc=
=xt8A
-----END PGP SIGNATURE-----
_______________________________________________
wifidog mailing list
wifidog at listes.ilesansfil.org
http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog-listes.ilesansfil.org