Ralf S. Engelschall wrote:
>
> 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.
Yawn. I knew I'd regret saying that. I'm not suggesting that they are
mutually exclusive, I'm just saying that I need to know that there is a
problem before I fix it, and if that means it has to go wrong first, so
be it. But the point is that I don't believe there's a problem. I don't
think I should change the way it works on the off-chance that there
_might_ be a problem.
> > 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?
It should. And as far as I know, it is. All this is pure speculation,
arising from your original stance that "assertions are bad", which you
now agree is not actually true. You are now trying to find a way to
demonstrate that my assertions are bad, while yours are good. So you are
invoking an error condition that is not known to occur to justify the
argument. I'm getting bored with this, I have to admit.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
