Issue #1765 has been updated by luke. Status changed from Unreviewed to Needs design decision
I think this is a road too far. This sets up an unnecessary dependency on DNS and the local hostname, and in fact, people specifically often want their certificates not to contain valid host names. It's true that you could spoof things if you manage to get a host's cert and private key, but if you've got that, you've already entirely compromised that host since doing so requires root on that box. I'm skeptical that this is really even a bug, and I dread the drastic usability issues "fixing" it would entail. Already, ad-hoc Puppet communication is made a huge pain through the need to specify --certname and --no-http_enable_post_connection_check. With this, it would effectively never be possible to do network communication between Puppet nodes unless you could guarantee your network was already entirely set up correctly, which seems to defeat the point of having a configuration management system. What do others think? ---------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
