> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Tuesday, July 17, 2012 9:14 AM > To: Tomcat Users List > Subject: Re: Client Authentication using SSL > > -----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
Chris - Right now, my auth is just a user/pw form put up over SSL. I figured adding the client-cert-auth to the SSL connection and then throwing up my form as usual would be a good next step. That way I've verified the client system is approved, and so is the users. Still could have a disconnect in that the cert is approved, but not necessarily for the userid involved. I've seen some how-tos that suggest putting the userid as the cname on the cert and then requiring the matching pw. It's certainly more secure, and solves the problem of approved user A masquerading as approved user B that is allowed by my first step. However, it also requires reworking the app to pull the uid from the cert, and is probably a level of security above what most of my customer base cares about. I'm basically looking at alternatives for future business into sites that really want that extra level of security. There are potentially other methods of providing for the higher security at those installations. For example, some have their own extranet which is heavily tied down, and we could go in behind that. Then I don't really care anymore, as the high-level stuff was already done just to get on the network. For future sales, it's basically going to require discussions of what they think is appropriate. Thanks again for your help. Jeff __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
