Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-27 15:07:05 +0900, Michael Paquier wrote: On Sat, Jun 27, 2015 at 6:12 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@anarazel.de writes: On 2015-06-24 16:41:48 +0200, Andres Freund wrote: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. I think by now we essentially concluded that we should do that. What I'm not sure yet is how: Do we want to rip it out in master and just change the default in the backbranches, or do we want to rip it out in all branches and leave a faux guc in place in the back branches. I vote for the latter, but would be ok with both variants. I think the former is probably the saner answer. It is less likely to annoy people who dislike back-branch changes. And it will be significantly less work, considering that that code has changed enough that you won't be able to just cherry-pick a removal patch. I also fear there's a nonzero chance of breaking stuff if you're careless about doing the removal in one or more of the five active back branches ... +1 for removing on master and just disabling on back-branches. The problem with that approach is that it leaves people hanging in the dry if they've uncommented the default value, or changed it. That doesn't seem nice to me. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Andres Freund and...@anarazel.de writes: On 2015-06-27 15:07:05 +0900, Michael Paquier wrote: +1 for removing on master and just disabling on back-branches. The problem with that approach is that it leaves people hanging in the dry if they've uncommented the default value, or changed it. That doesn't seem nice to me. I think at least 99% of the people who are using a nondefault value of ssl_renegotiation_limit are using zero and so would have no problem with this at all. Possibly 100% of them; there's not really much use-case for changing from 512MB to some other nonzero value, is there? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-27 12:10:49 -0400, Tom Lane wrote: Andres Freund and...@anarazel.de writes: On 2015-06-27 15:07:05 +0900, Michael Paquier wrote: +1 for removing on master and just disabling on back-branches. The problem with that approach is that it leaves people hanging in the dry if they've uncommented the default value, or changed it. That doesn't seem nice to me. I think at least 99% of the people who are using a nondefault value of ssl_renegotiation_limit are using zero and so would have no problem with this at all. Possibly 100% of them; there's not really much use-case for changing from 512MB to some other nonzero value, is there? While still at 2ndq I've seen some increase it to nonzero values to cope with the connection breaks. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Andres Freund and...@anarazel.de writes: On 2015-06-24 16:41:48 +0200, Andres Freund wrote: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. I think by now we essentially concluded that we should do that. What I'm not sure yet is how: Do we want to rip it out in master and just change the default in the backbranches, or do we want to rip it out in all branches and leave a faux guc in place in the back branches. I vote for the latter, but would be ok with both variants. I think the former is probably the saner answer. It is less likely to annoy people who dislike back-branch changes. And it will be significantly less work, considering that that code has changed enough that you won't be able to just cherry-pick a removal patch. I also fear there's a nonzero chance of breaking stuff if you're careless about doing the removal in one or more of the five active back branches ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-24 16:41:48 +0200, Andres Freund wrote: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. I think by now we essentially concluded that we should do that. What I'm not sure yet is how: Do we want to rip it out in master and just change the default in the backbranches, or do we want to rip it out in all branches and leave a faux guc in place in the back branches. I vote for the latter, but would be ok with both variants. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On Fri, Jun 26, 2015 at 3:09 PM, Andres Freund and...@anarazel.de wrote: On 2015-06-24 16:41:48 +0200, Andres Freund wrote: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. I think by now we essentially concluded that we should do that. What I'm not sure yet is how: Do we want to rip it out in master and just change the default in the backbranches, or do we want to rip it out in all branches and leave a faux guc in place in the back branches. I vote for the latter, but would be ok with both variants. 3. Change the default and make the guc impotent - in the back branches. Its minimally invasive and accomplishes the same user-facing goal as ripping it out. Leaving dead code around in master seems undesirable so ripping it out from there would still make sense. This does provide an easy fall-back in the back-branches if we are accused of being overly parental. David J.
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-26 15:36:53 -0400, David G. Johnston wrote: On Fri, Jun 26, 2015 at 3:09 PM, Andres Freund and...@anarazel.de wrote: On 2015-06-24 16:41:48 +0200, Andres Freund wrote: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. I think by now we essentially concluded that we should do that. What I'm not sure yet is how: Do we want to rip it out in master and just change the default in the backbranches, or do we want to rip it out in all branches and leave a faux guc in place in the back branches. I vote for the latter, but would be ok with both variants. 3. Change the default and make the guc impotent - in the back branches. Its minimally invasive and accomplishes the same user-facing goal as ripping it out. What would be the point of that? The code is pretty localized, so leaving it in, but unreachable, seems to have no benefits. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On Jun 24, 2015 7:40 PM, Andres Freund and...@anarazel.de wrote: On 2015-06-24 12:57:03 -0400, Robert Haas wrote: On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@anarazel.de writes: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. Well, that's a radical proposal, but I think we should take it seriously. On balance I think I agree that SSL renegotiation has not been worth the trouble. And we definitely aren't testing it adequately, so if we wanted to keep it then there's even *more* work that somebody ought to expend. I'd like to know what factors we are balancing against each other. Benefits: SSL renegotiation limits the exposure of on-the-wire material that's leaked if either client or server is hijacked during a existing session. With renegotiation the client/server will hopefully only have the currently negotiated symetric key, covering only session_renegotiation_limit bytes, in memory. That's nice, but from a practical point of view it's not worth all that much. If the server has been hacked nearly all the data is accessible anyway, and even if not, the hacker can just continue collecting data going forward. If the client has been hacked, it's likely that it has been relegating data for the session to somewhere that's still accessible. For the server hacked case all that generally only matters if perfect forward secrecy (PFS) has been employed, without that the session keys can be recovered anyway as the private key will be accessible in memory. All this only matters for hacks that access running processes. Deficits: SSL renegotiation has had several weaknesses (c.f. CVE-2009-3555/RFC 5746 , although I'm not 100% sure it's possible to apply to PG) on the protocol level, at least partially leading to much worse vulnerabilities than renegotiation in the pg style fixes. The openssl implementation has had several bugs several of them unfixed years after they were reported (#3712, #2481, #2146,...). By my reading of openssl's code the current state is entirely broken for duplex communication. The current draft of the next version of the TLS standard removes renegotiation entirely. I think this is a very strong argument against it. If the standards people now think it's a bad idea, we shouldn't encourage it. That's assuming they haven't replaced it with something else (even more complicated of course), and not just removed it. But i don't think they did. /Magnus
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-24 11:11:16 -0400, Tom Lane wrote: On balance I think I agree that SSL renegotiation has not been worth the trouble. And we definitely aren't testing it adequately, so if we wanted to keep it then there's even *more* work that somebody ought to expend. Right. Our code was nearly entirely broken for streaming replication for *years* without anybody noticing. And even now it doesn't reliably work. It's also pretty hard to test due to the required data volumes and the vast number of different behaviours across openssl versions. I assume we'd back-patch it, too? (Probably not remove the ssl_renegotiation_limit variable, but always act as though it were zero.) Yes, I think so. Maybe log a warning at startup if set to nonzero (startup is probably the best we can do). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Andres Freund and...@anarazel.de writes: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. Well, that's a radical proposal, but I think we should take it seriously. On balance I think I agree that SSL renegotiation has not been worth the trouble. And we definitely aren't testing it adequately, so if we wanted to keep it then there's even *more* work that somebody ought to expend. I assume we'd back-patch it, too? (Probably not remove the ssl_renegotiation_limit variable, but always act as though it were zero.) If we still have to maintain the code in the back branches then we'd continue to have to deal with its bugs for some time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On Jun 24, 2015 5:13 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@anarazel.de writes: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. Well, that's a radical proposal, but I think we should take it seriously. Yes. Just on my phone right now, but wasn't renegotiation also an attack vector in one of the recent openssl bugs? /Magnus
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-24 19:35:51 +0200, Andres Freund wrote: Our code currently uses crude hacks (c.f. comment around SSL_clear_num_renegotiations(), and the loop around SSL_do_handshake() in the back branches) to manage renegotiations. There's pending patches to substantially increase the amount of ugly hacking to cope with us misusing the SSL_read/write protocol. C.f. http://archives.postgresql.org/message-id/54DE6FAF.6050005%40vmware.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@anarazel.de writes: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. Well, that's a radical proposal, but I think we should take it seriously. On balance I think I agree that SSL renegotiation has not been worth the trouble. And we definitely aren't testing it adequately, so if we wanted to keep it then there's even *more* work that somebody ought to expend. I'd like to know what factors we are balancing against each other. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
On 2015-06-24 12:57:03 -0400, Robert Haas wrote: On Wed, Jun 24, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@anarazel.de writes: I, by now, have come to a different conclusion. I think it's time to entirely drop the renegotiation support. Well, that's a radical proposal, but I think we should take it seriously. On balance I think I agree that SSL renegotiation has not been worth the trouble. And we definitely aren't testing it adequately, so if we wanted to keep it then there's even *more* work that somebody ought to expend. I'd like to know what factors we are balancing against each other. Benefits: SSL renegotiation limits the exposure of on-the-wire material that's leaked if either client or server is hijacked during a existing session. With renegotiation the client/server will hopefully only have the currently negotiated symetric key, covering only session_renegotiation_limit bytes, in memory. That's nice, but from a practical point of view it's not worth all that much. If the server has been hacked nearly all the data is accessible anyway, and even if not, the hacker can just continue collecting data going forward. If the client has been hacked, it's likely that it has been relegating data for the session to somewhere that's still accessible. For the server hacked case all that generally only matters if perfect forward secrecy (PFS) has been employed, without that the session keys can be recovered anyway as the private key will be accessible in memory. All this only matters for hacks that access running processes. Deficits: SSL renegotiation has had several weaknesses (c.f. CVE-2009-3555/RFC 5746 , although I'm not 100% sure it's possible to apply to PG) on the protocol level, at least partially leading to much worse vulnerabilities than renegotiation in the pg style fixes. The openssl implementation has had several bugs several of them unfixed years after they were reported (#3712, #2481, #2146,...). By my reading of openssl's code the current state is entirely broken for duplex communication. The current draft of the next version of the TLS standard removes renegotiation entirely. Additionally supporting SSL renegotiation requires SSL_write/read callers to always call the SSL_write/read after either function has reported the need for additional reads/writes (note that SSL_read can require writes and the other way round). We don't comply with that rule, especially in the backbranches, because it's really hard to do that. Our code currently uses crude hacks (c.f. comment around SSL_clear_num_renegotiations(), and the loop around SSL_do_handshake() in the back branches) to manage renegotiations. There's pending patches to substantially increase the amount of ugly hacking to cope with us misusing the SSL_read/write protocol. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
