Puppet certification issue

[nan meng]

Hi all,

I have tested puppet with version 4.1 and 2.x,  found that if an agent connect master without certification, the connection still can be established.

I think it is not reasonable. Because if agent connect with an wrong certification the connection will be refused.

Does anyone know how to fix it?

the attachment is packet captured using tcpdump. It can prove what I have said.

Best Regards,

Nan Meng

[jcbollinger]

On Tuesday, July 18, 2017 at 10:36:17 AM UTC-5, nan meng wrote:

Hi all,

I have tested puppet with version 4.1 and 2.x,  found that if an agent connect master without certification, the connection still can be established.

I think it is not reasonable. Because if agent connect with an wrong certification the connection will be refused.

Merely connecting does not necessarily imply normal or successful operation.  The Puppet catalog request process requires master and agent to authenticate to each other via cryptographic certificate.  This has been a Puppet foundational principle forever, or at least since before I started using Puppet way back at version 0.24.  If indeed you can show that a Puppet agent is able to obtain a catalog from a Puppet master without presenting a certificate that the master is willing to trust, or at least presenting a certificate-signing request that the master is willing to honor, then you have identified a serious flaw.  I'm not yet prepared to believe that you have done that.

 

Does anyone know how to fix it?

It's not clear to me that anything is broken.

 

the attachment is packet captured using tcpdump. It can prove what I have said.

I'm not sure what, exactly, your capture proves.  I see a TCP connection being established from a client to a server running on Puppet's standard port, 8140, at a different IP address.  I see some binary data being exchanged, and then the connection being closed at both ends.  But my protocol analyzer does not recognize the the protocol of the conversation, and certainly it does not recognize it as SSL / TLS.  Who knows what the exchange actually means, or whether it is problematic?

If you want me to believe that you have discovered a bug -- or indeed if you want help with a solution or workaround -- then you'll need to present enough information to replicate the problem.  That includes some or all of the following:

• Specific versions of agent and master
• Operating system and version on which each is running
• All non-default configuration properties on each side
• A manifest set and any other needed server-side data (ideally a single, trivial manifest if that is indeed sufficient)
• The specific puppet agent command issued (which should include the --debug or --test flag)
• The corresponding console and/or log output from the agent, and maybe also from the master.

All software has bugs, but I anticipate that you will find Puppet to be operating as intended in this particular area.

John

[nan meng]

1. Version:

Puppet: 4.10.4

Puppet server: 2.7.2

Puppet Agent: I do not use agent to do test.

OS: Ubuntu 64-desktop 16.04

Openssl: 1.0.2g

2. There is not any none default configuration.

3. Test command: openssl s_client -connect puppet:8140    ##puppet is the hostname of master.

4. There is not log from puppet, that is why I capture packet.

5. Use wireshark, Menu->Analyze->Decode As, TCP,  choose SSL, the result is decode as SSL.

In No. 12, We can see that client send hand shake message with Certificate field, but it is empty.

And then in the No. 15, we can see that hand shake is success.

 

I think it is bug, that an faked agent can connect to server without certification.

 

It difficult to insert picture, so please see the attachment.

在 2017年7月18日星期二 UTC+8下午11:36:17，nan meng写道：

[Michael Smith]

Puppet uses application-level authentication, not server-level, so a client certificate is not required to connect to the server.

Some details about this are documented at https://docs.puppet.com/puppet/5.0/config_file_auth.html and https://docs.puppet.com/puppetserver/5.0/config_file_auth.html.

It's primarily required for the client certificate bootstrap process, whereby a client: sends a certificate signing request (CSR), an authorized user signs the certificate, and the client retrieves that signed certificate.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ec9fc782-c78b-4ddf-ab24-a914ac999462%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Monday, July 24, 2017 at 9:26:39 AM UTC-5, nan meng wrote:

1. Version:

Puppet: 4.10.4

Puppet server: 2.7.2

Puppet Agent: I do not use agent to do test.

OS: Ubuntu 64-desktop 16.04

Openssl: 1.0.2g

2. There is not any none default configuration.

3. Test command: openssl s_client -connect puppet:8140    ##puppet is the hostname of master.

4. There is not log from puppet, that is why I capture packet.

5. Use wireshark, Menu->Analyze->Decode As, TCP,  choose SSL, the result is decode as SSL.

As I said in response to your previous message, merely connecting to the Puppet server without a certificate does not in itself indicate a flaw.  I was perhaps not clear enough in that previous response that Puppet allows SSL connections without a client certificate in order to service certificate-signing requests, as Michael has now clarified as well.

It would constitute a bug if an untrusted client -- whether a Puppet agent or something else -- were able to obtain a catalog or other secure data from the master, but you have not demonstrated such an issue as far as I can determine.  Simply accepting a connection without authentication via client certificate does not demonstrate Puppet disclosing secure data to an untrusted client, nor is it an indication that a client successfully establishing such a connection could obtain such data.

I still see no reason to believe that the behavior you describe is flawed or that it requires fixing. 

John