Re: [PATCH] add ssl_protocols configuration option

The attached patches add an ssl_protocols configuration option which
control which versions of SSL or TLS the server will use. The syntax is
similar to Apache's SSLProtocols directive, except that the list is
colon-separated instead of whitespace-separated, although that is easy
to change if it proves unpopular.

Summary of the patch:

- In src/backend/libpq/be-secure.c:
- Add an SSLProtocols variable for the option.
- Add a function, parse_SSL_protocols(), that parses an ssl_protocols
string and returns a bitmask suitable for SSL_CTX_set_options().
- Change initialize_SSL() to call parse_SSL_protocols() and pass the
result to SSL_CTX_set_options().
- In src/backend/utils/misc/guc.c:
- Add an extern declaration for SSLProtocols.
- Add an entry in the ConfigureNamesString array for the
ssl_protocols option.
- In src/backend/utils/misc/postgresql.conf.sample:
- Add a sample ssl_protocols line.
- In doc/src/sgml/config.sgml:
- Document the ssl_protocols option.

The file names are slightly different in 9.5, since be-secure.c was
split in two and the declaration was moved into libpq.h.

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.

On Fri, Oct 17, 2014 at 7:58 PM, Dag-Erling Smørgrav <des(at)des(dot)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(dot)paquier(at)gmail(dot)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(at)des(dot)no

Dag-Erling Smørgrav wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)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
http://www.postgresql.org/message-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

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Dag-Erling Smrgrav 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
> http://www.postgresql.org/message-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

On Fri, Oct 17, 2014 at 7:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
>> http://www.postgresql.org/message-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/

Magnus Hagander <magnus(at)hagander(dot)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

On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)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/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

On Oct 19, 2014 9:18 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)des(dot)no

Magnus Hagander <magnus(at)hagander(dot)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(at)des(dot)no

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)des(dot)no

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)des(dot)no

Magnus Hagander <magnus(at)hagander(dot)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(at)des(dot)no

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

> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)svana(dot)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(at)svana(dot)org> writes:
> Dag-Erling Smørgrav <des(at)des(dot)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(at)des(dot)no

On Wed, Oct 22, 2014 at 09:36:59PM +0200, Dag-Erling Smørgrav wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > Dag-Erling Smørgrav <des(at)des(dot)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(at)svana(dot)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(at)svana(dot)org> writes:
> Dag-Erling Smørgrav <des(at)des(dot)no> writes:
> > Martijn van Oosterhout <kleptog(at)svana(dot)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(at)des(dot)no

Dag-Erling Smørgrav wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > Dag-Erling Smørgrav <des(at)des(dot)no> writes:
> > > Martijn van Oosterhout <kleptog(at)svana(dot)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.

OpenSSL just announced a week or two ago that they're abandoning support
for 0.9.8 by the end of next year[1], which means its replacements have
been around for a really long time. I think it's fine to drop 0.9.7
support --- we already dropped support for 0.9.6 with the renegotiation
rework[2] in the 9.4 timeframe.

OpenSSL 0.9.7 has already not gotten fixes for all the latest flurry of
security issues, so anyone *is* using SSL but not at least the 0.9.8
branch, they are in trouble.

[1] http://openssl.6102.n7.nabble.com/OpenSSL-0-9-8-End-Of-Life-Announcement-td54155.html
[2] http://www.postgresql.org/message-id/20130712203252.GH29206@eldon.alvh.no-ip.org

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

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> OpenSSL just announced a week or two ago that they're abandoning support
> for 0.9.8 by the end of next year[1], which means its replacements have
> been around for a really long time.

RHEL5 still has 0.9.8e with backported patches and will be supported
until 2017-03-31.

FreeBSD 8.4, 9.1, 9.2 and 9.3 all have 0.9.8y with backported patches.
8.4, 9.1 and 9.2 all expire before OpenSSL 0.9.8, but 9.3 will be
supported until 2016-12-31.

0.9.8 and 1.0.1 are not binary compatible, so upgrading is *not* an
option. We (as in FreeBSD) will have to make do - either develop our
own patches or adapt RedHat's.

