Issue #1765 has been updated by IanTurner.
Luke, In my opinion, any configuration management solution needs to provide some way to limit client access to configuration information. Some clients will always have access to more private information than others, and a configuration management scheme needs to provide a way to enforce this. In particular, external-facing hosts are more prone to compromise and are frequently restricted in their access to resources elsewhere in the organization. That said, I respect the idea that puppet users might not have a fully functional DNS infrastructure in place, especially since such an infrastructure might itself be managed by puppet. However, even if some users have no need of client-specific authentication, I would at least request a puppetmaster configuration option for the checks I mentioned earlier. In particular, the most important one is to have the puppetmaster confirm that the facter hostname and certificate hostname match: It is this loophole which allows a compromised client to retrieve configuration information about any other client under management. We're naturally happy to discuss these issues in this forum, but if you'd like to chat about things on the phone, feel free to give me a call. I think Andrew Shafer has my number, if you don't have it handy. ---------------------------------------- Bug #1765: Certificate hostnames are not verified http://projects.reductivelabs.com/issues/show/1765 Author: IanTurner Status: Needs design decision Priority: High Assigned to: Category: SSL Target version: Complexity: Unknown Affected version: 0.24.6 Keywords: certificate security spoof validation authentication dns The puppetmaster only verifies the validity of the client certificate, but does not verify the associated hostname. Thus a client with a certificate signed as "publicserver" can instead claim to be "secretserver" and gain access to the latter's configuration. This certificate hostname spoofing can be a serious issue, since client configuration may include password hashes and other confidential data. The best approach to client validation is to verify that all three of the following are identical at the FQDN level: 1. The FQDN on the signed client certificate. 2. The FQDN presented by the client facter invocation. 3. The result of a reverse lookup on the connecting client IP address. Additionally, an address (A/AAAA record, not CNAME record) lookup on this FQDN should in turn yield the connecting client IP address in the query result. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
