-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
