Please convert this application to use the system's crypto policy for SSL and TLS: https://fedoraproject.org/wiki/Packaging:CryptoPolicies If this program is compiled against gnutls, change the default priority string to be "@SYSTEM" or to use gnutls_set_default_priority(). If this program is compiled against openssl, and there is no default cipher list specified, you don't need to modify it. Otherwise replace the default cipher list with "PROFILE=SYSTEM". In both cases please verify that the application uses the system's crypto policies. If the package is already using the system-wide crypto policies, or it does not use SSL or TLS, no action is required, the bug can simply be closed.
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.