On Thu, Jan 15, 2015 at 4:17 PM, Michael Paquier
wrote:
> On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin
> wrote:
> > Michael Paquier writes:
>
> Perhaps ssloptions.[ch], unless you plan to add non-option-related
> code
> there later?
> >>>
> >>> I don't think anything else than
On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin wrote:
> Michael Paquier 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 t
Michael Paquier 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
On Thu, Nov 27, 2014 at 8:51 PM, Alex Shulgin wrote:
>
> Dag-Erling Smørgrav writes:
>
>> Alex Shulgin 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
Dag-Erling Smørgrav writes:
> Alex Shulgin 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 op
Alex Shulgin 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-openss
Alex Shulgin 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.
>
> Y
Dag-Erling Smørgrav writes:
> Alex Shulgin 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
> in
Alex Shulgin 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ør
Dag-Erling Smørgrav writes:
> Alex Shulgin 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 configu
On Thu, Nov 20, 2014 at 10:19 AM, Dag-Erling Smørgrav wrote:
> Magnus Hagander writes:
>> Alex Shulgin 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
Magnus Hagander writes:
> Alex Shulgin 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
On Wed, Nov 19, 2014 at 4:34 PM, Alex Shulgin wrote:
>
> Dag-Erling Smørgrav 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 th
Alex Shulgin 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
Dag-Erling Smørgrav 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,
Dag-Erling Smørgrav wrote:
> Alvaro Herrera 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 a
On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane 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 particu
Tom Lane 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
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Alvaro Herrera 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, unle
Alvaro Herrera 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.
Dag-Erling Smørgrav wrote:
> Martijn van Oosterhout writes:
> > Dag-Erling Smørgrav writes:
> > > Martijn van Oosterhout 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
Martijn van Oosterhout writes:
> Dag-Erling Smørgrav writes:
> > Martijn van Oosterhout 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
On Wed, Oct 22, 2014 at 09:36:59PM +0200, Dag-Erling Smørgrav wrote:
> Martijn van Oosterhout writes:
> > Dag-Erling Smørgrav 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 tol
Martijn van Oosterhout writes:
> Dag-Erling Smørgrav 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 al
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 sur
On Wed, Oct 22, 2014 at 3:12 PM, Dag-Erling Smørgrav wrote:
> Tom Lane 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 hav
Magnus Hagander 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 changes to your subscr
Tom Lane 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 typic
Tom Lane 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,
> becaus
Magnus Hagander 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.
Actua
Tom Lane 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 Heartb
On Oct 19, 2014 9:18 PM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane 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
Magnus Hagander writes:
> On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane 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
On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane wrote:
> Magnus Hagander 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
>> r
Magnus Hagander 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 wou
On Fri, Oct 17, 2014 at 7:08 PM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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.
Dag-Erling Smørgrav wrote:
> Michael Paquier 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
Michael Paquier 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 fo
On Fri, Oct 17, 2014 at 7:58 PM, Dag-Erling Smørgrav 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
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 pr
41 matches
Mail list logo
