Thread

1. [PATCH] add ssl_protocols configuration option

   Dag-Erling Smørgrav <des@des.no> — 2014-10-17T10:58:10Z

   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.
   
   

2. Re: [PATCH] add ssl_protocols configuration option

   Michael Paquier <michael.paquier@gmail.com> — 2014-10-17T11:39:52Z

   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
   

3. Re: [PATCH] add ssl_protocols configuration option

   Dag-Erling Smørgrav <des@des.no> — 2014-10-17T12:36:08Z

   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
   
   
   

4. Re: [PATCH] add ssl_protocols configuration option

   Alvaro Herrera <alvherre@2ndquadrant.com> — 2014-10-17T16:40:21Z

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

5. Re: [PATCH] add ssl_protocols configuration option

   Tom Lane <tgl@sss.pgh.pa.us> — 2014-10-17T17:08:31Z

   Alvaro Herrera <alvherre@2ndquadrant.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
   
   
   

6. Re: [PATCH] add ssl_protocols configuration option

   Magnus Hagander <magnus@hagander.net> — 2014-10-19T09:14:29Z

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

7. Re: [PATCH] add ssl_protocols configuration option

   Tom Lane <tgl@sss.pgh.pa.us> — 2014-10-19T16:17:45Z

   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
   
   
   

8. Re: [PATCH] add ssl_protocols configuration option

   Magnus Hagander <magnus@hagander.net> — 2014-10-19T17:10:10Z

   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/
   
   
   

9. Re: [PATCH] add ssl_protocols configuration option

   Tom Lane <tgl@sss.pgh.pa.us> — 2014-10-19T19:18:41Z

   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
   
   
   

10. Re: [PATCH] add ssl_protocols configuration option

    Magnus Hagander <magnus@hagander.net> — 2014-10-19T20:04:35Z

    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
    

11. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-22T13:12:19Z

    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
    
    
    

12. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-22T13:14:26Z

    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
    
    
    

13. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-22T13:16:56Z

    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
    
    
    

14. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-22T13:21:52Z

    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
    
    
    

15. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-22T13:22:17Z

    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
    
    
    

16. Re: [PATCH] add ssl_protocols configuration option

    Michael Paquier <michael.paquier@gmail.com> — 2014-10-22T13:34:58Z

    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
    

17. Re: [PATCH] add ssl_protocols configuration option

    Martijn van Oosterhout <kleptog@svana.org> — 2014-10-22T18:54:44Z

    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
    

18. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-22T19:36:59Z

    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
    
    
    

19. Re: [PATCH] add ssl_protocols configuration option

    Martijn van Oosterhout <kleptog@svana.org> — 2014-10-23T06:30:37Z

    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
    

20. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-23T07:30:24Z

    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
    
    
    

21. Re: [PATCH] add ssl_protocols configuration option

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2014-10-23T09:58:50Z

    Dag-Erling Smørgrav wrote:
    > 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.
    
    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
    
    
    

22. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-23T16:40:50Z

    Alvaro Herrera <alvherre@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 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@des.no
    
    
    

23. Re: [PATCH] add ssl_protocols configuration option

    Tom Lane <tgl@sss.pgh.pa.us> — 2014-10-23T18:11:09Z

    =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> writes:
    > Alvaro Herrera <alvherre@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 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
    
    
    

24. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-10-23T18:56:49Z

    Tom Lane <tgl@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 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@des.no
    
    
    

25. Re: [PATCH] add ssl_protocols configuration option

    Robert Haas <robertmhaas@gmail.com> — 2014-10-23T23:51:26Z

    On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane <tgl@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 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
    
    
    

26. Re: [PATCH] add ssl_protocols configuration option

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2014-10-23T23:55:46Z

    Dag-Erling Smørgrav wrote:
    > Alvaro Herrera <alvherre@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 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
    
    
    

27. Re: [PATCH] add ssl_protocols configuration option

    Alex Shulgin <ash@commandprompt.com> — 2014-11-19T15:34:39Z

    Dag-Erling Smørgrav <des@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 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
    
    
    

28. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-11-20T08:41:52Z

    Alex Shulgin <ash@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 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@des.no
    
    
    

29. Re: [PATCH] add ssl_protocols configuration option

    Magnus Hagander <magnus@hagander.net> — 2014-11-20T08:49:24Z

    On Wed, Nov 19, 2014 at 4:34 PM, Alex Shulgin <ash@commandprompt.com> wrote:
    >
    > Dag-Erling Smørgrav <des@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 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/
    
    
    

30. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-11-20T09:19:19Z

    Magnus Hagander <magnus@hagander.net> writes:
    > Alex Shulgin <ash@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?
    > 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@des.no
    
    
    

31. Re: [PATCH] add ssl_protocols configuration option

    Magnus Hagander <magnus@hagander.net> — 2014-11-20T09:26:37Z

    On Thu, Nov 20, 2014 at 10:19 AM, Dag-Erling Smørgrav <des@des.no> wrote:
    > Magnus Hagander <magnus@hagander.net> writes:
    >> Alex Shulgin <ash@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?
    >> 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/
    
    
    

32. Re: [PATCH] add ssl_protocols configuration option

    Alex Shulgin <ash@commandprompt.com> — 2014-11-20T11:57:12Z

    Dag-Erling Smørgrav <des@des.no> writes:
    
    > Alex Shulgin <ash@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 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
    
    
    

33. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-11-21T08:15:36Z

    Alex Shulgin <ash@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.
    
    DES
    -- 
    Dag-Erling Smørgrav - des@des.no
    
    
    

34. Re: [PATCH] add ssl_protocols configuration option

    Alex Shulgin <ash@commandprompt.com> — 2014-11-21T09:13:10Z

    Dag-Erling Smørgrav <des@des.no> writes:
    
    > Alex Shulgin <ash@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.
    
    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
    
    
    

35. Re: [PATCH] add ssl_protocols configuration option

    Alex Shulgin <ash@commandprompt.com> — 2014-11-26T18:52:46Z

    Alex Shulgin <ash@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.
    >
    > 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
    
    

36. Re: [PATCH] add ssl_protocols configuration option

    Dag-Erling Smørgrav <des@des.no> — 2014-11-27T10:47:24Z

    Alex Shulgin <ash@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 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@des.no
    
    
    

37. Re: [PATCH] add ssl_protocols configuration option

    Alex Shulgin <ash@commandprompt.com> — 2014-11-27T11:51:46Z

    Dag-Erling Smørgrav <des@des.no> writes:
    
    > Alex Shulgin <ash@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 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
    
    
    

38. Re: [PATCH] add ssl_protocols configuration option

    Michael Paquier <michael.paquier@gmail.com> — 2014-12-15T03:02:07Z

    On Thu, Nov 27, 2014 at 8:51 PM, Alex Shulgin <ash@commandprompt.com> wrote:
    >
    > Dag-Erling Smørgrav <des@des.no> writes:
    >
    >> Alex Shulgin <ash@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 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
    
    
    

39. Re: [PATCH] add ssl_protocols configuration option

    Alex Shulgin <ash@commandprompt.com> — 2014-12-15T14:15:56Z

    Michael Paquier <michael.paquier@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 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
    
    

40. Re: [PATCH] add ssl_protocols configuration option

    Michael Paquier <michael.paquier@gmail.com> — 2015-01-15T07:17:02Z

    On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin <ash@commandprompt.com> wrote:
    > Michael Paquier <michael.paquier@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 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
    
    
    

41. Re: [PATCH] add ssl_protocols configuration option

    Michael Paquier <michael.paquier@gmail.com> — 2015-02-13T08:13:11Z

    On Thu, Jan 15, 2015 at 4:17 PM, Michael Paquier <michael.paquier@gmail.com>
    wrote:
    
    > On Mon, Dec 15, 2014 at 11:15 PM, Alex Shulgin <ash@commandprompt.com>
    > wrote:
    > > Michael Paquier <michael.paquier@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 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