> OpenSSL 0.9.7 has already not gotten fixes for all the latest flurry of
> security issues, so anyone *is* using SSL but not at least the 0.9.8
> branch, they are in trouble.

The latest 0.9.8 still only has TLS 1.0, unless they're planning to
backport 1.1 and 1.2 (which I seriously doubt).

DES
--
Dag-Erling Smørgrav - des(at)des(dot)no

=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des(at)des(dot)no> writes:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> OpenSSL 0.9.7 has already not gotten fixes for all the latest flurry of
>> security issues, so anyone *is* using SSL but not at least the 0.9.8
>> branch, they are in trouble.

> The latest 0.9.8 still only has TLS 1.0, unless they're planning to
> backport 1.1 and 1.2 (which I seriously doubt).

The upshot of this conversation still seems to be that we don't need to
do anything. Unless I'm misunderstanding something:

(1) No currently supported (or even recently supported) version of either
the backend or libpq will select protocol less than TLS 1.0 unless forced
to via (poorly chosen) configuration settings.

(2) Anyone who is feeling paranoid about shutting off SSLv3 despite (1)
can do so via the existing ssl_ciphers GUC parameter.

Seems to me that's sufficient, not only for now but for the future;
existing OpenSSL practice is that the ciphers string includes categories
corresponding to protocol versions, so you can shut off an old
protocol version there if you need to.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Anyone who is feeling paranoid about shutting off SSLv3 despite (1)
> can do so via the existing ssl_ciphers GUC parameter [...] the ciphers
> string includes categories corresponding to protocol versions, so you
> can shut off an old protocol version there if you need to.

The overlap between SSL 3.0 and TLS 1.0 is 100%:

% openssl ciphers SSLv2 | md5
fe5ff23432f119364a1126ca0776c5db
% openssl ciphers SSLv3 | md5
bde4e4a10b9c3f323c0632ad067e293a
% openssl ciphers TLSv1 | md5
bde4e4a10b9c3f323c0632ad067e293a
% openssl ciphers TLSv1.2 | md5
26c375b6bdefb018b9dd7df463658320

Thus, if you disable all SSL 3.0 ciphers, you also disable TLS 1.0.

DES
--
Dag-Erling Smørgrav - des(at)des(dot)no

On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I think it's pretty common for flaws to be discovered in particular
protocols - usually, but not always, the oldest ones. The cost of
adding a new GUC seems pretty small tom me compared to the appealing
potential for users to secure their installation by changing a
configuration setting rather than, say, having to wait for new
packages to be available to install.

> 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.

checkpoint_segments can easily be misused to decrease rather than
increase performance, and autovacuum_naptime can easily be misused to
destroy rather than improve autovacuum behavior. If we only added
GUCs that couldn't be used to make things worse, we'd have no GUCs.
The bottom line for me is that OpenSSL has (a) a seemingly
never-ending supply of serious security flaws and (b) an exposed knob
intended to help users of OpenSSL mitigate the effects of those flaws.
Exposing that knob to our users seems like a good plan; supporting
alternate SSL implementations might be an even better one, not that
the two are mutually exclusive.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Dag-Erling Smørgrav wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > OpenSSL just announced a week or two ago that they're abandoning support
> > for 0.9.8 by the end of next year[1], which means its replacements have
> > been around for a really long time.
>
> RHEL5 still has 0.9.8e with backported patches and will be supported
> until 2017-03-31.
>
> FreeBSD 8.4, 9.1, 9.2 and 9.3 all have 0.9.8y with backported patches.
> 8.4, 9.1 and 9.2 all expire before OpenSSL 0.9.8, but 9.3 will be
> supported until 2016-12-31.
>
> 0.9.8 and 1.0.1 are not binary compatible, so upgrading is *not* an
> option. We (as in FreeBSD) will have to make do - either develop our
> own patches or adapt RedHat's.

I think you misread me. I was saying to desupport 0.9.7, not 0.9.8.

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

Dag-Erling Smørgrav <des(at)des(dot)no> writes:
>
> The attached patches add an ssl_protocols configuration option which
> control which versions of SSL or TLS the server will use. The syntax is
> similar to Apache's SSLProtocols directive, except that the list is
> colon-separated instead of whitespace-separated, although that is easy
> to change if it proves unpopular.

