Puppet users - Aug 2011 - Secure Certification Authority Transfer

Hello,

We are  attempting to set up a completely secure puppet based system.
Puppet''s encrypted communications between the master and the client is
ideal, but its client joining and certificate transfer mechanism is
not. The client certificate request and signed certificate response is
vulnerable to man-in-the-middle attacks since the CA is not verified.

 As such we are manually transferring the client certificates and CA
to the client from the master to avoid this problem. Our question is,
is there a way to force clients to verify the connection against the
ca certificate, and if that is not possible for whatever reason then
fail. The default behavior is to verify the certificate and fail,
except when the CA certificate is missing on the client at which point
the client simply (insecurely) downloads it from the master,
compromising the entire security chain.

We would like a system which could not be compromised by the removal
of a file from a client coupled with a man-in-the-middle attack. Does
anyone know of any magic "force secure connections" options or
similar?

Thanks

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Aug 24, 2011 at 7:32 AM, It Dept <it@ukcrd.com>
wrote:
> Hello,
>
> We are  attempting to set up a completely secure puppet based system.
> Puppet''s encrypted communications between the master and the
client is
> ideal, but its client joining and certificate transfer mechanism is
> not. The client certificate request and signed certificate response is
> vulnerable to man-in-the-middle attacks since the CA is not verified.
The CA pub keys should be deployed to the agent as part of the
provisioning process. This is no different than how your browser trust
a well known certificate signing authority, it has to be deployed to
the client in advance. Ideally, roll it into a package and generate it
with a sufficiently long TTL.
> We would like a system which could not be compromised by the removal
> of a file from a client coupled with a man-in-the-middle attack. Does
> anyone know of any magic "force secure connections" options or
> similar?
Man in the middle in itself doesn''t pose an issue, however if the
attacker have access to the agent system to replace the entire ssl
directory, I think you have bigger problem on your hand, and it''s not
something certificates were designed to protect you against. This is
no different then asking the question, if someone replaced my web
browser certificate trust and hijacks my DNS, how do I know he''s not
acting as man in a middle as my bank''s website?

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Nan,

Thanks for the reply. I think I should re-frame the question as I
don''t think I was at all clear.

What we are looking for is a way to prevent the puppet agent from ever
sending a request to the master if it cannot verify the certificate
chain. We will handle the secure transfer of certificates/CA cert from
master to client manually, but we don''t want clients accidentally
downloading the ca themselves insecurely.

Thanks

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Disclaimer - I know nothing of actually doing what this article is
referring to and it''s impact on puppet, and I''m a relative
puppet
newb.  I just happened to understand your question :)

This is likely of interest to you:
http://www.rubyinside.com/how-to-cure-nethttps-risky-default-https-behavior-4010.html

Justin

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

As a ''work-around'' (and no, I don''t really like this
either) you could use file attributes (chattr +i [filename]) or mandatory access
controls to prevent the server certificate from being modified on your clients
after it''s been received securely.

Not a Puppet/Webrick/Apache fix but it is a secondary way at least to provide
added assurance that the certificate received won''t be accidentally (or
perhaps purposely) updated/replaced/removed without someone''s knowledge
or effort prior.

-Mark

On Aug 25, 2011, at 7:42 AM, It Dept wrote:
> Hi Nan,
> 
> Thanks for the reply. I think I should re-frame the question as I
> don''t think I was at all clear.
> 
> What we are looking for is a way to prevent the puppet agent from ever
> sending a request to the master if it cannot verify the certificate
> chain. We will handle the secure transfer of certificates/CA cert from
> master to client manually, but we don''t want clients accidentally
> downloading the ca themselves insecurely.
> 
> Thanks
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
> 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Aug 25, 2011 at 8:42 PM, It Dept <it@ukcrd.com>
wrote:
> Hi Nan,
>
> Thanks for the reply. I think I should re-frame the question as I
> don''t think I was at all clear.
>
> What we are looking for is a way to prevent the puppet agent from ever
> sending a request to the master if it cannot verify the certificate
> chain. We will handle the secure transfer of certificates/CA cert from
> master to client manually, but we don''t want clients accidentally
> downloading the ca themselves insecurely.
>
Not sure if this is what you need but let me share anyway. When I
configured Nginx to serve as puppet master I set the ssl_verify_client
option to "on" and then no new clients were able to request the
certificate chain. Clients that were already signed had no problems
downloading the configuration catalogs and worked just fine. Only new
clients failed to work with the new server. The nginx logs would show
that the client was requesting the "/production/ca" file but the
server response was alway 404 not found and the client could never get
the certificate. Maybe if you force ssl_verify_client option you can
get what you want.

For me this was a problem rather than a feature and the problem was
mainly because  nginx (version < 1.0.0) did not support optional ssl
client verification as Apache does. With nginx 1.0.5 I can set
ssl_verify_client to optional and now my new clients get signed as
expected.  SInce all my clients are in the local LAN or connected via
VPN I think I can dismiss the middle in the man security problem.

