3

I'm working on a Server and Client based app which require two way SSL authentication. (Client authenticates server and Server authenticate client both using SSL Certificates.)

I'm quite new to Netty and have few doubts regarding this.

  1. Is two way authentication possible using Netty?
  2. Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?
  3. If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake? And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?
  4. Are there any examples I could refer to regarding this?

I really appreciate any help regarding this, answers or a push in right direction.

Donald Duck
  • 8,409
  • 22
  • 75
  • 99
Shamal Karunarathne
  • 1,759
  • 3
  • 16
  • 24

3 Answers3

11

Is two way authentication possible using Netty?

Yes

Can it be simply achievable by adding another SslHandler to the pipelinefactories of both server and client?

Yes

If the above is true, how can I grab the required SslHandler at the ChannelConnected() method to do the SslHandshake?

You need the setup the keystore and the truststore correctly when creating your SSLContext.

And Is it possible to invoke the second handshake at the ChannelConected() method by calling the pipeline back again?

From memory, client and server authentication is done in the 1st handshake.

On the client, install the client's private key in the keystore and the server's public key in the truststore.

On the server, install the server's private key in the keystore and the client's public key in the truststore.

Are there any examples I could refer to regarding this?

  • Here's an example I did for websockets. It only shows you how to setup the server keystore. You will have to add a truststore as the 2nd parameter of serverContext.init(kmf.getKeyManagers(), null, null);

  • Here's a similar example in Scala with trust store setup.

  • Here's a good java guide on how to setup SSLContext.

Hope this helps.

Veebs
  • 2,390
  • 13
  • 10
  • 1
    You're not closing the trust store's input stream in your scala example. In addition, it's preferable to use `Key/TrustManagerFactory.getDefaultAlgorithm()` instead of forcing `SunX509`, which isn't the JSSE default for the TMF and which wouldn't work with a non Sun/Oracle-based JRE (e.g. IBM). – Bruno May 16 '12 at 00:58
3

Two way authentication requires that both server and client have certificates that the other trusts. The client needs to generate a private key, store it in his keystore, and get it signed by somebody that the server's truststore trusts.

It isn't just a matter of what code you write.

user207421
  • 305,947
  • 44
  • 307
  • 483
1

SSL is a presentation layer protocol and the SSL handshake happens right after the socket connection is established and the before the application layer gets a usable socket connection. No matter what application you are using, if you have the SSL protocol layer in place then you can work over SSL.

Two way authentication is just a matter of configuration as mentioned by @EJP above. If both the parties can establish and validate each other trust chain then the handshake succeeds. Refer the netty configuration manual for configuring SSL truststores.

Drona
  • 6,886
  • 1
  • 29
  • 35
  • The SSL handshake doesn't necessarily happen straight after the connection is established, it can happen after some plain text communication (e.g. with `STARTTLS`-like protocols or HTTP proxy `CONNECT`) or after re-negotiation (typically to get a client-cert if it isn't requested in the first handshake). – Bruno May 15 '12 at 11:51
  • @Bruno but, isnt the plain text communication part of the SSL session establishment process? – Drona May 15 '12 at 11:57
  • Not really, it's usually normal application protocol before the handshake really starts (via `Client Hello`). Often, it happens after at most of couple of application request/resp, but it could happen after a longer exchange in principle. – Bruno May 15 '12 at 12:00