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: puppetAssignee: David Lutterkort <lutter>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: el4CC: 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
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.

Comment 1 Akira TAGOH 2007-11-21 00:37:27 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?


Comment 2 David Lutterkort 2007-11-21 01:37:05 UTC
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

Comment 4 Akira TAGOH 2007-11-21 01:48:38 UTC
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?

Comment 5 Akira TAGOH 2007-11-21 01:50:12 UTC
(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.

Comment 7 Digant C Kasundra 2007-11-21 09:40:18 UTC
(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.

Comment 8 Digant C Kasundra 2007-11-21 09:44:08 UTC
(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.  


Comment 9 Akira TAGOH 2007-11-22 00:17:42 UTC
(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.

Comment 10 David Lutterkort 2008-01-10 23:31:20 UTC
Closing since this has been resolved upstream (details of the solution in
http://reductivelabs.com/trac/puppet/ticket/896)