Mitch and Chris,

A little overview might help with why I'm thinking about this and how
the problem got more complex than it needed to.

Our system is accessed by remote workers in many many locations.  Some
locations are run by technocrats.  For instance one of the sites will
establish a VPN but we must open all ports in both directions.  This
violates more than a couple of rules not to mention common sense.  Any
other configuration will result in <loud booming voice> "tunnel
termination."  Other locations are not interested in allowing us any
VPN access in any format.

So we setup the system to run SSL and things were great for a while. 
Then a new IIS issue allowed a script kiddie to take over.  We've
since taken the server off the Internet.  That wasn't a popular
decision for those of us who like our jobs.

So I'm seeking something to buffer our server from the real world.  My
thought is to use something like the captive portal.  Here's the
thought process:

User connects via https 1.1 to the gatekeeper,
User authenticates to the gatekeeper,
The gatekeeper passes the user through to the real server,
When the user is done they close the browser and https 1.1 keep alive
goes bye bye killing the rules to pass the connection from that IP

Some thoughts on how to put this together:

Simple if everything can be wrapped into m0n0wall through modules:
   Internet -> m0n0wall -> Server

No SSL, No Problem:
   Internet -> SSL Acelerator -> m0n0wall -> Server

Can't pass through, okay this is getting sticky:
  Internet -> SSLA -> m0n0wall on IP 1
  Internet -> m0n0wall on IP2 -> server

This all hinges on:
   Captive portal working over SSL
   Captive portal working with Radius
   Some way to pass through the SSL session or redirect it to a second
IP under captive portal control (one IP is better, two can work)
   A lot of time to tinker this into existence and a bunch of help

One problem I see to this whole idea is that if someone auths from
behind a NAT everyone behind that NAT will be allowed in.  This could
be a problem but I think it is better odds than the entire world being
able to scan and attack the server.  Part of me feels like there's a
real need for something like this.  Another part fears the person who
doesn't think about the security possibilities before they use it.

<Mitch>
> Not sure if that was your original idea, but I think that's a GREAT one...

Thanks.  I'm not so sure it is great and I'm glad to have a few folks
to bounce it around.  I can see some serious issues but if taken in
the right light I'm all for improving the odds.

<Mitch>
> If I'm completely confusing or perverting your original idea, smack me - but
> is this what you were thinking? Is it possible?

I think you hit the idea on the head Mitch.  It needs a bit more
thought but I think it is possible by sliding the right parts
together.  Of course that makes it sound real easy and I have no
delusions of ease.

<Chris>
> it would have to pass the credentials over the net in clear
> text.  And you might have to do a little hacking on captive portal to
> keep it from opening all ports to authenticated users, though firewall
> rules may suffice.

It would have to support at least SSL or it isn't viable  I'm going to
have to look at the captive portal to understand how it works the
magic.  My guess is it inserts an allow rule on successful auth and
that could easily be altered.

<Mitch>
> The goal here is to allow selective access to THEORETICALLY secure services
> without opening them to the world JUST IN CASE.

Mind if I steal that for my presentation.  I just love how that
sounds!  I guess that pegs me as a security nut.

<Mitch>
> How will the session be maintained for the remote user?

I'm thinking HTTP 1.1 keep alive.  I don't know if that works over SSL
but seeing as SSL is a streaming encryption service I can't imagine it
would change HTTP 1.1 specs too much.  Time for some RFC reading.

<Mitch>
> Assumed actions:

Your list is good.

<Mitch>
> SO - here is my quandry... how does the user maintain their session? By
> keeping the https:// login page option (which could have some sort of
> meta-refresh to provide a "keep-alive"?)

Do we have to have a meta-refresh?  Doesn't HTTP 1.1 provide a keep
alive function or does it close the port after a period of inactivity?

<Mitch>
> I sure see the value in this - just not sure how hard it would be to do.

Close to impossible.  <grin>  Now no matter how hard it is its so much
easier than I thought!

I really appreciate you guys bouncing this around.  I'm sure it can be
done and I'm willing to put some effort into it.  I'm pretty good with
the protocol standards and research and I'm not too shabby at hacking
on someone else's great work.

Thanks,

Mike