tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Janner <>
Subject RE: Client Authentication using SSL
Date Thu, 19 Jul 2012 17:05:36 GMT

> -----Original Message-----
> From: Christopher Schultz []
> Sent: Tuesday, July 17, 2012 9:14 AM
> To: Tomcat Users List
> Subject: Re: Client Authentication using SSL
> 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.

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:
For additional commands, e-mail:

View raw message