On Tue, 11 Jul 2000, Brian J. Murrell wrote:
> I would tend to issue client-side certs and authenticate them at the
> reverse SSL proxy in addition any "server based" authentication that I
> did at the web/mail server(s). That way if there is a buffer overflow
I'd shy away from client-side certificates unless I had some pretty
specific OS security, and even then I'd be wary due to laptop users and
home-based users who may not be able to physically secure their machines.
> or other authentication information driven attack in the web/mail
> servers, they will not get exploited unless the cracker can satisfy the
> reverse proxy with a certificate.
Given malicious code, traveling machines and terminations, that's not
always the bar it should be.
I'd look closely at two-factor (hard token-based) authentication or
challenge-response authentication. Both of those can solve not only the
insecurity issue, but the issues with malicious code presenting a
certificate when a luser isn't present.
> jail sounds wonderful for that! The other problem is social. If you
> have certificate leaks you need to terminate somebody's access
> immediately!
The problem is discovering a certificate leak, or worse-yet having to
regen the root certificate in case of compromise (or employee
termination with CA access) with a large number of remote and active
users. IMO it's better to rely on hardware than people if at all
possible- redundant hardware is cheap ;)
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
