Applied following patch in rawhide:
https://pkgs.fedoraproject.org/cgit/pacemaker.git/diff/bz1179335-system-wide-crypto-policies.patch?id=fb1901f62830b444f9d6b5908d3ae342fee74f03&id2=dff8d9929d758040af423e71aeb5672ba8b20067

Thanks. I notice in the patch that the old priority string enables anonymous authentication (which is vulnerable to man in the middle attacks), is that intentional for this program? If yes, then the patch may make it incompatible with the server or clients it is supposed to communicate with. If the anonymous authentication is by design it may make sense to skip crypto-policies compliance (and document that in the spec), or use "@SYSTEM:+ANON-DH".

It may be a good idea to communicate with upstream first though, to verify that the anonymous ciphersuites are not enabled by mistake.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Nikos, excuse such a big delay on this.
I'd like to finally move this towards some reasonable resolution.

I count myself a part of the upstream crew, so it could have a wider
impact as far it's possible to detect support "@SYSTEM" et al.
directives from the configure script.

To your question:

> I notice in the patch that the old priority string enables anonymous
> authentication (which is vulnerable to man in the middle attacks), is
> that intentional for this program?

I will provide a little bit of history (also for my own reference,
feel free to jumpt to the last item):

- this is connected with "remote access to distributed configuration
  inventory (called CIB)" feature, introduced with:
  https://github.com/ClusterLabs/pacemaker/commit/4e0b19870858f5685896fdaec69ce489bc6f0755
- from the beginning, it was using anonymous authentication, because
  as apparent, authentication itself was deferred to PAM (user+password,
  with a restriction that user has to be in "admin" group if I read it
  correctly) -- it's an experimental opt-in feature so the risks
  connected with MITM are not that hot, as also highlighted with
  https://github.com/ClusterLabs/pacemaker/commit/0f19d4b98716d6db9d5260541e27da085cb8ef81
  which, depending on the compilation switches, allowed for cleartext
  channel and/or not authentication altogether
- taking the evolutionary perspective into account (pacemaker spinned
  off the heartbeat project), it looks like the feature was actually
  an interim way to loose the dependency on heartbeat itself so as to
  have mutual or at least management access to arbitrary node's CIB:
  https://github.com/ClusterLabs/pacemaker/commit/26ab885590949cfad9c1369712d63702b7f09d65
  but it's all made completely optional, depending whether user
  specified "remote_access_port" in the CIB:
  https://github.com/ClusterLabs/pacemaker/commit/c8df289112a5394c4d617d0c5f4c1820b0cbee51
- fast-forward ~ 1 year, the idea of remote management access is still
  there, some new polish:
  https://github.com/ClusterLabs/pacemaker/commit/6a6e9078ed69d3966fc70242e73255c030473f83
  https://github.com/ClusterLabs/pacemaker/commit/1374499aaa7d8e596099b2bfb64a021ef3e93616
- fast-forward another ~ 1 year, the toggle in CIB was renamed to
  "remote-tls-port"
  https://github.com/ClusterLabs/pacemaker/commit/b17fc33d0a6c5e97de431b5a80c3b7e10c7c8957
- and this is more or less the current state, ability to opt-in for
  ability to access daemon managing CIB remotely via anonymous encrypted
  (or not, depending on setting in CIB) channel with autorization
  protected by PAM (or not if not compiled with it)

So yes, it's intentional, it's for "convenient in-transit security
(without hassles with preshared key or certificates) for an opt-in
remote access to distributed configuration inventory (CIB)", and
now also with added "when the risk of MITM at the session initialization
phase is not critical" (e.g., connection between virtual machines).

> If yes, then the patch may make it incompatible with the server or
> clients it is supposed to communicate with. If the anonymous
> authentication is by design it may make sense to skip crypto-policies
> compliance (and document that in the spec), or use "@SYSTEM:+ANON-DH".

I guess the latter is better as it enforces "correct" length for
Diffie-Hellman key exchange?
https://github.com/nmav/fedora-crypto-policies/blob/f25/back-ends/profiles/DEFAULT.pl#L38

> It may be a good idea to communicate with upstream first though, to
> verify that the anonymous ciphersuites are not enabled by mistake.

See the beginning and the initial question if we can detect support for
such parametrization string in configure script.

Thanks for you feedback.

