Bug 1272243

Summary: M2Crypto OpenSSL strings vs. https://fedoraproject.org/wiki/Packaging:CryptoPolicies
Product: [Fedora] Fedora Reporter: Miloslav Trmač <mitr>
Component: m2cryptoAssignee: Miloslav Trmač <mitr>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: gholms, mcepl, mcepl, mitr, nmavrogi, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: m2crypto-0.25.0-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-20 09:53:59 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1179209    

Description Miloslav Trmač 2015-10-15 16:50:32 EDT
M2Crypto-0.22.5/M2Crypto/SSL/Context.py:
>        if weak_crypto is None:
>            if protocol == 'sslv23':
>                self.set_options(m2.SSL_OP_ALL | m2.SSL_OP_NO_SSLv2)
>            self.set_cipher_list('ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH')

1, Is this a violation of https://fedoraproject.org/wiki/Packaging:CryptoPolicies ? It can be plausibly read to only deal with libraries.

2. If 1., what would change by using PROFILE=SYSTEM?

3. If 1., should this be a downstream-only change can/should this also happen upstream?
Comment 1 Matěj Cepl 2015-10-16 01:05:21 EDT
Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG, etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.

Also, concerning libraries, I think the argument can go exactly in the opposite direction; not only libraries should not be exempted, but even more they should be even more strict, because many Python programs run

ctx = SSL.Context()

expecting getting something secure.

Actually, I have strong feelings about weak_crypto itself. Do we have some strong reasons to have this at all? In case somebody is suicidal she can always use SSL.set* methods later on her new context. I am not sure why we should help it. I can see https://gitlab.com/m2crypto/m2crypto/commit/94ba38c0a6 but it doesn’t contain any persuasive reason for the existence of the parameter.

2. So, yes, I believe we should put "PROFILE=SYSTEM" to the default self.set_cipher_list().

