On 2013-10-01 10:27:14 -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander <magnus@hagander.net> wrote:
> >> If we can't feel comfortable with an ERROR, let's not do it at all.
> >
> > In principle, I agree.
> >
> > However, if we want to do this as a temporary measure to judge impact,
> > we could do WARNING now and flip it to ERROR in the next minor
> > release.
>
> I can't imagine that whacking the behavior around multiple times is
> going to please very many people.
If we have to whack it around, it's because there's a bug in either our
usage of openssl or in openssl itself. Neither is particularly unlikely,
but it's not like not erroring or warning out will stop that.
The alternate reason for getting the WARNING/ERROR is that there is
somebody MITMing the connection and explicitly corrupting renegotiation
packets. But that's a reason for making it an ERROR immediately, not
making it silent. I think from the security POV it's pretty clear that we
should make it an error.
So, imo the question is why are we uncomfortable making it an ERROR
immediately? I think the most likely reason for problems is users having
configured ssl_renegotiation_limit absurdly low, like less than what the
particular algorithms used actually need. What about clamping it to 1MB
if != 0? We can't make it an actual error in the backbranches...
> > If we do, the it might be
> > worth doing that. If we don't believe we'll get any input from the
> > WARNINGs anyway, we might as well flip it to an ERROR. But if we do
> > flip it to an ERROR, we should have a way to disable that error if, as
> > Alvaro puts it, we end up breaking too many things.
>
> A way of disabling the error seems like an awfully good idea. Since I
> know my audience, I won't suggest the obvious method of accomplishing
> that goal, but I think we all know what it is.
In which scenario would you want to do that? The way to prevent the
ERROR it is to disable renegotiation entirely. And that's already
possible. Anything else seems like papering over security issues.
I guess I am voting for making renegotiation failure an ERROR everywhere
and silently clamp renegotiation_limit to a lower bound of 1MB in the
backbranches while making the (0, 1MB) an error in HEAD.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
