tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Client Authentication using SSL
Date Tue, 17 Jul 2012 14:13:59 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeffrey,

On 7/16/12 10:01 AM, Jeffrey Janner wrote:
> Thanks Chris, I'd seen a lot of traffic on the topic over the
> years, so knew someone had real-world experience on the subject. 
> I'll check out what you did a little further. Of course, thinking
> on my proposed plan, a really uptight security admin might not
> think it all that more secure that basic-auth over server-only
> SSL. You know the type: the guy that insists the SSLPassword value
> in server.xml be encrypted.

Yup.

SSL client certificates are great because it's basically impossible to
fake them, and once they are installed, you don't have anything to
remember (like a passphrase). So, you can do super-high-grade
authentication one-time, then issue the SSL cert to avoid all that in
the future. Plus, they can be revoked.

They can, however, be trivially copied and moved elsewhere. So, you
might want to couple the SSL certificate with some other kind of
authentication like passphrase or even just remote IP address checking.

The other nice thing is that you don't need the original
issuing-certificate's key in order to verify the authenticity of the
client cert: you can install the CA (and subs) certs on the server and
verify the validity of the client certificate without revealing any
secrets on the server (like the secret for the server's key, for
instance). That allows you to keep your super-secret CA keys under
lock and key but still use them for authentication purposes.

The real question is whether or not it gives you anything more secure
than what you already have (I dunno what you already have). The SSL
connection takes care of the security of the information in-transit.
The client SSL cert takes care of one factor of authentication: it's
something the remote client "has". Any security expert will tell you
that multi-factor authentication is superior (and they'd be right) but
you still have the problem of distribution of the token *plus* the
authentication of the user before issuing the token. For example, if
your authentication is non-existent for client-cert issuance, then the
second "factor" for authentication into your primary system is
entirely useless.

Web-based authentication is difficult to do in a really good way.
Sure, there are good tools (GPG, X509, etc.) and tried-and-true
procedures (username/password/PIN/whatever) but when it comes down to
it, allowing remote access to sensitive data is inherently risky. When
it comes right down to it, even a very well-implemented system still
needs to be used by humans, who will invariably find a way to poke
holes in your security -- say, by putting their passwords on post-its
on their monitors. Really, it's the humans that really mess up
security for everyone ;)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAFcycACgkQ9CaO5/Lv0PAYHwCeI2V4++1mMCTRrqUpipBnswHV
cyAAn0rROWS47++js5IMM7iFg0BRgZAk
=zbGQ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message