----- Original Message -----
> From: "John Gelnaw" <jgel...@gmail.com>
> To: "puppet-users" <puppet-users@googlegroups.com>
> Sent: Tuesday, 10 January, 2017 01:17:58
> Subject: Re: [Puppet Users] Over-engineering rant
> On Monday, January 9, 2017 at 2:39:38 PM UTC-5, R.I. Pienaar wrote:
>>
>>
>> Because if i can convince your client to connect to $evil_ca, then what?
>> How's it to know its a new legit ca and not a new bad ca?
>>
>
> The same way it "knew" when you originally provisioned it-- It didn't. In
> fact, the agent, by default, displays the *request* fingerprint-- but never
> the server fingerprint, and doesn't give me a chance to verify it.
>
> So how many times have you verified you didn't talk to an evil CA when you
> originally connected an agent?
Every time? I logged into my known CA using a non Puppet means, I know it's
the known CA because of SSH safety checks and I sign the client I expect to
sign on this known CA using the information at hand - the client fingerprint
that I visually confirm.
> And the thing is, if I delete that cached file, it promptly (and as near as
> I can tell, blindly) downloads the ca.pem file anyway.
But this is not enough, the new ca.pem isn't all you need, you need certs signed
by the new ca too.
Today the trust system is such that the master has to know its handing code
out to trusted clients - hence giving you the info you need to establish client
trust. Yes more is needed, see below.
> The entire point of a public/private key system is the ability to trust.
> The agent can trust the server, the server can trust the agent.
>
> The lack of ability to renew that trust *before* it expires is a serious
> failure-- Recently, my initial 5 year CA expired. The "conventional
> wisdom" was to REBUILD MY ENTIRE ENTERPRISE. If I'd had to do that,
> there's a good chance I'd have reevaluated my 5 year old decision to go
> with puppet-- not saying I wouldn't have wound up with puppet anyway, but
> I'd have looked much, much harder at competing products, which have made
> huge progress in 5 years.
Yes, as I said to you before, the Puppet CA system needs a lot of work, it
was designed now ~10 years ago and much have changed, it's had some organic
growth but a huge fixup is needed. I bet 10 years ago Luke did not expect
the CA to be around 10 years on and did not imagine we are where we are
so understandable how it is, but it should have been redesigned a while
ago already.
Turns out it's not news to anyone that this is needed and if you look in
Jira there is a whole group of tickets covering exactly that and afaik
it's quite high priority. I am sure constructive input on those will be
appreciated.
This is why I've previously, when you contacted me off list, also asked
the same question to you: Have you filed any tickets or are you just
ranting to make yourself feel better?
To expand on the issue with redownloading CA and blind trust, lets
consider a situation I am often in.
My laptop laptop1.mycorp.local is Puppet managed, have a cert and
a CA. My laptop is using DHCP because I travel a lot and it uses
the default 'puppet' name for the master.
I go to evilcorp.local who gives me a DHCP host name sucker1.evilcorp.local,
my Puppet agent makes a new cert automagically for this name, sends
it off to be signed by puppet1.evilcorp.local who in turn auto signs
it, I cache the new ca.pem and we're off. It runs a exec{} that
rsyncs my whole ~ off to its NAS neatly bypassing any disk encryption
I might have and so steals all my other clients code and secrets I
happen to have on my laptop.
Except this doesn't happen because it doesn't redownload the CA.
Not redownloading the CA is CRITICAL. And yes naming things still
suck, calling it a cache is a mistake, not treating it like a cache
is not.
Today you can mitigate this happening even in the case where somehow
ca.pem goes missing - like it ends up in lost+found. By setting a
specific certname that is related to your HARDWARE and not your
SOFTWARE. Don't use 'puppet' as a master name. Not enough though
since my whole SSL dir and config might go missing and this is the
problem with Puppet and its annoying pure local disk based approach
to this.
Local disk issues aside, Ideally I want:
# puppet agent --waitforcert 10 --ca_finger_print xx:xx:xx
It should send off the CSR and only accept a signed cert back from
that CA, it should only store that CA, it should store that finger
print in a lock file and ONLY EVER talk to that CA or do anything
as a result of that CA.
If it has any private key at all, it should never automatically
generate a new private key regardless of certname. Automatic
bootstrapping should only happen when the whole ssl setup is
completely missing.
The process of reissuing expiring certs or cycling your client
certs should be done ONLY under the management of the existing
trust relationship and never automatically.
* A week/month before CA expires, the master CA makes a new one
* New connections come in, they are trusted by not yet expired
CA, this already trusted CA instructs the agent to either
redo its certificates of redo certs and CA. The latter
would update the lock file with the new CA fingerprint in
addition to the old one
* Agents goes through the cert/ca dance but now as it's already
under the existing CA trust relationship it can easily be auto
signed. Made safe by CSR extended attributes that contains a
single use shared secret the CA gave it via the SSL connection
* On CA expiry, start using the new credentials.
Now we can set much shorter cert life times, I am especially interested
in short agent cert life times, the same process can be used to also
move agents to a new CA etc
Tools should exist to reset a agent back to factory default where it
will start a whole new fresh bootstrap as it was first day. There can
be no safe middleground other than make new certs as part of existing
trust as above, or establish new trust from scratch. You cannot safely
just download new CAs (and anyway its not enough as mentioned)
This is very different from WHY ARENT YOU DOWNLOADING JUST ANY RANDOM
ca.pem YOU ARE GIVEN THIS WILL FIX ALL THE PROBLEMS WHY ARE YOU SUCH
IDIOTS? As per your emails.
It's a ongoing trust relationship that is extended under control,
the basic design isn't new or anything the same happens in IKE, TLS
etc except there it's in memory which is very different.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1604914912.136548.1484026624618.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.
