VanguardLH said:
Yep, after I checked, client authentication can be provided via a
certificate. However, I sincerely doubt that a cert obtained for e-mail
use is usable for a site's authentication of clients that connect to it.
Whether it does make sense to use e-mail certs also for client
authentication depends on the security policy in effect and the
enrollment process.
Where do these clients get those certs to authenticate themself to your
site? Aren't they issued by your site?
They were issued by a CA in a well-defined enrollment process with
client-side key generation.
The e-mail certs are coming
from a trusted 3rd party. In your scenario where you want to regulate
who can connect to your server and have them authenticate when to do so,
aren't you the one issuing the cert?
In former times I were the CA (I've implemented the open source solution
was
http://www.pyca.de back in 1998). But I see no problem to use my
Thawte e-mail cert also for SSL client authc. Whether one trusts a 3rd
party to properly do the identity checking is a question everybody has
to answer himself.
For me the important key point is the client-side key generation done
over a web interface and the authc done when submitting the
certification service request (CSR) containing my public key.
I checked with a guy from IT during lunch. The brief discussion was,
yes, they do issue a cert (they issue it, not some 3rd party). That
cert really only gets used during the encryption phase to protect the
traffic and only partially to verify the client connecting to their
network.
Sorry, please have a closer look at the cryptographic protocols used.
Checking with a IT guy during lunch is not enough to fully understand
things.
There is no distinction between using the client cert "only for
encryption". There is no proper authorization (here allowing to use a
connection key) without proper authentication.
A cert could be moved to another host.
How to keep private keys secret is another issue. Smartcards usually
help. Well, a user can pass his smartcard to another user telling him
also the PIN. There is no technical solution to prevent this from happening.
They want their own specific laptops connecting from
the outside (for contractors) or to regulate exactly which desktops (for
their full-time employees) can connect to their network.
Use smartcards which people need all the time (accessing the building,
buying lunch) so it's a loss for them to give it to others.
So they have
you install their VPN software which requires negotiation with an IT rep
to generate a secret key that is encrypted in the registry and which
snapshots that laptop so the secret key isn't usable on another host.
Is this Cisco VPN? Then SCEP is used. But skilled people can surely
extract the private key from the registry.
So when you use their VPN software, it needs the secret key to check
that host is allowed to connect to their network along with THEIR cert
to authenticate that host on their network.
I think this is flawed because they are reyling on a host-based private
key which they assume cannot be exported and reimported on another
system. I would not do it like this.
And even then you come into
a special "zone" in their network that has further restrictions than a
host sitting in their building.
This does not have anything to do with PKI and certs. That's network
infrastructure.
I knew about the VPN setup and key
because I had to input the generated key provided by a code generated by
their program on my host, giving it to the IT guy, and getting back
another code.
Sounds like SCEP.
I wasn't aware that the process also connected to their
cert server to get a special trusted one installed on the host that I
must use to connect from outside.
Well, you need a trusted root CA cert.
I can't just move their trusted cert
to another host to get it to connect to their network
I think you could if having enough skills. ;-)
Still, I really doubt an e-mail cert from a 3rd party is being used in
this situation to validate the client host is authorized to connect to
the corporate network. The IT guy said it must be THEIR cert used on
the client host.
Well, that might be true in their configuration. But that does not mean
that it's impossible or insecure to do it otherwise.
The key point with X.509 certs is that the user or system is the only
holder of the secret key. The public-key certs have to be validated
against a public-key cert of a (root) CA cert marked trusted.
Another reason this setup is used (where their cert
gets installed) is something the IT guy alluded to: man-in-the-middle
"attack" but which is their proxy being able to intercept and
interrogate SSL traffic (so any employee's traffic can be investigated
for policy or company violation).
Well, that's another point.
He didn't want to go into details, and lunchtime was over,
other than to mention they can look at anyone's SSL traffic going
through their network, in or out or internal.
I know that technique. There are off-the-shelf products implementing
something like this.
Ciao, Michael.
