Re: Logging into FW-1 with SSL?

[czarcone () rpm com]

Scott,

I assume that the ultimate goal here is user authentication for web services. It
might be more helpful to pull back and look at your entire architecture. There
are multple places where you could enforce user authentication:

1. On your firewall (As you've already discovered, this is fine for cleartext
HTTP, but as you've discovered, HTTPS and SSL throws a big wrench in the works.
They're no feasible way around it; if there were, it would essentially be a
man-in-the-middle attack, an attack that SSL was designed to prevent).
2. On the web server itself (Makes sense, but you'd better have faith in your
webserver's resistance to attack).
3. On a reverse proxy (ideally in front of your firewall, or perhaps in a DMZ.)

In every case, your firewall/webserver/proxy needs to support RADIUS
authentication, of which nearly all major commercial packages do (and most of
the better freeware packages like Apache and SQUID).

Writing off (1) altogether, which option you would like to pursue ideally
depends on your security posture and your requirements. I would recommend (2)
for low-to-medium security situations, and (3) for higher security. For the
ultra-paranoid, you could even perform authentication at both points, using
different user identities and passwords.

BTW, what kind of password mechanism are you using within your RADIUS
infrastructure? Are you using one-time tokens like SecurID or S/KEY, or are you
using static passwords? Static passwords for inbound communications is a
Generally Bad Idea, even if your communications path is encrypted. Shoulder
surfing for reusable passwords is your main concern there...

Regards,

Christopher Zarcone
Network Security Consultant
RPM Consulting, Inc.
#include <std.disclaimer.h>
My opinions are completely my own and based on no useful knowledge whatsoever,
and in fact should not be considered by anyone.


> So my question:  Is there some way around this dependency loop, for example,
> is it possible for the firewall to serve up a certificate that would allow
> HTTPS to occur during the authentication at the firewall?  Or is there
> another way around it?  I'm open to any suggestions, or to a plain old
> "Nope, it can't be done".