regards,
Horacio
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 25/08/11 16:05, Horacio Sanson wrote:
> snip
> For me this was a problem rather than a feature and the problem was
> mainly because  nginx (version < 1.0.0) did not support optional ssl
> client verification as Apache does. With nginx 1.0.5 I can set
> ssl_verify_client to optional and now my new clients get signed as
> expected. 
For what is worth, this specific feature was added in Nginx 0.8.7 then
backported a little bit after into 0.7.63 (circa Oct 2009).
I do know this well because I wrote the patch so that we could support
puppet clients with nginx without resorting to using a different port
for CA :)

-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks for the suggestions, these have given us some possibilities to
look at.

Just to be clear: Is there no built in way to force the puppet client
to NEVER retrieve certificates/CA without verifying the certificate
chain first? (without hacking through code)

Thanks again

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Aug 25, 2011 at 8:02 AM, It Dept <it@ukcrd.com> wrote:
> Thanks for the suggestions, these have given us some possibilities to
> look at.
>
> Just to be clear: Is there no built in way to force the puppet client
> to NEVER retrieve certificates/CA without verifying the certificate
> chain first? (without hacking through code)
>
I may be reading your request incorrectly, but it almost sounds like you
don''t really want to have the Puppet CA at all, and just want to
generate
certificates manually and distribute them yourself.

Would launching all your masters with --no-ca help here?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Aug 25, 2011 at 8:02 AM, It Dept <it@ukcrd.com>
wrote:
> Thanks for the suggestions, these have given us some possibilities to
> look at.
>
> Just to be clear: Is there no built in way to force the puppet client
> to NEVER retrieve certificates/CA without verifying the certificate
> chain first? (without hacking through code)
To clarify, puppet will verify the agent and master certificates
against the CA cert. So I think your focus is on the CA cert. If you
distribute the CA as part of the puppet install, it should resolve
this issue. Make the CA file immutable as Mark has suggested. If you
want to take it one step further, maybe a feature request so puppet
agent doesn''t request the CA, maybe something like an option
:disable_cacert_download.

In order to verify the CA cert up some chain, it only make sense if
it''s not self signed (and I don''t believe puppet cert will
generate
anything other than a self signed CA), so we need to know what to
verify it against. Are you planning to have a third party like
Verisign/Thawte sign the CA cert?

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Aug 25, 5:37 pm, Nigel Kersten <ni...@puppetlabs.com>
wrote:
>
> I may be reading your request incorrectly, but it almost sounds like you
> don''t really want to have the Puppet CA at all, and just want to
generate
> certificates manually and distribute them yourself.
>
> Would launching all your masters with --no-ca help here?
We tried using our own existing CA infrastructure by using an
intermediate CA on our puppet master. During this test we were using --
no-ca. We manually generated certificates for the client and master,
but neither the master nor the client seemed to support using
intermediate CAs. The client simply failed to verify the certificate,
even when we tried putting the root CA and intermediate CA
certificates in the same file called ca.pem. This is unrelated to our
problem as it doesn''t solve the security problem, but I just thought
I''d share our experience in this area.

With regard to our current issue: we don''t mind the master acting as a
CA since we can manually generate certificates for the clients on the
master and transfer them to the clients ourselves. Our issue is with
the clients making unverifiable CA cert request. This cannot be solved
server side since even if the server refuses the clients requests for
the ca, there could still be a man-in-the-middle attack coupled with a
DNS poison which could lead to a third party CA being sent to the
client, compromising our security chain for the client.

On Aug 25, 7:22 pm, Nan Liu <n...@puppetlabs.com>
wrote:
>
> To clarify, puppet will verify the agent and master certificates
> against the CA cert. So I think your focus is on the CA cert. If you
> distribute the CA as part of the puppet install, it should resolve
> this issue. Make the CA file immutable as Mark has suggested. If you
> want to take it one step further, maybe a feature request so puppet
> agent doesn''t request the CA, maybe something like an option
> :disable_cacert_download.
You exactly right in terms of what we want to achieve. We want to
distribute both the CA and client certificates/keys manually as part
of the install process. We just want to disable the clients''
capability to ever make requests when they cannot verify the identity
of the server. I know that the client will not make these requests
when the certificates are put in place manually, but mistakes can
happen and it would be very difficult to identify where they had. It
does seem to be a matter for a feature request, but I would like to go
further and have the option to disable ALL unverifiable requests on
the client.
> In order to verify the CA cert up some chain, it only make sense if
> it''s not self signed (and I don''t believe puppet cert
will generate
> anything other than a self signed CA), so we need to know what to
> verify it against. Are you planning to have a third party like
> Verisign/Thawte sign the CA cert?
>
As I mentioned above we did try to have the puppet CA signed by our
own in house root CA, but we could not get puppet to accept a full
chain (unless there is a way to specify more than one ca.pem file?).
As it stands we are just using the standard puppet-generated CA
structure and want a way to stop clients downloading the ca from the
server when they cannot verify the identity of the server.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.