Re: [PATCH 1/2] SSL: GUC option to prefer server cipher order
От | Marko Kreen |
---|---|
Тема | Re: [PATCH 1/2] SSL: GUC option to prefer server cipher order |
Дата | |
Msg-id | 20131129165241.GA27570@gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH 1/2] SSL: GUC option to prefer server cipher order (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
On Fri, Nov 29, 2013 at 05:51:28PM +0200, Heikki Linnakangas wrote: > On 11/29/2013 05:43 PM, Marko Kreen wrote: > >On Fri, Nov 29, 2013 at 09:25:02AM -0500, Peter Eisentraut wrote: > >>On Thu, 2013-11-14 at 11:45 +0100, Magnus Hagander wrote: > >>>I think the default behaviour should be the one we recommend (which > >>>would be to have the server one be preferred). But I do agree with the > >>>requirement to have a GUC to be able to remove it > >> > >>Is there a reason why you would want to turn it off? > > > >GUC is there so old behaviour can be restored. > > > >Why would anyone want that, I don't know. In context of PostgreSQL, > >I see no reason to prefer old behaviour. > > Imagine that the server is public, and anyone can connect. The > server offers SSL protection not to protect the data in the server, > since that's public anyway, but to protect the communication of the > client. In that situation, it should be the client's choice what > encryption to use (if any). This is analogous to using https on a > public website. > > I concur that that's pretty far-fetched. Just changing the behavior, > with no GUC, is fine by me. But client can control that behaviour - it just needs to specify suites it wants and drop the rest. So only question is that does any client have better (non-tuned?) defaults than we can set from server. Considering the whole HTTPS world has answered 'no' to that question and nowadays server-controlled behaviour is preferred, I think it's safe to change the behaviour in Postgres too. -- marko
В списке pgsql-hackers по дате отправления: