[PATCH] add ssl_protocols configuration option

On Fri, Oct 17, 2014 at 7:58 PM, Dag-Erling Smørgrav <des@des.no> wrote:

The default is "ALL:-SSLv2" in 9.0-9.3 and "ALL:-SSL" in 9.4 and up.
This corresponds to the current hardcoded values, so the default
behavior is unchanged, but the admin now has the option to select a
different settings, e.g. if a serious vulnerability is found in TLS 1.0.

Please note that new features can only be added to the version currently in
development, aka 9.5. You should as well register your patch to the current
commit fest, I think you are still in time:
https://commitfest.postgresql.org/action/commitfest_view?id=24
--
Michael

Michael Paquier <michael.paquier@gmail.com> writes:

Please note that new features can only be added to the version
currently in development, aka 9.5.

I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will make life much easier for everyone if a POODLE-like vulnerability
is discovered in TLS.

You should as well register your patch to the current commit fest, I
think you are still in time:
https://commitfest.postgresql.org/action/commitfest_view?id=24

Thanks for reminding me.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Dag-Erling Sm�rgrav wrote:

Michael Paquier <michael.paquier@gmail.com> writes:

Please note that new features can only be added to the version
currently in development, aka 9.5.

I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will make life much easier for everyone if a POODLE-like vulnerability
is discovered in TLS.

I see this as vaguely related to
/messages/by-id/20131114202733.GB7583@eldon.alvh.no-ip.org
where we want to have SSL behavior configurable in the back branches due
to renegotiation issues: there was talk in that thread about introducing
new GUC variables in back branches to control the behavior. The current
patch really doesn't add much in the way of features (SSLv3 support and
so on already exist in back branches) --- what it does add is a way to
control whether these are used.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Dag-Erling Sm�rgrav wrote:

I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will make life much easier for everyone if a POODLE-like vulnerability
is discovered in TLS.

I see this as vaguely related to
/messages/by-id/20131114202733.GB7583@eldon.alvh.no-ip.org
where we want to have SSL behavior configurable in the back branches due
to renegotiation issues: there was talk in that thread about introducing
new GUC variables in back branches to control the behavior. The current
patch really doesn't add much in the way of features (SSLv3 support and
so on already exist in back branches) --- what it does add is a way to
control whether these are used.

This looks to me like re-fighting the last war. Such a GUC has zero value
*unless* some situation exactly like the POODLE bug comes up again, and
the odds of that are not high.

Moreover, the GUC could easily be misused to decrease rather than increase
one's security, if it's carelessly set. Remember that we only recently
fixed bugs that prevented use of the latest TLS version. If we have a
setting like this, I fully anticipate that people will set it to "only use
TLS 1.2" and then forget that they ever did that; years from now they'll
still be using 1.2 when it's deprecated.

So I think the argument that this is a useful security contribution is
pretty weak; and on the whole we don't need another marginally-useful GUC.

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

On Fri, Oct 17, 2014 at 7:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Dag-Erling Smørgrav wrote:

I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will make life much easier for everyone if a POODLE-like vulnerability
is discovered in TLS.

I see this as vaguely related to
/messages/by-id/20131114202733.GB7583@eldon.alvh.no-ip.org
where we want to have SSL behavior configurable in the back branches due
to renegotiation issues: there was talk in that thread about introducing
new GUC variables in back branches to control the behavior. The current
patch really doesn't add much in the way of features (SSLv3 support and
so on already exist in back branches) --- what it does add is a way to
control whether these are used.

This looks to me like re-fighting the last war. Such a GUC has zero value
*unless* some situation exactly like the POODLE bug comes up again, and
the odds of that are not high.

Moreover, the GUC could easily be misused to decrease rather than increase
one's security, if it's carelessly set. Remember that we only recently
fixed bugs that prevented use of the latest TLS version. If we have a
setting like this, I fully anticipate that people will set it to "only use
TLS 1.2" and then forget that they ever did that; years from now they'll
still be using 1.2 when it's deprecated.

If anything, I think the default should be "default", and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up again. It would require an
admin action, and in this case, it would make us less secure. If we
had a GUC that took the keyword "default" which would mean "whatever
the current version of postgresql thinks is the best" then we could
change the default in a security update if something showed up.

In a case like POODLE we probably wouldn't have done it anyway, as it
doesn't affect our connections (we're not http) and it would have the
potential of breaking some third party clients. However, if something
really bad showed up, we might want to do that.

So I think the argument that this is a useful security contribution is
pretty weak; and on the whole we don't need another marginally-useful GUC.

Having the guc could certainly be useful in some cases. If we do, we
should of course *also* have a corresponding configuration option in
libpq, so I'd say this patch is incomplete if we do want to do it.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Magnus Hagander <magnus@hagander.net> writes:

If anything, I think the default should be "default", and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up again. It would require an
admin action, and in this case, it would make us less secure. If we
had a GUC that took the keyword "default" which would mean "whatever
the current version of postgresql thinks is the best" then we could
change the default in a security update if something showed up.

That's pretty much isomorphic to just setting the value in the code,
no?

Having the guc could certainly be useful in some cases. If we do, we
should of course *also* have a corresponding configuration option in
libpq, so I'd say this patch is incomplete if we do want to do it.

True. But both of those scenarios posit that no *code* changes are
needed, which is infrequently the case.

And you still have the problem that if an admin does change the setting
away from "default", and forgets to revert that after his next update,
he could in the long run be less secure not more so. Client-side
settings would likely be even harder to get rid of than server-side.

And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till recently,
because nobody had looked at the issue for a decade. I see no reason
to expect that that history won't repeat itself.

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

On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

If anything, I think the default should be "default", and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up again. It would require an
admin action, and in this case, it would make us less secure. If we
had a GUC that took the keyword "default" which would mean "whatever
the current version of postgresql thinks is the best" then we could
change the default in a security update if something showed up.

That's pretty much isomorphic to just setting the value in the code,
no?

No, it would let the user (temporarily) override it.

Having the guc could certainly be useful in some cases. If we do, we
should of course *also* have a corresponding configuration option in
libpq, so I'd say this patch is incomplete if we do want to do it.

True. But both of those scenarios posit that no *code* changes are
needed, which is infrequently the case.

Definitely - it's still very borderline if it's useful.

And you still have the problem that if an admin does change the setting
away from "default", and forgets to revert that after his next update,
he could in the long run be less secure not more so. Client-side
settings would likely be even harder to get rid of than server-side.

True.

And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till recently,
because nobody had looked at the issue for a decade. I see no reason
to expect that that history won't repeat itself.

The best part would be if we could just leave it up to the SSL
library, but at least the openssl one doesn't have an API that lets us
do that, right? We *have* to pick something...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Magnus Hagander <magnus@hagander.net> writes:

On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till recently,
because nobody had looked at the issue for a decade. I see no reason
to expect that that history won't repeat itself.

The best part would be if we could just leave it up to the SSL
library, but at least the openssl one doesn't have an API that lets us
do that, right? We *have* to pick something...

As far as protocol version goes, I think our existing coding basically
says "prefer newest available version, but at least TLS 1.0". I think
that's probably a reasonable approach.

If the patch exposed a GUC that set a "minimum" version, rather than
calling out specific acceptable protocols, it might be less risky.

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

On Oct 19, 2014 9:18 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till recently,
because nobody had looked at the issue for a decade. I see no reason
to expect that that history won't repeat itself.

The best part would be if we could just leave it up to the SSL
library, but at least the openssl one doesn't have an API that lets us
do that, right? We *have* to pick something...

As far as protocol version goes, I think our existing coding basically
says "prefer newest available version, but at least TLS 1.0". I think
that's probably a reasonable approach.

Yes, it does that. Though it only does it on 9.4,but with the facts we know
now, what 9.4+ does is perfectly safe.

/Magnus

Tom Lane <tgl@sss.pgh.pa.us> writes:

This looks to me like re-fighting the last war. Such a GUC has zero value
*unless* some situation exactly like the POODLE bug comes up again, and
the odds of that are not high.

Many people would have said the exact same thing before POODLE, and
BEAST, and CRIME, and Heartbleed. You never know what sort of bugs or
weaknesses will show up or when; all you know is that there are a lot of
people working very hard to find these things and exploit them, and that
they *will* succeeded, again and again and again. You can gamble that
PostgreSQL will not be vulnerable due to specific details of its
protocol or how it uses TLS, but that's a gamble which you will
eventually lose.

Moreover, the GUC could easily be misused to decrease rather than increase
one's security, if it's carelessly set.

That's the user's responsibility.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Magnus Hagander <magnus@hagander.net> writes:

If anything, I think the default should be "default", and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up again.

Actually, I had that in an earlier version of the patch, but I thought
it was too obscure / circular. I can easily re-add it.

In a case like POODLE we probably wouldn't have done it anyway, as it
doesn't affect our connections (we're not http)

If I understand correctly, imaps has been shown to be vulnerable as
well, so I wouldn't be so sure.

Having the guc could certainly be useful in some cases. If we do, we
should of course *also* have a corresponding configuration option in
libpq, so I'd say this patch is incomplete if we do want to do it.

I can update the patch to include the client side.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.us> writes:

And in the end, if we set values like this from PG --- whether
hard-wired or via a GUC --- the SSL library people will have exactly
the same perspective with regards to *our* values. And not without
reason; we were forcing very obsolete settings up till recently,
because nobody had looked at the issue for a decade. I see no reason
to expect that that history won't repeat itself.

I'm not sure what you're saying here, but - I'm not sure how familiar
you are with the OpenSSL API, but it's insecure by default. There is
*no other choice* for an application than to explicitly select which
protocols it wants to use (or at least which protocols it wants to
avoid). And you can't change OpenSSL, because a ton of old crappy
software is going to break.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.us> writes:

As far as protocol version goes, I think our existing coding basically
says "prefer newest available version, but at least TLS 1.0". I think
that's probably a reasonable approach.

The client side forces TLS 1.0:

SSL_context = SSL_CTX_new(TLSv1_method());

In typical OpenSSL fashion, this does *not* mean 1.0 or higher. It
means 1.0 exactly.

If the patch exposed a GUC that set a "minimum" version, rather than
calling out specific acceptable protocols, it might be less risky.

Not necessarily. Someone might find a weakness in TLS 1.1 which is not
present in 1.0 because it involves a specific algorithm or mode that 1.0
does not support.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Magnus Hagander <magnus@hagander.net> writes:

Yes, it does that. Though it only does it on 9.4,but with the facts we
know now, what 9.4+ does is perfectly safe.

Agreed.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Oct 22, 2014 at 3:12 PM, Dag-Erling Smørgrav <des@des.no> wrote:

Tom Lane <tgl@sss.pgh.pa.us> writes:

This looks to me like re-fighting the last war. Such a GUC has zero

value

*unless* some situation exactly like the POODLE bug comes up again, and
the odds of that are not high.

Many people would have said the exact same thing before POODLE, and
BEAST, and CRIME, and Heartbleed. You never know what sort of bugs or
weaknesses will show up or when; all you know is that there are a lot of
people working very hard to find these things and exploit them, and that
they *will* succeeded, again and again and again. You can gamble that
PostgreSQL will not be vulnerable due to specific details of its
protocol or how it uses TLS, but that's a gamble which you will
eventually lose.

There are some companies, without naming them, that have increased the
resources dedicated to analyze existing security protocols and libraries,
so even if the chances are low, IMO the occurence that similar problems
show up are getting to increase wit the time.

Moreover, the GUC could easily be misused to decrease rather than

increase

one's security, if it's carelessly set.