Hello,

Here is my review of the patch against master branch:

* The patch applies and compiles cleanly, except for sgml docs:

postgres.xml:66141: element varlistentry: validity error : Element
varlistentry content does not follow the DTD, expecting (term+ ,
listitem), got (term indexterm listitem)

</para></listitem></varlistentry><varlistentry
^

The fix is to move <indexterm> under the <term> tag in the material
added to config.sgml by the patch.

* The patch works as advertised, though the only way to verify that
connections made with the protocol disabled by the GUC are indeed
rejected is to edit fe-secure-openssl.c to only allow specific TLS
versions. Adding configuration on the libpq side as suggested in the
original discussion might help here.

* The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
them forcibly after parsing the complete string (a warning is issued).
Should we also add a note about this to the documentation?

* In case the list of allowed protocols comes empty a FATAL error
message is logged: "could not set the protocol list (no valid
protocols available)". I think it's worth changing that to "could not
set SSL protocol list..." All other related error/warning logs
include "SSL".

* The added code follows conventions and looks good to me. I didn't
spot any problems in the parser. I've tried a good deal of different
values and all seem to be parsed correctly.

I would try to apply patches for older branches if there is consensus
that we really need this patch and we want to back-patch it.

Thanks.
--
Alex

Alex Shulgin <ash(at)commandprompt(dot)com> writes:
> * The patch works as advertised, though the only way to verify that
> connections made with the protocol disabled by the GUC are indeed
> rejected is to edit fe-secure-openssl.c to only allow specific TLS
> versions. Adding configuration on the libpq side as suggested in the
> original discussion might help here.

I can easily do that, but I won't have time until next week or so.

DES
--
Dag-Erling Smørgrav - des(at)des(dot)no

On Wed, Nov 19, 2014 at 4:34 PM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
>
> Dag-Erling Smørgrav <des(at)des(dot)no> writes:
>>
>> The attached patches add an ssl_protocols configuration option which
>> control which versions of SSL or TLS the server will use. The syntax is
>> similar to Apache's SSLProtocols directive, except that the list is
>> colon-separated instead of whitespace-separated, although that is easy
>> to change if it proves unpopular.
>
> Hello,
>
> Here is my review of the patch against master branch:
>
> * The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
> them forcibly after parsing the complete string (a warning is issued).
> Should we also add a note about this to the documentation?

I see no reason to accept them at all, if we're going to reject them
later anyway.

We can argue (as was done earlier in this thread) if we can drop SSL
3.0 completely -- but we can *definitely* drop SSLv2, and we should.
But anything that we're going to reject at a later stage anyway, we
should reject early.

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

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Alex Shulgin <ash(at)commandprompt(dot)com> writes:
> > * The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
> > them forcibly after parsing the complete string (a warning is issued).
> > Should we also add a note about this to the documentation?
> I see no reason to accept them at all, if we're going to reject them
> later anyway.
>
> We can argue (as was done earlier in this thread) if we can drop SSL
> 3.0 completely -- but we can *definitely* drop SSLv2, and we should.
> But anything that we're going to reject at a later stage anyway, we
> should reject early.

It's not really "early or late", but rather "within the loop or at the
end of it". From the users' perspective, the difference is that they
get (to paraphrase) "SSLv2 is not allowed" instead of "syntax error" and
that they can use constructs such as "ALL:-SSLv2".

DES
--
Dag-Erling Smørgrav - des(at)des(dot)no

On Thu, Nov 20, 2014 at 10:19 AM, Dag-Erling Smørgrav <des(at)des(dot)no> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Alex Shulgin <ash(at)commandprompt(dot)com> writes:
>> > * The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
>> > them forcibly after parsing the complete string (a warning is issued).
>> > Should we also add a note about this to the documentation?
>> I see no reason to accept them at all, if we're going to reject them
>> later anyway.
>>
>> We can argue (as was done earlier in this thread) if we can drop SSL
>> 3.0 completely -- but we can *definitely* drop SSLv2, and we should.
>> But anything that we're going to reject at a later stage anyway, we
>> should reject early.
>
> It's not really "early or late", but rather "within the loop or at the
> end of it". From the users' perspective, the difference is that they
> get (to paraphrase) "SSLv2 is not allowed" instead of "syntax error" and
> that they can use constructs such as "ALL:-SSLv2".

