You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Bill Moseley <mo...@hank.org> on 2007/09/22 18:04:41 UTC
[OT] Client authentication
This isn't mod_perl related, but I'm hoping someone here has
experience in this area and can provide some feedback.
Recommendation of a better list for this question is also welcome.
I have a mod_perl/SOAP::Lite server application where I need to
authenticate the connecting clients. The clients are all SOAP::Lite
applications and connect to the server over the Internet.
The server allows SSL connections only, and the server has a list of IP
addresses of the clients that are allowed to connect.
I'm also looking at using client certificates, which is something I
have not setup before.
First, I'm not clear in this closed application if I need a real CA or
if I can self-sign and be my own CA. (I read someplace that
this should be avoided for performance reasons, although that might
have been referring to use in web browsers.)
I'm also not clear if there's an advantage to using a client
certificate. Another other option would be a shared secret and
generate a message digest that can be verified on the server side.
If the concern is that someone might spoof an IP address then the
shared secret seems adequate.
If the concern is that someone might hack a client machine and make
fake requests to the server then it seems the hacker would have access to
the client cert just as easily as the shared secret.
But, as I said, I have not used client certs before so I might be
missing a key point.
What would you recommend, and why?
Thanks,
--
Bill Moseley
moseley@hank.org
Re: [OT] Client authentication
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Bill Moseley wrote:
> On Sun, Sep 23, 2007 at 01:44:44AM -0700, Philippe M. Chiasson wrote:
>>
>>> If the concern is that someone might spoof an IP address then the
>>> shared secret seems adequate.
>> If the secret is ever compromised, you have to update every single
>> client/server out there. If a client cert is compromised, you revoke it
>> and carry on doing business as usual.
>>
>>> If the concern is that someone might hack a client machine and make
>>> fake requests to the server then it seems the hacker would have access to
>>> the client cert just as easily as the shared secret.
>> Yup, but you can revoke a client-cert, not a shared secret...
>
> Hum, perhaps I'm missing something.
>
> The shared secret can be a single pair between a specific client and
> the server.
>
> The server is setup with a list of known secrets, so it's possible
> that each client has its own secret pair with the server. If a client
> is compromised then just that secret pair is removed/replaced and
> other clients continue.
That's correct, however, the idea with public-key crypto (as in this case)
is that the key generation can be handled by the clients themselves, and
the CA's responsability is just signing stuff.
But in your case, if managing shared-secrets in this way is not a problem,
then it doesn't matter what approach you chose.
>>> But, as I said, I have not used client certs before so I might be
>>> missing a key point.
>> Oh, and a bonus point. Client applications can generate their own certs,
>> and only get your CA to sign them. It's a much neater approach IMO. And
>> totally worth the slight extra complexity of running your own CA.
>
> Plus, it all happens at a higher level. The shared secret has to be
> at the application, where mod_ssl can handle client cert.
>
> It's just something I need to learn more about...
Applied Cryptography - Bruce Schneier (http://www.amazon.com/dp/0471117099)
------------------------------------------------------------------------
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
Re: [OT] Client authentication
Posted by Bill Moseley <mo...@hank.org>.
On Sun, Sep 23, 2007 at 01:44:44AM -0700, Philippe M. Chiasson wrote:
>
>
> > If the concern is that someone might spoof an IP address then the
> > shared secret seems adequate.
>
> If the secret is ever compromised, you have to update every single
> client/server out there. If a client cert is compromised, you revoke it
> and carry on doing business as usual.
>
> > If the concern is that someone might hack a client machine and make
> > fake requests to the server then it seems the hacker would have access to
> > the client cert just as easily as the shared secret.
>
> Yup, but you can revoke a client-cert, not a shared secret...
Hum, perhaps I'm missing something.
The shared secret can be a single pair between a specific client and
the server.
The server is setup with a list of known secrets, so it's possible
that each client has its own secret pair with the server. If a client
is compromised then just that secret pair is removed/replaced and
other clients continue.
> > But, as I said, I have not used client certs before so I might be
> > missing a key point.
>
> Oh, and a bonus point. Client applications can generate their own certs,
> and only get your CA to sign them. It's a much neater approach IMO. And
> totally worth the slight extra complexity of running your own CA.
Plus, it all happens at a higher level. The shared secret has to be
at the application, where mod_ssl can handle client cert.
It's just something I need to learn more about...
Thanks,
--
Bill Moseley
moseley@hank.org
Re: [OT] Client authentication
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Bill Moseley wrote:
> This isn't mod_perl related, but I'm hoping someone here has
> experience in this area and can provide some feedback.
> Recommendation of a better list for this question is also welcome.
>
> I have a mod_perl/SOAP::Lite server application where I need to
> authenticate the connecting clients. The clients are all SOAP::Lite
> applications and connect to the server over the Internet.
>
> The server allows SSL connections only, and the server has a list of IP
> addresses of the clients that are allowed to connect.
>
> I'm also looking at using client certificates, which is something I
> have not setup before.
>
> First, I'm not clear in this closed application if I need a real CA or
> if I can self-sign and be my own CA. (I read someplace that
> this should be avoided for performance reasons, although that might
> have been referring to use in web browsers.)
If it's an internal application, I'd go 100% self-signed with your
own CA. It's not hard, and it will save you tons of $$$.
> I'm also not clear if there's an advantage to using a client
> certificate. Another other option would be a shared secret and
> generate a message digest that can be verified on the server side.
>
> If the concern is that someone might spoof an IP address then the
> shared secret seems adequate.
If the secret is ever compromised, you have to update every single
client/server out there. If a client cert is compromised, you revoke it
and carry on doing business as usual.
> If the concern is that someone might hack a client machine and make
> fake requests to the server then it seems the hacker would have access to
> the client cert just as easily as the shared secret.
Yup, but you can revoke a client-cert, not a shared secret...
> But, as I said, I have not used client certs before so I might be
> missing a key point.
Oh, and a bonus point. Client applications can generate their own certs,
and only get your CA to sign them. It's a much neater approach IMO. And
totally worth the slight extra complexity of running your own CA.
Check out TinyCA as a good simple tool for this kind of CA (http://tinyca.sm-zone.net/)
------------------------------------------------------------------------
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/