3. Not sure what’s the situation with this upstream. Do these profiles exist upstream at all? Do all operation systems support it? What happens on Windows, Mac OS X, other Unices?
Comment 2 Nikos Mavrogiannopoulos 2015-10-16 03:24:43 EDT
(In reply to Matěj Cepl from comment #1)
> Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG,
> etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.
[...]
> 3. Not sure what’s the situation with this upstream. Do these profiles exist
> upstream at all? Do all operation systems support it? What happens on
> Windows, Mac OS X, other Unices?

The crypto policies is a Fedora feature and there is no meaning pushing that string upstream. You should notify upstream of insecure default settings though.
This particular string seems to allow anonymous ECDH which is susceptible to man-in-the-middle attacks.
Comment 3 Miloslav Trmač 2015-10-16 16:11:52 EDT
(In reply to Matěj Cepl from comment #1)
> Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG,
> etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.
> 
> Also, concerning libraries, I think the argument can go exactly in the
> opposite direction; not only libraries should not be exempted, but even more
> they should be even more strict, because many Python programs run
> 
> ctx = SSL.Context()
> 
> expecting getting something secure.

I don’t know; I could reasonably see a case for “we will not be changing library APIs, but instead patch every end-user application”. Nikos?

> Actually, I have strong feelings about weak_crypto itself. Do we have some
> strong reasons to have this at all? In case somebody is suicidal she can
> always use SSL.set* methods later on her new context. I am not sure why we
> should help it. I can see
> https://gitlab.com/m2crypto/m2crypto/commit/94ba38c0a6 but it doesn’t
> contain any persuasive reason for the existence of the parameter.

There might not be a good reason for adding something like that (though M2Crypto never seemed too sure whether it is just an OpenSSL binding or a layer which makes OpenSSL easier to use — see M2Crypto.SSL.Checker); that’s different from a reason for removing it and breaking the API now that it exists..
Comment 5 Nikos Mavrogiannopoulos 2015-10-19 03:18:00 EDT
(In reply to Miloslav Trmač from comment #3)
> (In reply to Matěj Cepl from comment #1)
> > Ad 1. I think the answer is "YES". For once m2crypto is IMHO (via SWIG,
> > etc.) de facto C application, which certainly sets SSL_CTX_set_cipher_list.
> > 
> > Also, concerning libraries, I think the argument can go exactly in the
> > opposite direction; not only libraries should not be exempted, but even more
> > they should be even more strict, because many Python programs run
> > 
> > ctx = SSL.Context()
> > 
> > expecting getting something secure.
> 
> I don’t know; I could reasonably see a case for “we will not be changing
> library APIs, but instead patch every end-user application”. Nikos?

There is no requirement to change APIs to enforce crypto policies. There is nothing preventing the enhancement of APIs to better accommodate system defaults, or some default string applicable to many applications.
Comment 6 Jan Kurik 2016-02-24 08:50:58 EST
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
Comment 7 Fedora End Of Life 2017-07-25 15:22:36 EDT
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.
Comment 8 Matěj Cepl 2017-07-27 18:11:37 EDT
(In reply to Nikos Mavrogiannopoulos from comment #5)
> There is no requirement to change APIs to enforce crypto policies. There is
> nothing preventing the enhancement of APIs to better accommodate system
> defaults, or some default string applicable to many applications.

Nikos, could you elaborate here, please, what you mean?
Comment 9 Nikos Mavrogiannopoulos 2017-07-28 02:02:37 EDT
(In reply to Matěj Cepl from comment #8)
> (In reply to Nikos Mavrogiannopoulos from comment #5)
> > There is no requirement to change APIs to enforce crypto policies. There is
> > nothing preventing the enhancement of APIs to better accommodate system
> > defaults, or some default string applicable to many applications.
> 
> Nikos, could you elaborate here, please, what you mean?

It is a generic statement, not a particular suggestion as I am unaware of the m2crypto apis. If you know the package's APIs you are in better position to figure out what to update than me.
Comment 10 Jan Kurik 2017-08-15 03:53:58 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
Comment 11 Miloslav Trmač 2017-09-21 18:36:59 EDT
Sometime in the meantime, the self.set_cipher_list call was removed; there is only 

>         if weak_crypto is None and protocol in ('sslv23', 'tls'):
>            self.set_options(m2.SSL_OP_ALL | m2.SSL_OP_NO_SSLv2 |
>                             m2.SSL_OP_NO_SSLv3)
(with the condition usually true).

So perhaps we are now fine?
Comment 12 Tomas Mraz 2017-09-22 02:39:26 EDT
Yes, that should be OK.
Comment 13 Matěj Cepl 2017-09-22 06:45:01 EDT
This has been changed in the commit c295b5bc from Wed Jul 27 15:32:00 2016 +0200                which was first released in 0.26.0.
Comment 14 Matěj Cepl 2018-02-19 08:13:49 EST
Could we get 0.28.2 in F27 as well? I would love to have some users (I have my doubts about number of people using Rawhide), plus this could be also fixed.
Comment 15 Miloslav Trmač 2018-02-20 09:51:07 EST
(In reply to Matěj Cepl from comment #13)
> This has been changed in the commit c295b5bc from Wed Jul 27 15:32:00 2016
> +0200                which was first released in 0.26.0.

That changes the set_options call, but the set_cipher_list call has actually been removed in 0.25.0 already AFAICT; and that is available in F25 and all later releases.  Hence, closing as CURRENTRELEASE.  Thanks!
Comment 16 Miloslav Trmač 2018-02-20 09:52:55 EST
(In reply to Matěj Cepl from comment #14)
> Could we get 0.28.2 in F27 as well? I would love to have some users (I have
> my doubts about number of people using Rawhide), plus this could be also
> fixed.

There are various ABI changes, e.g. dropping the PGP subpackage, which seem unsuitable for a stable release, at least in principle (I don’t have a strong opinion on whether someone will notice in practice, but that’s a difficult line to walk).  At least this particular issue doesn’t need the rebase AFAICS.