Ah, I see now - I hadn't looked at the code, just the review comment.
It's a "fallout" from the reverse logic in openssl. Then it makes a
lot more sense.

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

Dag-Erling Smørgrav <des(at)des(dot)no> writes:

> Alex Shulgin <ash(at)commandprompt(dot)com> writes:
>> * The patch works as advertised, though the only way to verify that
>> connections made with the protocol disabled by the GUC are indeed
>> rejected is to edit fe-secure-openssl.c to only allow specific TLS
>> versions. Adding configuration on the libpq side as suggested in the
>> original discussion might help here.
>
> I can easily do that, but I won't have time until next week or so.

I can do that too, just need a hint where to look at in libpq/psql to
add the option.

For SSL we have sslmode and sslcompression, etc. in conninfo, so adding
sslprotocols seems to be an option. As an aside note: should we also
expose a parameter to choose SSL ciphers (would be a separate patch)?

--
Alex

Alex Shulgin <ash(at)commandprompt(dot)com> writes:
> I can do that too, just need a hint where to look at in libpq/psql to
> add the option.

The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
(look for SSLv23_method() and SSL_CTX_set_options()). I haven't looked
into how to set it.

DES
--
Dag-Erling Smørgrav - des(at)des(dot)no

Dag-Erling Smørgrav <des(at)des(dot)no> writes:

> Alex Shulgin <ash(at)commandprompt(dot)com> writes:
>> I can do that too, just need a hint where to look at in libpq/psql to
>> add the option.
>
> The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
> (look for SSLv23_method() and SSL_CTX_set_options()). I haven't looked
> into how to set it.

Yes, I've figured it out. Guess we'd better share the ssl_protocol
value parser code between libpq and the backend. Any precedent?

--
Alex

Alex Shulgin <ash(at)commandprompt(dot)com> writes:
>>>
>>> I can do that too, just need a hint where to look at in libpq/psql to
>>> add the option.
>>
>> The place to *enforce* the option is src/interfaces/libpq/fe-secure.c
>> (look for SSLv23_method() and SSL_CTX_set_options()). I haven't looked
>> into how to set it.
>
> Yes, I've figured it out. Guess we'd better share the ssl_protocol
> value parser code between libpq and the backend. Any precedent?

OK, looks like I've come up with something workable: I've added
sslprotocol connection string keyword similar to pre-existing
sslcompression, etc.

Please see attached v2 of the original patch. I'm having doubts about
the name of openssl.h header though, libpq-openssl.h?

--
Alex

Alex Shulgin <ash(at)commandprompt(dot)com> writes:
> OK, looks like I've come up with something workable: I've added
> sslprotocol connection string keyword similar to pre-existing
> sslcompression, etc. Please see attached v2 of the original patch.
> I'm having doubts about the name of openssl.h header though,
> libpq-openssl.h?

Perhaps ssloptions.[ch], unless you plan to add non-option-related code
there later?

BTW, there is no Regent code in your openssl.c, so the copyright
statement is incorrect.

DES
--
Dag-Erling Smørgrav - des(at)des(dot)no

Dag-Erling Smørgrav <des(at)des(dot)no> writes:

> Alex Shulgin <ash(at)commandprompt(dot)com> writes:
>> OK, looks like I've come up with something workable: I've added
>> sslprotocol connection string keyword similar to pre-existing
>> sslcompression, etc. Please see attached v2 of the original patch.
>> I'm having doubts about the name of openssl.h header though,
>> libpq-openssl.h?
>
> Perhaps ssloptions.[ch], unless you plan to add non-option-related code
> there later?

I don't think anything else than common options-related code fits in
there, so ssloptions.c makes sense to me.

> BTW, there is no Regent code in your openssl.c, so the copyright
> statement is incorrect.

Good catch, I just blindly copied that from some other file.

--
Alex