(In reply to Jan Pokorný from comment #6)
> Nikos, excuse such a big delay on this.
> I'd like to finally move this towards some reasonable resolution.
> 
> I count myself a part of the upstream crew, so it could have a wider
> impact as far it's possible to detect support "@SYSTEM" et al.
> directives from the configure script.
> 
> To your question:
> 
> > I notice in the patch that the old priority string enables anonymous
> > authentication (which is vulnerable to man in the middle attacks), is
> > that intentional for this program?
> 
> I will provide a little bit of history (also for my own reference,
> feel free to jumpt to the last item):
> 
> - this is connected with "remote access to distributed configuration
>   inventory (called CIB)" feature, introduced with:
>  
> https://github.com/ClusterLabs/pacemaker/commit/
> 4e0b19870858f5685896fdaec69ce489bc6f0755
> - from the beginning, it was using anonymous authentication, because
>   as apparent, authentication itself was deferred to PAM (user+password,
>   with a restriction that user has to be in "admin" group if I read it
>   correctly) -- it's an experimental opt-in feature so the risks
>   connected with MITM are not that hot, as also highlighted with

Note that in typical TLS channels there is always server-side authentication, to ensure that the username-password combo is not sent to untrusted parties. However, as you describe it may not make sense to have such authentication when communicating between server machines on the same host. However, in such cases you wouldn't need to use TLS either (anon overhead is quite significant). If applicable it may make sense to make TLS always authenticated when specified, and require normal connections when using for communication within the same host. Would that make sense?

> > If yes, then the patch may make it incompatible with the server or
> > clients it is supposed to communicate with. If the anonymous
> > authentication is by design it may make sense to skip crypto-policies
> > compliance (and document that in the spec), or use "@SYSTEM:+ANON-DH".
> 
> I guess the latter is better as it enforces "correct" length for
> Diffie-Hellman key exchange?
> https://github.com/nmav/fedora-crypto-policies/blob/f25/back-ends/profiles/
> DEFAULT.pl#L38

I cannot really say. If MITM is not possible in the scenarios you are handling, is encryption really required? I mean are there realistic threats protecting from using anonymous authentication?

> See the beginning and the initial question if we can detect support for
> such parametrization string in configure script.

The @SYSTEM is a fedora available string only. It is intended to be used in fedora-specific configuration files. If you'd like to do that change on upstream you'd have to switch to gnutls_set_default_priority() instead which achieves the same thing.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

(In reply to Nikos Mavrogiannopoulos from comment #7)
> (In reply to Jan Pokorný from comment #6)
> > Nikos, excuse such a big delay on this.
> > I'd like to finally move this towards some reasonable resolution.
> > 
> > I count myself a part of the upstream crew, so it could have a wider
> > impact as far it's possible to detect support "@SYSTEM" et al.
> > directives from the configure script.
> > 
> > To your question:
> > 
> > > I notice in the patch that the old priority string enables anonymous
> > > authentication (which is vulnerable to man in the middle attacks), is
> > > that intentional for this program?
> > 
> > I will provide a little bit of history (also for my own reference,
> > feel free to jumpt to the last item):
> > 
> > - this is connected with "remote access to distributed configuration
> >   inventory (called CIB)" feature, introduced with:
> >  
> > https://github.com/ClusterLabs/pacemaker/commit/
> > 4e0b19870858f5685896fdaec69ce489bc6f0755
> > - from the beginning, it was using anonymous authentication, because
> >   as apparent, authentication itself was deferred to PAM (user+password,
> >   with a restriction that user has to be in "admin" group if I read it
> >   correctly) -- it's an experimental opt-in feature so the risks
> >   connected with MITM are not that hot, as also highlighted with
> 
> Note that in typical TLS channels there is always server-side
> authentication, to ensure that the username-password combo is not sent to
> untrusted parties. However, as you describe it may not make sense to have
> such authentication when communicating between server machines on the same
> host. However, in such cases you wouldn't need to use TLS either (anon
> overhead is quite significant). If applicable it may make sense to make TLS
> always authenticated when specified, and require normal connections when
> using for communication within the same host. Would that make sense?

The upstream implementation is subject to MITM attacks, but the software is typically installed on protected administrative-only networks, and is restricted to users in a particular group. As the GnuTLS docs suggest, the main benefit in this case is protecting against passive eavesdropping (not necessarily malicious, but avoiding sensitive info showing up plaintext in e.g. a wireshark session investigating network issues).

Currently, the upstream implementation does not use certificates for clients or servers; it uses anonymous credentials for this purpose (remote connection to the configuration daemon) and PSK for a separate purpose (communication between certain daemons). A certificate-based approach might make more sense, but is not a priority for development.

> > > If yes, then the patch may make it incompatible with the server or
> > > clients it is supposed to communicate with. If the anonymous
> > > authentication is by design it may make sense to skip crypto-policies
> > > compliance (and document that in the spec), or use "@SYSTEM:+ANON-DH".
> > 
> > I guess the latter is better as it enforces "correct" length for
> > Diffie-Hellman key exchange?
> > https://github.com/nmav/fedora-crypto-policies/blob/f25/back-ends/profiles/
> > DEFAULT.pl#L38

Agreed, we should use "@SYSTEM:+ANON-DH" (and "@SYSTEM:+DHE-PSK:+PSK" instead of "NORMAL:+DHE-PSK:+PSK" for the separate usage) to maintain the intended functionality, and document the reason for the policy exception in the spec.

> I cannot really say. If MITM is not possible in the scenarios you are
> handling, is encryption really required? I mean are there realistic threats
> protecting from using anonymous authentication?
> 
> > See the beginning and the initial question if we can detect support for
> > such parametrization string in configure script.
> 
> The @SYSTEM is a fedora available string only. It is intended to be used in
> fedora-specific configuration files. If you'd like to do that change on
> upstream you'd have to switch to gnutls_set_default_priority() instead which
> achieves the same thing.

I think the idea is to extend upstream functionality to allow the builder to specify the priority string at configure time, defaulting to the current upstream value. The Fedora spec could then set the desired value without needing a patch. To handle the two separate use cases, it should probably be something like ./configure --gnutls-priorities="@SYSTEM", and the software should append ":+ANON-DH" or ":+DHE-PSK:+PSK" as appropriate.

Unless there is a conceptual obstacle discovered, this is definitely
addressed in pacemaker-2.0.0-0.1.rc3.fc29/Rawhide, based on upstream
commits:

https://github.com/ClusterLabs/pacemaker/commit/b3dfce1d3
+
https://github.com/ClusterLabs/pacemaker/commit/92db7aff3
https://github.com/ClusterLabs/pacemaker/commit/6582f46f7

The second pair of commits provides flexibility, e.g. for
convenient cross-testing of the TLS-communicating peers with
a simple rebuilding as

  rpmbuild --define 'pcmk_gnutls_priorities PRIORITY-SPEC'

e.g. to emulate "FUTURE" profile as detailed at
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings#Detailed_Description
without mangling with @SYSTEM-selected one, allowing
independent setting for pacemaker and pacemaker-remoted
at the same plain host, for instance.