Red Hat Bugzilla – Bug 393451
ruby 1.8.1-7.EL4.8.1 breaks applications using SSL
Last modified: 2013-04-30 19:40:46 EDT
Description of problem: An upgrade to ruby 1.8.1-7.EL4.8.1 has broken applications that rely on SSL. Namely puppet is completely "service down" as a result of this. A similar security fix on Debian did not result in similar outage. Version-Release number of selected component (if applicable): 1.8.1-7.EL4.8.1 How reproducible: Every time Steps to Reproduce: 1. Get a working puppet environment (puppetmaster and puppet client) where the puppetmaster has a hostname that is not puppet and a cname that is puppet. 2. Upgrade ruby libraries 3. Run puppet client and it will give error. Actual results: Error message = Certificates were not trusted: hostname was not match Expected results: No error message Additional info: While this will read like a puppet issue, it isn't. Puppet was working fine and continues to work fine post-security fix on Debian systems. There is something particular to the way the security fix was rolled out on RHEL that is breaking backwards compatibility, which we were under the impression was always guaranteed. This bug prevents us from properly applying the security fix to our servers and I have therefore considered it urgent.
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)