That's the user's responsibility.

I actually just had a user knocking about having a way to control the
protocols used by server... So, changing my opinion on the matter, that
would be nice to have even such a parameter on back-branches, with
'default' to let the server decide which one is better.
--
Michael

On Wed, Oct 22, 2014 at 03:14:26PM +0200, Dag-Erling Smørgrav wrote:

In a case like POODLE we probably wouldn't have done it anyway, as it
doesn't affect our connections (we're not http)

If I understand correctly, imaps has been shown to be vulnerable as
well, so I wouldn't be so sure.

Reference? It's an SSL3 specific attack, so most servers are not
vulnerable because TLS will negotiate to the highest supported
protocol. So unless one of the client/server doesn't support TLS1.0
there's no issue. The only reason http is vulnerable is because
browsers do protocol downgrading, something strictly forbidden by the
spec.

Additionally, the man-in-the-middle must be able to control the padding
in the startup packet, which just isn't possible (no scripting language
in the client).

Since you can already specify the cipher list, couldn't you just add
-SSLv3 to the cipher list and be done?

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

He who writes carelessly confesses thereby at the very outset that he does
not attach much importance to his own thoughts.

-- Arthur Schopenhauer

Martijn van Oosterhout <kleptog@svana.org> writes:

Dag-Erling Smørgrav <des@des.no> writes:

If I understand correctly, imaps has been shown to be vulnerable as
well, so I wouldn't be so sure.

Reference?

Sorry, no reference. I was told that Thunderbird was vulnerable to
POODLE when talking imaps.

Since you can already specify the cipher list, couldn't you just add
-SSLv3 to the cipher list and be done?

I didn't want to change the existing behavior; all I wanted was to give
users a way to do so if they wish.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Oct 22, 2014 at 09:36:59PM +0200, Dag-Erling Smørgrav wrote:

Martijn van Oosterhout <kleptog@svana.org> writes:

Dag-Erling Smørgrav <des@des.no> writes:

If I understand correctly, imaps has been shown to be vulnerable as
well, so I wouldn't be so sure.

Reference?

Sorry, no reference. I was told that Thunderbird was vulnerable to
POODLE when talking imaps.

Ugh, found it. It does the same connection fallback stuff as firefox.

https://securityblog.redhat.com/2014/10/20/can-ssl-3-0-be-fixed-an-analysis-of-the-poodle-attack/

Since you can already specify the cipher list, couldn't you just add
-SSLv3 to the cipher list and be done?

I didn't want to change the existing behavior; all I wanted was to give
users a way to do so if they wish.

I think we should just disable SSL3.0 altogether. The only way this
could cause problems is if people are using PostgreSQL with an OpenSSL
library from last century. As for client libraries, even Windows XP
supports TLS1.0.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

He who writes carelessly confesses thereby at the very outset that he does
not attach much importance to his own thoughts.

-- Arthur Schopenhauer

Martijn van Oosterhout <kleptog@svana.org> writes:

Dag-Erling Smørgrav <des@des.no> writes:

Martijn van Oosterhout <kleptog@svana.org> writes:

Since you can already specify the cipher list, couldn't you just
add -SSLv3 to the cipher list and be done?

I didn't want to change the existing behavior; all I wanted was to
give users a way to do so if they wish.

I think we should just disable SSL3.0 altogether. The only way this
could cause problems is if people are using PostgreSQL with an OpenSSL
library from last century. As for client libraries, even Windows XP
supports TLS1.0.

As far as I'm concerned (i.e. as far as FreeBSD and the University of
Oslo are concerned), I couldn't care less about anything older than
0.9.8, which is what FreeBSD 8 and RHEL5 have, but I don't feel
comfortable making that decision for other people. On the gripping
hand, no currently supported version of libpq uses anything older than
TLS; 9.0 through 9.3 use TLS 1.0 only while 9.4 uses TLS 1.0 or higher.

DES
--
Dag-Erling Smørgrav - des@des.no

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers