I changed the subject.
Also, while this fork is not specifically a mainframe topic, it's really
important, and most of us will have it thrown in our face, even as
mainframers.
On 8/29/23 15:29, Grant Taylor wrote:
On 8/29/23 10:46 AM, Charles Mills wrote:
Don't want to get into one of the peeing contests that have become
all too common here.
Neither do I.
I do want to have a polite and professional discussion about what
things are capable of.
Hopefully I'll learn things from you -- I usually do. :-D Maybe, if
I'm very lucky, I'll teach you something. :-)
Same here.
And I confess to being contrarian.
I relish butting heads with Alan Altmark over things like MAC vs DAC.
(It's not for the head butt, which hurts, but for sake of digging down
to the foundation.)
Let me just say that never mind any enterprise PKI CA constraints, I
think Tom was talking about OpenSSL on a PC.
Why elide what is a very germane safety component? That being
restricting what a given CA is allowed to sign?
OpenSSL stores private keys -- private keys -- in a pretty accessible
format.
The *format* really doesn't bother me, other than w/r/t processability.
It's true that complicated access methods will slow down an attacker.
Problem is they also slow down legitimate work, and that effect is
multiplied. (Attacker only needs to succeed once; the good guy must
succeed time after time after time.)
OpenSSL /can/ store the private key in a file.
OpenSSL /can/ /also/ depend something like a YubiKey to store the
private key.
If I can get into Tom's PC -- perhaps while he is at lunch, or with a
clever phish -- and get that private key, then I can generate server
certificates for any site in the world and Tom's associates will
trust those certificates.
Maybe, maybe not. It will depend if the private key is password
protected or not. If there is a password, it won't be a walk up and
sign without knowing the password.
Not criticizing Tom or his processes here. Just pointing out to
readers that there are some significant risks in general to the
approach of "oh, I will just create an ad hoc CA and have my users
trust it."
I agree it's not effective for everyone to run their own CA. But for
purpose of education, a "live" in-house CA comes in handy.
I agree that there are risks.
It's a question of which is more risky long term:
1) training users to click past certificate warnings
2) the potential for someone to abuse Tom's CA which is constrained
to the enterprise domain name and has a hardware token (YubiKey)?
It's all about the lesser of the evils.
YES
And making it harder (more expensive) for the attacker (relative to his
ROI).
Trusting a CA is implicitly trusting everything that anyone does with
its root private key.
That's where a constrained CA / root key comes into play.
Trusting the key to sign *. is very bad.
Trusting the key to sign *.example.com, not so much so. Especially if
example.com is a private internal domain not possible to use in the
real world.
Yes, it is no different in some ways than trusting DigiCert. The
difference is that DigiCert has very rigorous protocols for
protecting its root private keys. OpenSSL does not.
It's possible for Tom, et al., to make reasonable approximations of
what DigiCert, et al., are doing. If Tom's company wanted to, they
can purchase a more professional Hardware Security Module (HSM) that
can get quite close to what more professional entities do if they so
choose.
But using something like a YubiKey to hold the root key of for an
enterprise CA constrained to the internal domain is probably
reasonably safe. Especially if said YubiKey is used to sign an
intermediate certificatte -- like the big kids do -- and storing said
YubiKey disconnected, in a safe in between uses once a quarter.
Especially if the system that does the signing is disconnected from
the network.
I've been simmering a blog post about MFA since GitHub pressed the issue
recently.
YubiKey is part of that because it can become a new single point of
failure.
In all of this, one of the biggest overlooked thingies is new points of
failure. We forget that locking out bad guys kinda sucks for US when WE
suddenly look like one of the bad guys. (Machines cannot tell the
difference.)
This is not a slam on YubiKey.
It's an observation that our systems need failover factors and most
developers still don't think about that.
I think it's well within reason for individuals, and especially
businesses to fairly safely have an (Enterprise) CA that is
constrained to their organization.
Grant. . . .
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
