Disabling server authentication
Hi,
I need to disable the server authentication stage of the SSL handshake protocol. I'm only interested in authenticating the clients you see.
Does anybody know how to do this?
According to the JSSE documentation, it is possible
"3 - Certificate - The server sends the client a certificate or a certificate chain. A certificate chain typically begins with the server's public key certificate and ends with the certificate authority's root certificate.This message is optional, but is used whenever server authentication is required."
http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.html#HowSSLWorks
I have tried searching, but it seems that everybody creates SSL connection for server authentication over the web as opposed to just client authentication :p
If you are coding both ends in Java the easiest way is to setUseClientMode(true) at the server and false at the client before doing any I/O. Otherwise you will have to enable a non-authenticating cipher suite and then do set NeedClientAuth (true) at the server.
ejp at 2007-7-7 3:25:57 >
Thanks for the reply :)
Yes I am writing both ends.
I have just tried adding the appropriate useClientMode() to both the server and the client. Now I get a handshake exception after the clients hello.
Connection thread, handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common
I think this means the server can't find a suitable cipher suite when the handshake is in the server hello stage. I don't know what would cause this though as I'm still al little clueless regarding the different cipher suites :|
Am I correct in thinking that the useClientMode requires a different type of handshake (or one that follows different rules) and that also requires a different cipher suite?
Nevermind, fixed that problem.
My client wasn't pointed at the keystore and thus wasn't able to provide the key for encrytion (I think).
Now I have the problem of having to distribute the keystore with the client.
Does that mean somebody could
*access the keystore
*create a client prgram and sign it with the key in the keystore
*run new client and be authorised (since key is in servers truststore)
The public key is in the keystore, the private key is only in the truststore. You need the private key to sign things and the public key to verify the signature.
ejp at 2007-7-7 3:25:57 >
I thought the keystore contained both keys and the truststore contained the exported certificate? For practical use anyway, since I think they are both capable of storing keys and certificates
If I try and sign something with the privatekey via the truststore I get an error
jarsigner: Certificate chain not found for: <alias>. <alias> must reference a valid KeyStore key
entry containing a private key and corresponding public key certificate chain.
That also suggests that the private key is in the keystore. What I gathered from the documentation was that generate a key pair in the keystore. you can use this to sign files (via the keystore) and also export a certificate (containing the public key) to distribute in a truststore.
What I want to do differently is have just the client authenticated. I was trying to do was
1) generate tthe key in the servers keystore
2)sign the client code with this key
3)generate a certificate using this key and store it in the servers truststore
4) have the server suthenticate the client against this truststore.
The server needs no authentication and hopefully the client should need no keystores.
Hope that makes sense :p
Sorry, you are correct, I got that back to front. The truststore contains only public keys, keystore contains both.You need to issue each client with a certificate in its keystore which is trusted by the server's truststore.
ejp at 2007-7-7 3:25:57 >
Ah I see, right I think i'm getting the hang of this now . Consequently , I have come to the conclusion that what I was attempting to do is incorrect :p
Is it possible to authenticate a client without the client having a keystore containing its private key.
What I thought I could do was
1) generate a key pair and store this on the server.
2) export the public key + certificate to the clients keystore
3) have the client send this to the server when requested for authorisation.
4)have the server authorise the client.
It seems to me that you need to send a private key certificate for comparison against the corresponding public key certificate in the truststore.
If this is the case, how would I go about authorising clients to connect to my server. My aim is to only allow clients to connect if they have been authorised by me. The clients should not have a keystore because somebody could simply write a new java client and start it up with this keystore.
The SSL handshake gives you an authenticated identity, in your case a client identity. It is up to you to decide whether that identity is authorised.
ejp at 2007-7-7 3:25:57 >
Aye, but doesn't the client need it's private key certificate in order to send it's authentication via the SSL handshake?
In this case, somebody could load up their own java client whilst using the same keystore. My server app would think this client was an authenticated.
I'm not sure how I can decide if that particular client is authorised since all I will have in my server truststore is the corresponding public key certificate.
Thanks for all the replies by the way, much appreiciated :)
Sorry, first line of previous post should say:Aye, but doesn't the client need it's public key certificate in order to send it's authentication via the SSL handshake?
Yes it does need the public version of its certificate to authenticate. However this only establishes that the client is who it says it is. You can rely on that otherwise PKI is broken (and that's another topic).
However I say again that whether your server wants to trust (i.e. authorize) that client identity is an application decision. You can get the authenticated identity from the peer certificate via SSLSocket.getSession(). Whether you trust that identity or not is up to you, and SSL doesn't try to make that decision for you.
ejp at 2007-7-7 3:25:57 >
The confusing part for me was that, if somebody runs their own "fake" client using my real clients keystore, then the server will simply see a valid certificate.
I've discovered how to send the certificates "attached" (via jarsigner) to the clients jarfile now. I will check this against the server keystore. This should mean I have to sign valid clients :)
I'll give you all those dukes for being helpful :p
