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 removing
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 number of
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 think so.
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
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.
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
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
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
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
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
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 there's two
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
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)
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
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 backpatch
On Fri, Nov 15, 2013 at 10:49 AM, Andres Freund and...@2ndquadrant.com 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
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.
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
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 ready.
Alvaro Herrera alvhe...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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,
On 2013-11-15 10:58:19 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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
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, Oct 1, 2013 at 9:16 AM, Alvaro Herrera alvhe...@2ndquadrant.com 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
On Tue, Oct 1, 2013 at 4:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 1, 2013 at 9:16 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Since back branches releases are getting closer, I would like to push
this to all supported branches. To avoid a compatibility nightmare in
On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander mag...@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
On 2013-10-01 10:27:14 -0400, Robert Haas wrote:
On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander mag...@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,
On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
alvhe...@2ndquadrant.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
Robert Haas escribió:
On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
alvhe...@2ndquadrant.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
On Tue, Sep 24, 2013 at 12:30 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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:
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 Fri, Jul 12, 2013 at 8:51 PM, Noah Misch n...@leadboat.com 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
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 Hat
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 persuasive
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:
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 go
On Thu, Jul 11, 2013 at 4:20 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Thu, Jul 11, 2013 at 1:13 AM, Sean Chittenden s...@chittenden.org 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
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
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
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)
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
46 matches
Mail list logo