On Thu, Nov 27, 2014 at 8:51 PM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
>
> Dag-Erling Smørgrav <des(at)des(dot)no> writes:
>
>> Alex Shulgin <ash(at)commandprompt(dot)com> writes:
>>> OK, looks like I've come up with something workable: I've added
>>> sslprotocol connection string keyword similar to pre-existing
>>> sslcompression, etc. Please see attached v2 of the original patch.
>>> I'm having doubts about the name of openssl.h header though,
>>> libpq-openssl.h?
>>
>> Perhaps ssloptions.[ch], unless you plan to add non-option-related code
>> there later?
>
> I don't think anything else than common options-related code fits in
> there, so ssloptions.c makes sense to me.
>
>> BTW, there is no Regent code in your openssl.c, so the copyright
>> statement is incorrect.
>
> Good catch, I just blindly copied that from some other file.
There have been arguments in favor and against this patch... But
marking it as returned with feedback because of a lack of activity in
the last couple of weeks. Feel free to update if you think that's not
correct, and please move this patch to commit fest 2014-12.
--
Michael

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>>
>>> Perhaps ssloptions.[ch], unless you plan to add non-option-related code
>>> there later?
>>
>> I don't think anything else than common options-related code fits in
>> there, so ssloptions.c makes sense to me.
>>
>>> BTW, there is no Regent code in your openssl.c, so the copyright
>>> statement is incorrect.
>>
>> Good catch, I just blindly copied that from some other file.
> There have been arguments in favor and against this patch... But
> marking it as returned with feedback because of a lack of activity in
> the last couple of weeks. Feel free to update if you think that's not
> correct, and please move this patch to commit fest 2014-12.

Attached is a new version that addresses the earlier feedback: renamed
the added *.[ch] files and removed incorrect copyright line.

I'm moving this to the current CF.

--
Alex

On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin <ash(at)commandprompt(dot)com> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>>>
>>>> Perhaps ssloptions.[ch], unless you plan to add non-option-related code
>>>> there later?
>>>
>>> I don't think anything else than common options-related code fits in
>>> there, so ssloptions.c makes sense to me.
>>>
>>>> BTW, there is no Regent code in your openssl.c, so the copyright
>>>> statement is incorrect.
>>>
>>> Good catch, I just blindly copied that from some other file.
>> There have been arguments in favor and against this patch... But
>> marking it as returned with feedback because of a lack of activity in
>> the last couple of weeks. Feel free to update if you think that's not
>> correct, and please move this patch to commit fest 2014-12.
>
> Attached is a new version that addresses the earlier feedback: renamed
> the added *.[ch] files and removed incorrect copyright line.
>
> I'm moving this to the current CF.
This patch is statuquo since the beginning of this CF, at the
arguments are standing the same. If there is nothing happening maybe
it would be better to mark it as returned with feedback? Thoughts?
--
Michael

On Thu, Jan 15, 2015 at 4:17 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin <ash(at)commandprompt(dot)com>
> wrote:
> > Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> >>>>
> >>>> Perhaps ssloptions.[ch], unless you plan to add non-option-related
> code
> >>>> there later?
> >>>
> >>> I don't think anything else than common options-related code fits in
> >>> there, so ssloptions.c makes sense to me.
> >>>
> >>>> BTW, there is no Regent code in your openssl.c, so the copyright
> >>>> statement is incorrect.
> >>>
> >>> Good catch, I just blindly copied that from some other file.
> >> There have been arguments in favor and against this patch... But
> >> marking it as returned with feedback because of a lack of activity in
> >> the last couple of weeks. Feel free to update if you think that's not
> >> correct, and please move this patch to commit fest 2014-12.
> >
> > Attached is a new version that addresses the earlier feedback: renamed
> > the added *.[ch] files and removed incorrect copyright line.
> >
> > I'm moving this to the current CF.
> This patch is statuquo since the beginning of this CF, at the
> arguments are standing the same. If there is nothing happening maybe
> it would be better to mark it as returned with feedback? Thoughts?
>

I am not sure where we are moving on here, and if anybody cares much about
this patch... Hence marked as rejected. Feel free to complain...
--
Michael