[Chilli] How to put uamport behind SSL?

[Outback Dingo]

hijacking a port like 443 that could be in use by say apache isnt a great
idea
it would negate the use of chilli and a ssl web server on the same system

On Sun, Nov 29, 2009 at 2:36 PM, David Bird <david at coova.com> wrote:

> Fixed in rev 250. Though, it doesn't do what you outlined. It will
> hijack port 443 and with security error redirect to the captive portal.
> It doesn't do SSL on the UAM port. I suppose it is a straight forward
> feature (perhaps for uamuiport leaving uamport as is).  With that said,
> chilli uses the chap challenge/response style login to secure the
> password. It does reveal a username over plain HTTP, but then again you
> can always use anonymous codes or one-time-passwords. At this point, I
> would use a relay -- chilli already has all the facilities for SSL
> (using openssl at least).
>
> David
>
>
> On Sun, 2009-11-29 at 15:34 +0200, Gunther Mayer wrote:
> > Hi guys,
> >
> > I've been trying to enable clients to communicate to chilli's uamport
> > over SSL for authentication. Our uamserver has been running with SSL
> > from day one but the uamport access is currently still over ordinary
> > http for lack of a better alternative. With newer browsers
> > increasingly complaining about mixed content the time has come to ssl
> > enable chilli's uamport as well (I know - we'll have to get a
> > commercial certificate but that's OK).
> >
> > But how?
> >
> > At first I thought there's a simple solution: use matrixtunnel (or its
> > successor xrelayd with xyssl/polarssl) in front of chilli, i.e. as a
> > proxy to provide a "fake" SSL port for clients which is then forwarded
> > to chilli's normal http uamport. I've got xrelayd installed and
> > working but if I point my browser to
> >
> > https://ua.m.lis.ten:8443/prelogin
> >
> > I just get an empty page instead of the normal login page that I get
> > when using the plain http://ua.m.lis.ten:uamport/prelogin (8443 is the
> > port xrelayd is forwarding to chilli's uamport). I think that's
> > because chilli only sees the http request as originating from the
> > local machine instead of from the client and hence doesn't know what
> > to do. Or am I doing something wrong here?
> >
> > Then I saw the very recent openssl support that David put in trunk
> > this month and thought perhaps that's the solution. However, latest
> > svn (r249) doesn't even compile:
> >
> > $ svn co http://dev.coova.org/svn/coova-chilli
> > $ ./bootstrap2 # ./bootstrap no longer works here :-(
> > $ ./configure --with-openssl
> > $ make
> > cd . && /bin/bash ./config.status config.h
> > config.status: creating config.h
> > config.status: config.h is unchanged
> > make  all-recursive
> > make[1]: Entering directory `/Coova/coova-chilli-1.0.15-pre-r249'
> > Making all in bstring
> > make[2]: Entering directory
> > `/Coova/coova-chilli-1.0.15-pre-r249/bstring'
> > make[2]: Nothing to be done for `all'.
> > make[2]: Leaving directory
> > `/Coova/coova-chilli-1.0.15-pre-r249/bstring'
> > Making all in src
> > make[2]: Entering directory `/Coova/coova-chilli-1.0.15-pre-r249/src'
> > /bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
> > -I..    -D_GNU_SOURCE -Wall -fno-builtin -fno-strict-aliasing -O2
> > -fomit-frame-pointer -funroll-loops -pipe
> > -DDEFCHILLICONF='"/usr/local/etc/chilli.conf"'
> > -DDEFPIDFILE='"/usr/local/var/run/chilli.pid"'
> > -DDEFSTATEDIR='"/usr/local/var/run"'
> > -DDEFCMDSOCK='"/usr/local/var/run/chilli.sock"'
> > -DSBINDIR='"/usr/local/sbin"' -I../bstring  -g -O2 -MT chilli.lo -MD
> > -MP -MF .deps/chilli.Tpo -c -o chilli.lo chilli.c
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -Wall
> > -fno-builtin -fno-strict-aliasing -O2 -fomit-frame-pointer
> > -funroll-loops -pipe -DDEFCHILLICONF=\"/usr/local/etc/chilli.conf\"
> > -DDEFPIDFILE=\"/usr/local/var/run/chilli.pid\" -DDEFSTATEDIR=
> > \"/usr/local/var/run\" -DDEFCMDSOCK=\"/usr/local/var/run/chilli.sock\"
> > -DSBINDIR=\"/usr/local/sbin\" -I../bstring -g -O2 -MT chilli.lo -MD
> > -MP -MF .deps/chilli.Tpo -c chilli.c  -fPIC -DPIC -o .libs/chilli.o
> > chilli.c: In function ‘cb_redir_getstate’:
> > chilli.c:1682: error: ‘struct dhcp_conn_t’ has no member named
> > ‘dnatport’
> > chilli.c:1683: error: ‘struct dhcp_conn_t’ has no member named
> > ‘dnatstate’
> > chilli.c: In function ‘config_radius_session’:
> > chilli.c:2429: warning: passing argument 3 of
> > ‘pass_throughs_from_string’ from incompatible pointer type
> > garden.h:53: note: expected ‘size_t *’ but argument is of type
> > ‘uint32_t *’
> > chilli.c: In function ‘cmdsock_accept’:
> > chilli.c:3756: warning: passing argument 3 of ‘accept’ from
> > incompatible pointer type
> > /usr/include/sys/socket.h:214: note: expected ‘socklen_t *
> > __restrict__’ but argument is of type ‘size_t *’
> > chilli.c: In function ‘redir_msg’:
> > chilli.c:3997: warning: passing argument 3 of ‘accept’ from
> > incompatible pointer type
> > /usr/include/sys/socket.h:214: note: expected ‘socklen_t *
> > __restrict__’ but argument is of type ‘size_t *’
> > make[2]: *** [chilli.lo] Error 1
> > make[2]: Leaving directory `/Coova/coova-chilli-1.0.15-pre-r249/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/Coova/coova-chilli-1.0.15-pre-r249'
> > make: *** [all] Error 2
> >
> > Now I'm really stuck. How do I achieve my goal?
> >
> > Gunther
> > _______________________________________________
> > Chilli mailing list
> > Chilli at coova.org
> > http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>
>
> _______________________________________________
> Chilli mailing list
> Chilli at coova.org
> http://lists.coova.org/cgi-bin/mailman/listinfo/chilli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.coova.org/pipermail/chilli/attachments/20091129/961d314f/attachment.htm>