Bug 393451
Summary: | ruby 1.8.1-7.EL4.8.1 breaks applications using SSL | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Digant C Kasundra <digant> |
Component: | puppet | Assignee: | David Lutterkort <lutter> |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | low | ||
Version: | el4 | CC: | hbrock, lutter, tagoh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-01-10 23:31:20 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
Digant C Kasundra
2007-11-21 00:05:16 UTC
I don't think that the security fix itself is causing your problem. actually we uses the same fixes for this security issue. and comparing the outcome between RHEL4 and either version of Debian doesn't make sense because they don't ship 1.8.1 at all. that's likely that there may be another bug in 1.8.1. To clarify, does your SSL certificate exactly have the same hostname with your server and is your client accessing to it right? The problem isn't restricted to RHEL4, the analogous fix causes the same issues on Fedora, too. The issue really is that usually people used a CNAME for their server (puppetmaster) and the canonical hostname on the SSL server cert. I believe Debian merged a fix that also allowed turning off post_connection_check for Net::HTTP Just tested with the self-certificated. I don't see any problems as long as I connect to the http server with the same hostname what SSL certificate exactly matches. which is actually CNAME however. I mean SSL certificate has a hostname for CNAME and accessing to that. isn't it your case? (In reply to comment #2) > The problem isn't restricted to RHEL4, the analogous fix causes the same issues > on Fedora, too. > > The issue really is that usually people used a CNAME for their server > (puppetmaster) and the canonical hostname on the SSL server cert. > > I believe Debian merged a fix that also allowed turning off > post_connection_check for Net::HTTP No, they don't. it should be backported from trunk as we use. so you can still turn off with http.verify_mode=OpenSSL::SSL::VERIFY_NONE. (In reply to comment #1) > To clarify, does your SSL certificate exactly have the same hostname with your > server and is your client accessing to it right? No, in general, people assign the CNAME of "puppet" to their puppetmaster, which usually has a hostname other than "puppet." This is the scenario that generates the problem. All our clients were accessing it without error before the upgrade of the ruby libraries. (In reply to comment #1) > I don't think that the security fix itself is causing your problem. actually we > uses the same fixes for this security issue. and comparing the outcome between > RHEL4 and either version of Debian doesn't make sense because they don't ship > 1.8.1 at all. that's likely that there may be another bug in 1.8.1. They released a patch for the same CVE-2007-5162. Here is the note from the Debian news file: The upstream author had taken two actions about CVE-2007-5162. 1) They released Ruby 1.8.6-p111 and 1.8.5-p114. But the release requires to change user's code to verify server's identity. http://www.ruby-lang.org/en/news/2007/10/04/net-https-vulnerability/ [en] http://www.ruby-lang.org/ja/news/2007/10/04/isecpartners-com-2007-006-rubyssl/ [ja] 2) The upstream author re-added some fixes for Ruby. It makes Ruby verify server's identity on default. This is available on ruby_1_8 branch, trunk of the Ruby repository and next release of Ruby 1.8.x. On Debian, we took the 2nd action of the above. (In reply to comment #7) > (In reply to comment #1) > > To clarify, does your SSL certificate exactly have the same hostname with your > > server and is your client accessing to it right? > > No, in general, people assign the CNAME of "puppet" to their puppetmaster, which > usually has a hostname other than "puppet." This is the scenario that generates > the problem. No, it doesn't. but puppet was just working fine on the problem, which means it was just relying on the wrong behavior. the subject and FQDN puppet is accessing has to be the same regardless of using CNAME nor has the different IP address. reassigning to puppet. Closing since this has been resolved upstream (details of the solution in http://reductivelabs.com/trac/puppet/ticket/896) |