- Thread starter
- #21
M
Michael Ströder
VanguardLH wrote:
> "Michael Ströder" wrote in <news:9q0ii5-u7e.ln1@nb2.stroeder.com>:
>
>> VanguardLH wrote:
>>> Please indicate in what scenario a client would need to first obtain a
>>> cert to then use to identify itself to a target web or mail host.
>> I started using SSL client authentication (additional to the required
>> server authentication) for HTTPS, IMAPS and SMTP/STARTTLS with
>> client-side user certs 10 years ago (using Netscape Communicator 4.5 and
>> Apache/mod_ssl, stunnel to imapd and postfix with starttls patch).
>
> 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 have seen encrypted "keys" used by some
>>> VPN programs to validate that the client's host is allowed to connect to
>>> the corporate network but those keys were not certs.
>> You can also use end user certs for client authentication in a VPN. Have
>> already used this with IPsec/IKE and SSL-based VPNs where appropriate.
>
> 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.
> "Michael Ströder" wrote in <news:9q0ii5-u7e.ln1@nb2.stroeder.com>:
>
>> VanguardLH wrote:
>>> Please indicate in what scenario a client would need to first obtain a
>>> cert to then use to identify itself to a target web or mail host.
>> I started using SSL client authentication (additional to the required
>> server authentication) for HTTPS, IMAPS and SMTP/STARTTLS with
>> client-side user certs 10 years ago (using Netscape Communicator 4.5 and
>> Apache/mod_ssl, stunnel to imapd and postfix with starttls patch).
>
> 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 have seen encrypted "keys" used by some
>>> VPN programs to validate that the client's host is allowed to connect to
>>> the corporate network but those keys were not certs.
>> You can also use end user certs for client authentication in a VPN. Have
>> already used this with IPsec/IKE and SSL-based VPNs where appropriate.
>
> 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.