Re: SSL renegotiation

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSL renegotiation
Date: 2013-09-24 16:30:47
Message-ID: 20130924163047.GO4832@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas escribió:
> On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > Here's an updated version; this mainly simplifies code, per comments
> > from Andres (things were a bit too baroque in places due to the way the
> > code had evolved, and I hadn't gone over it to simplify it).
> >
> > The only behavior change is that the renegotiation is requested 1kB
> > before the limit is hit: the raise to 1% of the configured limit was
> > removed.
>
> What basis do we have for thinking that 1kB is definitely enough to
> avoid spurious disconnects?

I noticed that the "count" variable (which is what we use to determine
when to start the renegotiation and eventually kill the connection) is
only incremented when there's successful SSL transmission: it doesn't
count low-level network transmission. If OpenSSL returns a WANT_READ or
WANT_WRITE error code, that variable is not incremented. The number of
bytes returned does not include network data transmitted only to satisfy
the renegotiation.

Sadly, with the OpenSSL codebase, there isn't much documented field
experience to go by. Even something battle-tested such as Apache's
mod_ssl gets this wrong; but apparently they don't care because their
sessions are normally so short-lived that they don't get these problems.

Also, I spent several days trying to understand the OpenSSL codebase to
figure out how this works, and I think there might be bugs in there too,
at least with nonblocking sockets. I wasn't able to reproduce an actual
failure, though. Funnily enough, their own test utilities do not stress
this area too much (at least the ones they include in their release
tarballs).

> (I have a bad feeling that you're going to say something along the
> lines of "well, we tried it a bunch of times, and...".)

Well, I did try a few times and saw no failure :-)

I have heard about processes in production environments that are
restarted periodically to avoid SSL failures which they blame on
renegotiation. Some other guys have ssl_renegotiation_limit=0 because
they know it causes network problems. I suggest we need to get this
patch out there, so that they can test it; and if 1kB turns out not to
be sufficient, we will have field experience including appropriate error
messages on what is actually going on. (Right now, the error messages
we get are complaining about completely the wrong thing.)

I mean, if that 1kB limit is the only quarrel you have with this patch,
I'm happy.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2013-09-24 16:46:33 Re: SSL renegotiation
Previous Message Robert Haas 2013-09-24 13:29:01 Re: SSL renegotiation

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-09-24 16:34:48 Re: Completing PL support for Event Triggers
Previous Message Robert Haas 2013-09-24 16:19:51 Re: dynamic shared memory