Bug 537962
| Summary: | openssl-1.0.0-0.12.beta4 clients do not interoperate with deployed servers | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> |
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | andreas.bierfert, davej, jeff, jima, joshuadfranklin, mspevack, mvanross, rdieter, thoger, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.0.0-0.13.beta4.fc12 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-11-20 05:22:41 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Rex Dieter
2009-11-17 00:00:01 UTC
rebuilding against the newer openssl-devel doesn't help either. Bouncing to openssl for comment/feedback. In particular, I was using a cert signed by an in-house CA, so was using alpine's /novalidate-cert option:
inbox-path={server.foo.bar/novalidate-cert}inbox
added CA to /etc/pki/tls/certs/ca-bundle.crt and dropped /no-validate, no change. Reverted to openssl-1.0.0-0.10.beta3.fc12.x86_64 and it works again. Same problem with psi-0.13-1.fc12.x86_64 This is most probably caused by a fix for CVE-2009-3555. The failing clients most probably do not use SSL_OP_ALL flags to allow compatibility with buggy SSL/TLS servers. One of the flags included in the SSL_OP_ALL flags disables the extension which allows safe renegotiation. The possible fixes are: - make the clients use SSL_OP_ALL or SSL_OP_ALLOW_UNSAFE_RENEGOTIATION - change openssl so it allows servers not supporting the safe renegotiation extension even when the flag is not passed by the application I'm inclined to the second possibility for now as the current default breaks too many things. Tomas Hoger, what do you think about it? 1.0.0 beta4 does enforce reneg extension on the client side expecting it to be in each TLS1 server hello and failing if it does not. As pointed out in the proposed reneg RFC, this has significant interoperability issues (section 4.1). So while this bug mentions alpine and psi, similar problem is likely to exist for any client connecting to the server not supporting reneg extension (which currently means almost all servers). IMO, current 'fail if no reneg extension in server hello' is not likely to be a viable default for clients for quite some time. Before the extension is supported by the majority of servers, it may drive people to using SSL3 if that is configurable in the app. *** Bug 538373 has been marked as a duplicate of this bug. *** openssl-1.0.0-0.13.beta4.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openssl-1.0.0-0.13.beta4.fc12 *** Bug 538456 has been marked as a duplicate of this bug. *** tested openssl-1.0.0-0.13.beta4.fc12 , works like a charm again with alpine. openssl-1.0.0-0.13.beta4.fc12 works fine with psi as well. OpenVPN and exim are working again for me with openssl-1.0.0-0.13.beta4.fc12. openssl-1.0.0-0.13.beta4.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. |