Develop Reference

X.509 certificates for authentication without using client SSL

I'm trying to improve some code that enables logging in to our application using digital certificates, probably certificates stored on PKCS11 tokens.
It's a Java client server application, with the server on JBoss [Wildfly], and a rich Java thick client. We also have a GWT/Javascript based web client, but this doesn't yet support certificate auth.
The current implementation uses 2-way SSL authentication if certificate authentication is configured, i.e. the server will require a client certificate when the connection is opened. This causes some problems, and in trying to find ways to address them I've been searching madly to see if there is a standard, 'Right Way To Do PKI Auth To A JBoss Application'.
However just about everything I have found on the subject seems also to revolve around using two-way SSL, which kind of implies that is the Right Way to Do It.
It seems undesirable to me, in that the network transport is quite a low-level concern, heavily separated from the application logic and stuff like authentication and user management.
In order to prove the client is a valid user of the system (as opposed to merely someone with credentials endorsed by a CA in the server trust store), the server application logic has to rummage around looking to find the certificate that was used on the incoming connection in order to scrape the Common Name off it. I've discovered that javax.servlet.request.X509Certificate is a standard-ish parameter one can query on the servlet, so it ought at least to be possible.
The other architectural problem this causes is that our app requires reauthentication for the lifetime of certain sensitive operations. If one is using the SSL connection to prove the user has the private key, then logically that would require opening a whole separate connection.
Logically, authenticating with a certificate would seem to require
The server generating a nonce
The client encrypting the nonce using the client's private key
The client sending that encrypted value to the server with the accompanying public certificate [or certificate chain].
Now, that is exactly what happens during an SSL handshake, but obviously a whole load of other baggage comes with it that is irrelevant to the application-level concern of authenticating the user.
I thought about implementing the steps directly myself, but this would seem to violate the first rule of crypto (Don't implement your own crypto).
If the server generates random nonces then that introduces a level of chattiness and statefulness to the process, which is doable but a pain when you are striving for a stateless and clusterable server.
Time-based One-Time Password implementations circumvent this, and seem to be a standardized mechanism for 2-factor authentication that is getting support from Google+ and the like.
However I can't find anything in the way of out-of-the-box libraries that will let me build an implementation using certificates directly from an imposed PKI.

How to secure communication in client-server app?

I've got backend running on the tomcat server and client running in the browser. Application is built on Spring 3 MVC + Spring security framework. How to secure the communication ? Is there other option than just to set the server to be accessed only via HTTPS ? I've got no experience with this so it might be a stupid question, but will this affect my application and do I have to set something up in my app, when the server shall communicate with client via GET/POST request via https ?

It depends somewhat what you mean by "secure." If you want privacy, you must use TLS (SSL) as a transport.
If you're only concerned with authentication, then you have another option: Digest Authentication.
Digest Authentication allows the client (browser, usually) and the server to exchange authentication credentials in a secure manner without securing the entire communication. If you use Digest Authentication, then third parties can still:
See what data the client and server exchange
Insert themselves between the client and server and alter the exchange
What third parties cannot do is spoof the authentication or steal username/passwords in transit.
If that's not secure enough, you need TLS. You do not necessarily have to purchase a certificate. You can use OpenSSL to generate your own. This certificate will not automatically be trusted by browsers, however, so you can't really use it for public sites.
You will need to consult your server documentation for how to set up HTTPS or Digest Authentication, depending on which fits your needs.

Your application should not be affected by switching from HTTP to HTTPS, Tomcat handles this or maybe an Apache in front. It's important to understand, that HTTPS is a server-thing, not an application topic, because the client makes a connection to the server (Tomcat), not to your application. Check out the Tomcat documentation, it's pretty clear about how things work.
And, like the others said: From what you've said it's best to use HTTPS (TLS/SSL). Certificates are a bit frightning at the beginning, but it's worth to invest the time.

HTTPS is the (S)ecure form of HTTP, since you have an HTTP client server application I would certainly used HTTPS. All you need is to create an SSL certicate for your website and restrict access to your website to HTTPS only, then you are 99.99% secure.
Your certicate can be either commercial from Versign or equivalent or some open source engine.
for the clients nothing needs to be done to support HTTPS

SSL and authenticating users

I have a REST API which clients connect over SSL (self signed cert 2048bit)
I was thinking of implementing the following security
The client requests a RSA public key from the server
Encrypts the username / password
Adds these to the header of EVERY REST call allowing the server to be stateless
The application involves users adding credit cards (the numbers themselves are encrypted) and purchasing products so security is critical
We also have very limited time from a iphone client point of view so I was hoping if the above would be suitable?

Usually, when it comes to security, one doesn't want to reinvent the wheel. It's way better to use state-of-the-art technologies, so you'll benefits from others' (likely more skilled than you) work.
If you have a RESTful API on SSL, I don't think you have written your own custom TCP protocol. Likely you'll use HTTP, so since it's on SSL, you are on HTTPS.
When using HTTPS, your browser makes sure that the request is signed and encrypted so that only the other end (the service) can authenticate the client and decrypt the message. So there is no need to encrypt data and using custom headers. A simple cookie-based session is enough so you don't send users' passwords in every request.

java security configuration for ssl

I have the following question on SSL/TLS.
After the server hello, starts the authentication phase of the server.
From various articles/books, it appears that this phase is optional. E.g. in wiki
The server sends its Certificate
message (depending on the selected
cipher suite, this may be omitted by
the server).
But I do not understand what it means to say that it depends on the encryption suite.
So my understanding is either a ServerKeyExchange or a Certificate follows a ServerHello.
So my question is, can the server authentication be omitted all together?
For example to omit client aunthentication in Tomcat, you just configure the connector to not request it.
How can the server authentication be omitted? Does it depend on the java framework I use, if it supports it?
And what does it mean to omit the server authentication? If the certificate is not send then the ServerKeyExchange becomes mandatory, or usually frameworks allow provisioning of a local public key instead if one wants to by pass-authentication phase for performance or because it does not make any sense?
Or does this depends on the encryption suite somehow, as wiki seems to imply?
NOTE:
I understand that server should always be authenticated. The context of my problem though is a client app and server running on the same machine (and java runtime I guess) so it can be considered safe to bypass server authentication (I think).
Any input is highly welcome!
Thanks!

In TLS/SSL, server authentication is optional.
If you choose TLS/SSL cipher suite without authn (such as TLS_NULL_WITH_NULL_NULL (turns off authn and encryption) or TLS_DH_anon_XXXX (use only encryption) in TLS specification), server certificate won't be sent.
TLS/SSL without authn doesn't seem to be supported pure-Java connector.
But I think the native-connector with SSLCipherSuite=aNULL supports it.
I don't know it's safe to disable authn, i.e., attacks such as DNS-spoofing might be threats.
I think you'd better to use server authn if performance is not problem.
Or, turning off TLS/SSL itself might be choice. (Encrypting server-client communication might be meaningless because administrator of the computer can steal certificate files and dump JVM heap.)

Authentication and Encryption are important when data travels across an untrusted network or when one of the endpoints is not trusted. If you application only makes connections on localhost, then Authentication and Encryption aren't important (the fact that your data and application are on locahost implies a trust in localhost).

you can get ssl configuration for tomcat 6 from
http://nayanmali.blogspot.com/
you got whole configuration and how to create keytool and how to generate certificate form that

Authentication: Kerberos or SSL?

I'm in the "pre-design" phase (if there is such a thing!) for a Java EE app that will use a Swing box on the client end and implement components for both web and server tiers.
I'm instantly presented with some technology choices and have been reading up on the differences between how Kerberos and SSL work. One area that I have not been able to find any answers to has been the subject of how to choose between Kerberos or SSL. In other words, how do you tell when it is appropriate to use either protocol?
Let's assume that the Swing client isn't bound by a particular transport (UDP, TCP or otherwise) and could use either/any. How does one choose between which of these two is a better match for their application?
Thanks!

and suddenly (several months later) a wild Sys Admin appears...
I'm going to have to be a voice of dissent on this. The notion that you would ever establish a PKI without a CA is incredibly absurd. You have to maintain the integrity and performance of the PKI by streamlining the creation process. You have to create and store the certs somewhere, where is that going to be? Boom, you have a CA. Any decent PKI is also going to require a CRL be maintained, is the administrator supposed to just write that by hand? You can also forget about having different types of 509's as the overhead of maintaining that by hand would blow-your-mind-wide-open-and-turn-it-into-grey-slurry.
I suppose you could just manually create the tickets with openssl's CLI and just ftp them to the remote clients, but that gets to be a HUGE hassle for deployments of appreciable size. Essentially, if your deployment is so small that generating the certs by hand (repetitive entering of information and all) and then just not worrying about a CRL is a reasonable plan, you don't need an advanced authentication system at all. Something along the lines of TLS+LDAP (one server cert for confidentiality and not authentication) is more appropriate.
Ok, now that I've cleared some misconceptions, let's actually answer your question: When would you want to use SSL over Kerberos for authentication? x509-based authentication is an incredibly nebulous beast, mostly on account that most people (like Michael-O above) don't realize that SSL work specifically because it's authenticating users. There are a few FTP programs that I know of that authenticate that way, middleware employs it...sometimes (which sounds close to your use case from the java talk), and vpn clients/gateways often authenticate with SSL certs.
Usage of SSL would imply the PKI I spoke of up there, which would work great if your use case involves confidentiality. DoD is a good example of an enterprise that makes extensive use of PKI for functions outside of authentication. In that context, supposing all relevant client programs support x509 authentication makes a lot of sense. It's still an exotic set up, and you would still have to figure out how the end-users will "present" their SSL credentials to the system (client configuration, smart cards, etc) but it would fit together nicely. Besides the odd fit, kerberos authenticates by way of a temporary ticket, whereas SSL certs typically last a long time (which is why a CRL is required) meaning that if the never-changing key is factored on one cert the attacker will have several months of free rides before they have to find a new cert, versus kerberos where they only have it for a day and that's only if the ticket isn't destroyed.
All other cases should use Kerberos authentication when possible. It provides the right layer of security and is actually designed as a large network authentication system, which is why you have things that are hard to duplicate with SSL (like authenticating as a service instead of a regular user) and just plain work for their intended purpose. Your use cases are always going to need to take into account existing infrastructure which is probably going to be kerberos-oriented, sometimes LDAPS-oriented, but almost never x509 authentication-oriented. In other words: whatever you're writing is MUCH more likely to be running in a kerberos infrastructure already, so you might as well plug into that somehow. You'll also benefit more from administrator familiarity with Kerberos-as-authentication than 509-as-authentication. The con on this is that confidentiality outside of the ticket is kind of a joke. NFSv4 has some weak DES (and no I didn't mean 3DES even) encryption that it (somehow) relates to the kerberos ticket but it does authentication and that's basically all it does.
I'd like to see some of x509's flexibility combined with kerberos-style infrastructure (recognition of services and the "one time pad" aspect of having a soon-to-expire ticket) incorporated into a solution that was more widely implemented than x509 is now, but at this stage it's mostly day-dreaming.
Summary:
x509 is good if infrastructure requirements won't be a problem and you'll be using PKI for other stuff anyways, but might be duplicating effort needlessly otherwise or if the deployment is probably going to have a kerberos infrastructure anyways.
Kerberos is a similar but better authentication scheme that is more widely used/understood but won't help you with PKI at all, you get authentication, and that is it.

Comparing Kerberos and SSL/TLS doesn't make sense.
Kerberos is an authentication protocol.
TLS is a protocol for securing the communication between two parties, which relies on mechanisms for authentication and encryption. How they work depend on the chosen cipher suite. Although most usages of TLS (e.g. HTTPS) use X.509 certificates, in which case you're likely to use a PKI for the authentication of the remote party, Kerberos cipher suites can also be used. Few TLS stacks support these Kerberos cipher suites as far as I'm aware (Java does).
It doesn't have to be one or the other. For example, even if you're using SPNEGO (Kerberos) HTTP authentication, it often makes sense to secure the transport using TLS (often with an X.509 certificate on the server side, verified via a PKI). If not, the SPNEGO tokens exchanged in the HTTP headers guarantee the authentication, but the rest of the HTTP messages could have been modified by an attacker.

This could be useful:
http://www.faqs.org/faqs/kerberos-faq/general/section-31.html

Consider that any solution involving Kerberos will be more complicated than SSL because it requires an additional, third component, the Authentication Server, which must be managed and administered (e.g. MS Active Directory) whereas SSL is simply a client/server protocol.

You are mixing stuff. Kerberos is an authentication protocol, SSL ist encryption. Kerberos is the way to go if you are in a corporate environment.
Edit: Kerberos can also encrypt your data traffic transparently. No need for SSL certiticates.