On 02/23/2015 04:01 PM, Albe Laurenz wrote:
>> I think you could remove renegotiation from PostgreSQL as long as you
>> offer something better than RC4 in the TLS handshake.
>
> I'd say it is best to wait if and how OpenSSL change their API when they
> implement TLS 1.3.
>
> I'd vote against rem
Renegotiation should be a best practice. Trouble is it's been broken (at the
protocol level) three times in the last few years so it's a massive hole in
practice.
Ideally we should leave the renegotiate in, and only remove it if configure
detects a broken version of TLS.
Personal email. hbh..
On 2015-02-23 15:15:31 +0100, Florian Weimer wrote:
> On 02/22/2015 02:05 PM, Andres Freund wrote:
> > On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
> >> I honestly wonder why postgres uses renegotiation at all. The motivation
> >> that cryptoanalysis is easier as more data is sent seems quite
Florian Weimer wrote:
> On 02/22/2015 02:05 PM, Andres Freund wrote:
>> On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
>>> I honestly wonder why postgres uses renegotiation at all. The motivation
>>> that cryptoanalysis is easier as more data is sent seems quite
>>> far-fetched.
>>
>> I don't t
On 02/22/2015 02:05 PM, Andres Freund wrote:
> On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
>> I honestly wonder why postgres uses renegotiation at all. The motivation
>> that cryptoanalysis is easier as more data is sent seems quite
>> far-fetched.
>
> I don't think so. There's a fair numbe
On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
> I honestly wonder why postgres uses renegotiation at all. The motivation
> that cryptoanalysis is easier as more data is sent seems quite
> far-fetched.
I don't think so. There's a fair number of algorithms that can/could be
much easier be attac
Hi.
I noticed your latest mail thread about ssl renegotiations and this commit
by hlinnaka:
https://github.com/postgres/postgres/commit/272923a0a6956187471df4f032eee06559520390
and how renegotiation is done since that.
Before this commit, after sending a Hello Request, the backend waits until
the
On 02/12/2015 01:41 AM, Andres Freund wrote:
Hi,
On 2015-02-05 23:03:02 +0200, Heikki Linnakangas wrote:
On 01/26/2015 12:14 PM, Andres Freund wrote:
Hi,
When working on getting rid of ImmediateInterruptOK I wanted to verify
that ssl still works correctly. Turned out it didn't. But neither di
On 02/12/2015 01:33 AM, Andres Freund wrote:
On 2015-02-11 14:54:03 +0200, Heikki Linnakangas wrote:
Thoughts? Can you reproduce any errors with this?
I'm on battery right now, so I can't really test much.
Did you test having an actual standby instead of pg_receivexlog? I saw
some slightly di
Hi,
On 2015-02-05 23:03:02 +0200, Heikki Linnakangas wrote:
> On 01/26/2015 12:14 PM, Andres Freund wrote:
> >Hi,
> >
> >When working on getting rid of ImmediateInterruptOK I wanted to verify
> >that ssl still works correctly. Turned out it didn't. But neither did it
> >in master.
> >
> >Turns out
On 2015-02-11 14:54:03 +0200, Heikki Linnakangas wrote:
> Thoughts? Can you reproduce any errors with this?
I'm on battery right now, so I can't really test much.
Did you test having an actual standby instead of pg_receivexlog? I saw
some slightly different errors there.
Does this patch alone wo
Heikki Linnakangas wrote:
>> Can we work-around that easily? I believe we can. The crucial part is
>> that we mustn't let SSL_write() to process any incoming application
>> data. We can achieve that if we always call SSL_read() to drain such
>> data, before calling SSL_write(). But that's not quite
On 02/05/2015 11:03 PM, Heikki Linnakangas wrote:
On 01/26/2015 12:14 PM, Andres Freund wrote:
Can we work-around that easily? I believe we can. The crucial part is
that we mustn't let SSL_write() to process any incoming application
data. We can achieve that if we always call SSL_read() to drain
On 01/26/2015 12:14 PM, Andres Freund wrote:
Hi,
When working on getting rid of ImmediateInterruptOK I wanted to verify
that ssl still works correctly. Turned out it didn't. But neither did it
in master.
Turns out there's two major things we do wrong:
1) We ignore the rule that once called and
On 2015-01-26 11:14:05 +0100, Andres Freund wrote:
> My testcase for this is just to setup a server with a low
> ssl_renegotiation_limit, generate lots of WAL (wal.sql attached) and
> receive data via pg_receivexlog -n. Usually it'll error out quickly.
...
Greetings,
Andres Freund
--
Andres F
Hi,
When working on getting rid of ImmediateInterruptOK I wanted to verify
that ssl still works correctly. Turned out it didn't. But neither did it
in master.
Turns out there's two major things we do wrong:
1) We ignore the rule that once called and returning
SSL_ERROR_WANTS_(READ|WRITE) SSL_
On Mon, Aug 25, 2014 at 11:46:13PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > OK, then maybe end-of-beta is too long. But how much testing will it get
> > during development? I know I never use SSL on development installs.
> > How many hackers do?
>
> Just a reminder that I intend to bac
Tom Lane wrote:
> Andres Freund writes:
> > On 2013-11-15 10:43:23 -0500, Tom Lane wrote:
> >> Another reason I'm not in a hurry is that the problem we're trying
> >> to solve doesn't seem to be causing real-world trouble. So by
> >> "awhile", I'm thinking "let's let it get through 9.4 beta testi
On Fri, Nov 15, 2013 at 10:49 AM, Andres Freund wrote:
>> Another reason I'm not in a hurry is that the problem we're trying
>> to solve doesn't seem to be causing real-world trouble. So by
>> "awhile", I'm thinking "let's let it get through 9.4 beta testing".
>
> Well, there have been a bunch of
On 2013-11-15 10:58:19 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-11-15 10:43:23 -0500, Tom Lane wrote:
> >> Another reason I'm not in a hurry is that the problem we're trying
> >> to solve doesn't seem to be causing real-world trouble. So by
> >> "awhile", I'm thinking "let's let
Andres Freund writes:
> On 2013-11-15 10:43:23 -0500, Tom Lane wrote:
>> Another reason I'm not in a hurry is that the problem we're trying
>> to solve doesn't seem to be causing real-world trouble. So by
>> "awhile", I'm thinking "let's let it get through 9.4 beta testing".
> Well, there have b
Alvaro Herrera writes:
> So I committed this patch without backpatching anything. ...
> ... should we wait longer for the new renegotiation code to
> be more battle-tested?
+1 to waiting awhile. I think if we don't see any problems in
HEAD, then back-patching as-is would be the best solution.
Th
On 2013-11-15 10:43:23 -0500, Tom Lane wrote:
> +1 to waiting awhile. I think if we don't see any problems in
> HEAD, then back-patching as-is would be the best solution.
> The other alternatives are essentially acknowledging that you're
> back-patching something you're afraid isn't production rea
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> 1. Don't backpatch the ERROR bit at all, so that if the renegotiation
> fails we would silently continue just as currently
I'm leaning towards the above at this point.
> I was reminded of this once more because I just saw a spurious
>
So I committed this patch without backpatching anything. There was some
discussion about the exact strategy for backpatching the behavior
change, but no final agreement; the suggestions were
0. Backpatch as an ERROR. If it causes failures, people is supposed to
change their apps or something.
1
On 09/23/2013 10:51 PM, Alvaro Herrera wrote:
> + /* are we in the middle of a renegotiation? */
> + static bool in_ssl_renegotiation = false;
> +
Since this was committed, I'm getting the following warning:
be-secure.c:105:13: warning: ‘in_ssl_renegotiation’ defined but not used
[-Wunused-varia
On 2013-10-01 10:27:14 -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander 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 c
On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander 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
> re
On Tue, Oct 1, 2013 at 4:17 PM, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 9:16 AM, Alvaro Herrera
> wrote:
>> Since back branches releases are getting closer, I would like to push
>> this to all supported branches. To avoid a compatibility nightmare in
>> case the new die-on-delayed-renegotia
On Tue, Oct 1, 2013 at 9:16 AM, Alvaro Herrera wrote:
> Since back branches releases are getting closer, I would like to push
> this to all supported branches. To avoid a compatibility nightmare in
> case the new die-on-delayed-renegotiation behavior turns out not to be
> so great, I think it wou
Since back branches releases are getting closer, I would like to push
this to all supported branches. To avoid a compatibility nightmare in
case the new die-on-delayed-renegotiation behavior turns out not to be
so great, I think it would be OK to set the error level to WARNING in
all branches but
On Tue, Sep 24, 2013 at 12:30 PM, Alvaro Herrera
wrote:
> I mean, if that 1kB limit is the only quarrel you have with this patch,
> I'm happy.
You should probably be happy, then. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
Robert Haas escribió:
> On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
> 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).
> >
On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
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 tha
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
Here's the patch I propose to handle renegotiation cleanly. I noticed
in testing that SSL_renegotiate_pending() doesn't seem to actually work
--- if I throw an ereport(FATAL) at the point where I expect the
renegotiation to be complete, it always dies; even if I give it
megabytes of extra traffic
On Tue, Jul 16, 2013 at 10:41:44AM -0700, David Fetter wrote:
> On Fri, Jul 12, 2013 at 08:51:52PM -0400, Noah Misch wrote:
> > Agreed. The OpenSSL Project last applied a security fix to 0.9.6
> > over eight years ago. Compatibility with 0.9.6 has zero or negative
> > value.
>
> You've made a pe
On Fri, Jul 12, 2013 at 08:51:52PM -0400, Noah Misch wrote:
> On Fri, Jul 12, 2013 at 04:32:52PM -0400, Alvaro Herrera wrote:
> > Now, should we support the 0.9.6-and-earlier mechanism? My
> > inclination is no; even RHEL 3, the oldest supported Linux
> > distribution, uses 0.9.7 (Heck, even Red H
On Fri, Jul 12, 2013 at 8:51 PM, Noah Misch wrote:
> On Fri, Jul 12, 2013 at 04:32:52PM -0400, Alvaro Herrera wrote:
>> Now, should we support the 0.9.6-and-earlier mechanism? My inclination
>> is no; even RHEL 3, the oldest supported Linux distribution, uses 0.9.7
>> (Heck, even Red Hat Linux 9,
On Fri, Jul 12, 2013 at 04:32:52PM -0400, Alvaro Herrera wrote:
> Now, should we support the 0.9.6-and-earlier mechanism? My inclination
> is no; even RHEL 3, the oldest supported Linux distribution, uses 0.9.7
> (Heck, even Red Hat Linux 9, released on 2003). To see OpenSSL 0.9.6
> you need to g
Troels Nielsen escribió:
> Hi,
>
> These are the relevant bits from Apache2.4's mod_ssl.
>
> [snip]
So this is basically the same thing the Pg code is doing.
> That code supports at least OpenSSL 0.9.7 and later.
>
> Some explanation for it can be found here:
>
> http://books.google.dk/books?
On Thu, Jul 11, 2013 at 1:13 AM, Sean Chittenden wrote:
>> , I suppose two things can be done:
>>
>> 1. Quit the connection
>
> With my Infosec hat on, this is the correct option - force the client
> back in to compliance with whatever the stated crypto policy is through
> a reconnection.
>
>> 2.
On Thu, Jul 11, 2013 at 4:20 AM, Alvaro Herrera
wrote:
> I'm having a look at the SSL support code, because one of our customers
> reported it behaves unstably when the network is unreliable. I have yet
> to reproduce the exact problem they're having, but while reading the
> code I notice this i
> If the renegotiation fails
AH! Now I remember. SSL clients can optionally renegotiate, it's not
required to renegotiate the session if the other side chooses not to
(almost certainly due to a bug or limitation in the client's connecting
library). By monkeying with the state, you can explicitly f
Hi,
These are the relevant bits from Apache2.4's mod_ssl.
SSL_renegotiate(ssl);
SSL_do_handshake(ssl);
if (SSL_get_state(ssl) != SSL_ST_OK) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(02225)
"Re-negotiatio
I think this block is better written as:
if (ssl_renegotiation_limit && port->count > ssl_renegotiation_limit *
1024L)
{
SSL_set_session_id_context(port->ssl, (void *) &SSL_context,
sizeof(SSL_context));
if (SSL_renego
Hi,
I'm having a look at the SSL support code, because one of our customers
reported it behaves unstably when the network is unreliable. I have yet
to reproduce the exact problem they're having, but while reading the
code I notice this in be-secure.c:secure_write() :
if (ssl_renegotiatio
47 matches
Mail list logo
