| Summary: | openssl 1.0.1 randomly changed cipher names | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom Lane <tgl> |
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | hhorak, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-14 00:42:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Tom Lane
2012-02-11 17:17:09 UTC
I should point out that this change is not merely an issue of cosmetic changes in regression test output: it appears to me that it will lead to actual login failures in the field. The reason is that mysql has an account-security option that allows specification of a particular cipher that must be used by connections under that account. One of the failing regression tests demonstrates that after grant select on test.* to ssl_user2@localhost require cipher "DHE-RSA-AES256-SHA"; it is no longer possible for ssl_user2 to log in, whereas that was possible last week. While I could patch this test to specify DHE-RSA-AES256-SHA256 instead, that will not fix any such grants that are out there in production databases. I poked around in the mysql source code and confirmed that they are storing the REQUIRE CIPHER argument as a simple text string, and strcmp'ing it against the output of SSL_get_cipher(). So renaming of ciphers in that function's output *will* break this application, and I wouldn't be surprised if it causes problems for other apps too. If this change isn't undone, what I will probably do is patch in a translation layer to restore the pre-1.0.1 naming, so as to not break mysql users' security configurations. That's not going to be particularly desirable, though, because mysql will then be permanently out of step with the cipher names seen in other openssl applications. Tom, the openssl-1.0.1 supports TLS 1.2 and TLS 1.1 with new ciphersuites and hmacs. That means the algorithm used is really different and instead of SHA1 hmac SHA256 hmac is used. I suppose you could patch the tests/code? so that only TLS1.0 is used and these new ciphers and hmacs will not be chosen. But I am not sure it is really desirable. Hm, so you're saying that the default choice of cipher algorithm is different in 1.0.1 than in previous releases? That's not what I thought was happening, but it would explain the behavior. Is there any way to adjust the choice without changing openssl, ideally via an environment variable or some such? Yes, exactly. Unfortunately there is no environment variable to change the choice. You have to do it programmatically. Basically by restricting the TLS version to 1.0. OK, thanks for the info. Not sure what I'll do about this, but it doesn't seem that openssl is doing something unreasonable. |