On Tuesday, January 10, 2017 at 12:37:14 AM UTC-5, R.I. Pienaar wrote:
> > 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.
But when you connect agent "A" to server "B", unlike SSH, there's no option
of confirming the server's identity.
If I've connected to a rogue CA, I would expect it to autosign my cert
request as quickly as possible, and start spamming bad catalogs at my agent.
Verifying the correct agent fingerprint when you sign the cert is not the
time to be paranoid, merely a time to be cautious (in case you hand out any
restricted information such as passwords in your catalogs).
> 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.
>
Now, that's where things get interesting. I mentioned before that I
generated a new CA, signed with the old private key. All of my existing
agent certs kept working.
When it comes to certificate wizardry, I'm not a master-- mid level
apprentice would be a better description, but the certificate wizard in my
office was unsurprised that I didn't need to generate new certs.
> 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?
>
I didn't actually see a response to my offline comments-- I assumed they
got bit bucketed, so I came back here.
Historically, I've contributed to one issue a long time ago, haven't filed
new issues, because frankly, there was nothing in the discussion I felt I
could contribute to, other than "current system bad, pls fix!".
As for ranting, I have had two major complaints about puppet, and I
expressed both here-- hopefully in a civil fashion. Neither has been a
show stopper, but both have been a source of frustration.
> 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.
>
Now, I don't want to be misunderstood here, so I'll speak plainly:
Non FQDN's are the work of satan. If you can't be bothered to specify the
fully-qualified domain name for your One True puppet master, that's your
fault.
> 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.
>
What you've described is your laptop blindly trusting the DHCP server and
the local DNS server, and doesn't properly use DNS (let alone DNSSEC) to
verify it's talking to the same puppet master it's registered with.
The whole point of SSL is that I have a certificate that proves to the
server I am who I claim to be. The server ALSO has a certificate that
proves it's who it claims to be.
If your only safeguard against not getting hijacked by evil puppet masters
is to not renegotiate a soon-to-be-expired CA, then puppet has a flawed
security model.
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.
>
If you interpreted my emails (posts) that way, I'm very sorry-- My original
complaint was that there was no functionality to update a
valid-but-about-to-expire CA with a new one, without manually deleting the
existing CA, and blindly trusting the new CA.
The fact that I was able to generate a valid new CA that was still
recognized by my existing agent certificates apparently escaped you.
At no time did I intend to suggest that any operation (including renewing
the agent cert) should be carried out in a state of non-trust.
And anyone who has their puppet server name on their laptop set to "puppet"
is not allowed to yell about security. EVER.
--
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/edee6559-869e-4ae1-8770-f5d7e88171a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
