On Sat, Oct 31, 1998, Ben Laurie wrote:
>[...]
> > While you may think that the only way to run a SSL server is where no one
> > can login, no users can run any programs on it, etc. in the real world
> > that isn't always possible.
>
> I have to say that my main interest is in secure servers. If people want
> to run toy SSL servers, then I'll support them as far as I can, but not
> if it means compromising the safety of the real ones. That said, I
> haven't said that no one can log in, no users can run programs, etc.
> You've just invented that requirement. What I have said is that my
> threat model says that a local attacker is something that should not be
> permitted.
Ben, seems like you think that when something has to be secure it has to
implicate that it cannot be robust at the same time. This has not to be the
case: It can and should be always robust _AND_ secure. Both are important the
same way: Because lack of robustness opens new security holes. So security
software has to be designed and implemented in a robust way, then checked for
any special security problems and finally enhanced with security checks (DoS,
etc.) in _addition_ to the standard error checks, IMHO.
> Bottom line: if gcache is a problem in your environment, disable it.
Hmmm... is this very user friendly, Ben? I think we cannot say: "Hey, here is
the SSL solution. When something of it bores you, disable it" just because we
didn't spent enough time to make it as secure and robust as it should be to be
acceptable for the users. Then it's better at least to disable it all the time
and declare it as an experimental feature. I personally think the default
functionality should be already as secure and robust that users don't have
problems with it, shouldn't it?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
