Bug 1402235
Summary: | python-cryptography fernet.Fernet works intermittently under mod_wsgi when mod_ssl installed; errors out in hazmat/bindings/openssl/binding.py with "InternalError: Unknown OpenSSL error" | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Ryan Sawhill <rsawhill> | ||||
Component: | python-cryptography | Assignee: | Christian Heimes <cheimes> | ||||
Status: | CLOSED ERRATA | QA Contact: | Michal Reznik <mreznik> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.3 | CC: | alex.gaynor, cheimes, jorton, luhliari, mkosek, mreznik, npmccallum, rsawhill, tscherf | ||||
Target Milestone: | rc | Keywords: | ZStream | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1485896 (view as bug list) | Environment: | |||||
Last Closed: | 2018-04-10 11:36:43 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1420851, 1485896 | ||||||
Attachments: |
|
Description
Ryan Sawhill
2016-12-07 06:10:27 UTC
This kind of bug can occur when Apache / mod_ssl does not clean up OpenSSL's error stack properly. Other developers have reported similar issues with mod_wsgi applications. https://github.com/pyca/cryptography/pull/3278 should address the bug. (In reply to Christian Heimes from comment #2) > https://github.com/pyca/cryptography/pull/3278 should address the bug. Fascinating ... That made me question why this wasn't an issue in Fedora 25 and I realized: in addition to the reproducer-steps, in RHEL7 I also installed mod_ssl. Removing that, I can no longer reproduce in RHEL 7.3.1. [root@r73 ~]# rpm -q httpd python2-cryptography mod_ssl openssl httpd-2.4.6-45.el7.x86_64 python2-cryptography-1.3.1-3.el7.x86_64 package mod_ssl is not installed openssl-1.0.1e-60.el7.x86_64 [root@r73 ~]# systemctl restart httpd [root@r73 ~]# for i in {1..10}; do curl -s --head localhost/test_fernet | head -1; done HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK And if I install mod_ssl in F25, the issue surfaces. [root@f25 ~]# rpm -q httpd python2-cryptography mod_ssl openssl httpd-2.4.23-4.fc25.x86_64 python2-cryptography-1.5.3-3.fc25.x86_64 mod_ssl-2.4.23-4.fc25.x86_64 openssl-1.0.2j-1.fc25.x86_64 [root@f25 ~]# systemctl restart httpd [root@f25 ~]# for i in {1..15}; do curl -s --head localhost/test_fernet | head -1; done HTTP/1.1 500 Internal Server Error HTTP/1.1 500 Internal Server Error HTTP/1.1 500 Internal Server Error HTTP/1.1 500 Internal Server Error HTTP/1.1 500 Internal Server Error HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 500 Internal Server Error HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK AWESOME. So it looks like the upstream PR to make python-cryptography pragmatically handle these kinds of errors hasn't even been merged yet. Any reason to keep this BZ open? I'm thinking it makes most sense to clone this to mod_ssl package. Concur? The upstream PR will be merged soon. Paul wants me and Alex to review the PR before it gets merged. The fix will be in cryptography 1.7. Yes, it makes sense to clone the issue to mod_ssl and fix the root cause of the bug in mod_ssl. Let's just move this bug to httpd. If they are handling errors (which is clearly the case) then they need to clean up the error stack after handling the errors. The test cases you are showing don't show a mod_ssl configuration, or mod_ssl being exercised directly, so it's a bit hard for me to comment. curl -s --head localhost/test_fernet ... is plan HTTP. Having faced similar OpenSSL problems in mod_ssl itself, we took to doing: ERR_clear_error() some_SSL_function() in places where either the SSL function behaviour is dependent on the error stack being empty on entry, or doesn't clear it internally, and we need to check it afterwards. Note that Perl, PHP, ... stuff can also all get linked into the httpd process and change the error stack state. The above approach is the only one we've found reliable. (In reply to Joe Orton from comment #8) > The test cases you are showing don't show a mod_ssl configuration, or > mod_ssl being exercised directly, so it's a bit hard for me to comment. > > curl -s --head localhost/test_fernet > > ... is plan HTTP. I hear you Joe, but this is reproduceable with a completely default ssl.conf and you don't need to query over https to hit it. Simply install python-cffi mod_wsgi httpd python2-cryptography mod_ssl and then follow the steps. OK, fair enough. I'm not going to make a guarantee that mod_ssl will leave the error stack empty in all cases, we've never written it like that upstream, and every other OpenSSL consumer which has been linked into httpd (i.e. all of them) has managed to deal with this issue. I can either WONTFIX this bug or you can take it back and fix the issue in python-cryptography. (In reply to Joe Orton from comment #10) > I'm not going to make a guarantee that mod_ssl will leave the error stack > empty in all cases, we've never written it like that upstream, and every > other OpenSSL consumer which has been linked into httpd (i.e. all of them) > has managed to deal with this issue. I can either WONTFIX this bug or you > can take it back and fix the issue in python-cryptography. Thanks Joe. Understood. @Nathaniel McCallum: See above and also note that upstream python-cryptography has taken note of Joe's response and one of the maintainers reluctantly merged a pull request (https://github.com/pyca/cryptography/pull/3278) to clear the error queue. I leave it to you to decide how to move forward with this BZ -- e.g., to change component back to python-cryptography or just close in favor of the RHEL7.4 rebase request (bz1398666). python-cryptography is thorough and validates that OpenSSL is in a good state, before cryptography starts to use OpenSSL. After all OpenSSL is a security critical crypto and TLS library. I agree with upstream's approach validate-then-use. https://github.com/pyca/cryptography/pull/3278 is a workaround for an issue that upstream considers a bug in mod_ssl. Libraries should remove an error from the error stack before they hand over OpenSSL to another part of the application. The PR is new and not part of 1.7.2. It should be in 1.8.0 but that's not released yet. In bz1398666 I might go for 1.8.0 to fix another issue any way. Reassigning to python-cryptography, fix needs to be done there. Verified on: python2-cryptography-1.7.2-2.el7.x86_64 httpd-2.4.6-79.el7.x86_64 openssl-1.0.2k-11.el7.x86_64 python-cffi-1.6.0-5.el7.x86_64 mod_wsgi-3.4-12.el7_0.x86_64 mod_ssl-2.4.6-79.el7.x86_64 Created attachment 1367347 [details]
verification_steps
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0720 |