On Thu, Jan 15, 2015 at 4:17 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin a...@commandprompt.com
wrote:
Michael Paquier michael.paqu...@gmail.com writes:
Perhaps ssloptions.[ch], unless you plan to add non-option-related
code
there
On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin a...@commandprompt.com wrote:
Michael Paquier michael.paqu...@gmail.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
Michael Paquier michael.paqu...@gmail.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
On Thu, Nov 27, 2014 at 8:51 PM, Alex Shulgin a...@commandprompt.com wrote:
Dag-Erling Smørgrav d...@des.no writes:
Alex Shulgin a...@commandprompt.com writes:
OK, looks like I've come up with something workable: I've added
sslprotocol connection string keyword similar to pre-existing
Alex Shulgin a...@commandprompt.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
Dag-Erling Smørgrav d...@des.no writes:
Alex Shulgin a...@commandprompt.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
Alex Shulgin a...@commandprompt.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.
Alex Shulgin a...@commandprompt.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.
Dag-Erling Smørgrav d...@des.no writes:
Alex Shulgin a...@commandprompt.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
Alex Shulgin a...@commandprompt.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
On Wed, Nov 19, 2014 at 4:34 PM, Alex Shulgin a...@commandprompt.com wrote:
Dag-Erling Smørgrav d...@des.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
Magnus Hagander mag...@hagander.net writes:
Alex Shulgin a...@commandprompt.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?
On Thu, Nov 20, 2014 at 10:19 AM, Dag-Erling Smørgrav d...@des.no wrote:
Magnus Hagander mag...@hagander.net writes:
Alex Shulgin a...@commandprompt.com writes:
* The code allows specifying SSLv2 and SSLv3 in the GUC, but removes
them forcibly after parsing the complete string (a warning
Dag-Erling Smørgrav d...@des.no writes:
Alex Shulgin a...@commandprompt.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
Dag-Erling Smørgrav d...@des.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
On Wed, Oct 22, 2014 at 09:36:59PM +0200, Dag-Erling Smørgrav wrote:
Martijn van Oosterhout klep...@svana.org writes:
Dag-Erling Smørgrav d...@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
Dag-Erling Smørgrav wrote:
Martijn van Oosterhout klep...@svana.org writes:
Dag-Erling Smørgrav d...@des.no writes:
Martijn van Oosterhout klep...@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
Alvaro Herrera alvhe...@2ndquadrant.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
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no writes:
Alvaro Herrera alvhe...@2ndquadrant.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
Tom Lane t...@sss.pgh.pa.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
On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane t...@sss.pgh.pa.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
Dag-Erling Smørgrav wrote:
Alvaro Herrera alvhe...@2ndquadrant.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
Tom Lane t...@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
Magnus Hagander mag...@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
Tom Lane t...@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
Tom Lane t...@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 =
Magnus Hagander mag...@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 - d...@des.no
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Wed, Oct 22, 2014 at 3:12 PM, Dag-Erling Smørgrav d...@des.no wrote:
Tom Lane t...@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.
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.
Martijn van Oosterhout klep...@svana.org writes:
Dag-Erling Smørgrav d...@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
On Fri, Oct 17, 2014 at 7:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@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
Magnus Hagander mag...@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
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@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
Magnus Hagander mag...@hagander.net writes:
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane t...@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.
On Oct 19, 2014 9:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane t...@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
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
On Fri, Oct 17, 2014 at 7:58 PM, Dag-Erling Smørgrav d...@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,
Michael Paquier michael.paqu...@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
Dag-Erling Smørgrav wrote:
Michael Paquier michael.paqu...@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
Alvaro Herrera alvhe...@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
40 matches
Mail list logo
