avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish <paliwalash...@gmail.com>
Subject Re: AVRO and SSL/TLS IPC calls
Date Fri, 18 Oct 2013 11:28:21 GMT
I faced this issue while I was writing tests for HTTPS source. Can't recall
the details, but if you can look into the Test case it might help

https://github.com/apache/flume/blob/trunk/flume-ng-core/src/test/java/org/apache/flume/source/http/TestHTTPSource.javalook
into
testHttps()

If time permits, I shall give a shot at the code. Can also debug using
-Djavax.net.debug=ssl
or -Djavax.net.debug=all


On Fri, Oct 18, 2013 at 12:12 AM, Dr. Pala <mpala@datafascia.com> wrote:

>  Hi Connor, all,
>
> thanks for your reply. However, I am trying to use the Netty protocol +
> enforcing mutual authentication under TLS v1.2. I am almost there... but I
> am stuck with an error that is difficult to debug and maybe, guys, you have
> some more insights.
>
> Following this example:
>
>    -
>    http://svn.apache.org/repos/asf/avro/trunk/lang/java/ipc/src/test/java/org/apache/avro/ipc/TestNettyServerWithSSL.java
>
> I am trying to build a small toolkit that will make secure communication
> between the requestor and the responder easy to deploy. For doing that, I
> have some working code that initializes a keystore and uses that for the
> source of trust, here's part of the code:
>
>     // Instantiates a new responder
>     Responder responder = new SpecificResponder(m_protoClass, m_protoHandler);
>
>     // Gets a new Channel Factory
>     ChannelFactory channelFactory = new NioServerSocketChannelFactory(Executors.newCachedThreadPool(),
Executors.newCachedThreadPool());
>     // Gets the responder
>     //
>     // NOTE:
>     //
>     // The m_trustManager is a helper class that extends NioClientSocketChannelFactory
and
>     // implements X509TrustManager, ChannelPipelineFactory, ChannelFactory
>
>     m_server = new NettyServer(responder, new InetSocketAddress(m_host, m_port),
>         channelFactory, (ChannelPipelineFactory) m_trustManager, null);
>
>
> Internally the TrustManager implements the "*public ChannelPipeline
> getPipeline()*" method as follows:
>
>     // We need to get the pipeline
>     ChannelPipeline pipeline = Channels.pipeline();
> 		
>     // Set up key manager factory to use our key store
>     String algor = Security.getProperty("ssl.KeyManagerFactory.algorithm");
>     if (algor == null) algor = "SunX509";
> 		
>     KeyManagerFactory kmf = KeyManagerFactory.getInstance(algor);
>     kmf.init(m_keyStore, null);
>
>     // Now let's instantiate a new SSLContext and initialize it with the
>     // initialized KeyManagers
>     SSLContext serverContext = SSLContext.getInstance("TLSv1.2");
>     serverContext.init(kmf.getKeyManagers(), null, null);
>
>     // Let's create an SSLContext from which we will derive the SSLEngine
>     SSLEngine sslEngine = serverContext.createSSLEngine();
>
>     // DEBUGGING code that prints out the supported and enabled Ciphersuites
>     System.out.println("TrustManager::SERVER Mode::Supported Ciphersuites:");
>     String[] sCipher = sslEngine.getSupportedCipherSuites();
>     for (int i = 0; i < sCipher.length; i++)
>     {
>        System.out.println("- " + sCipher[i]);
>     }
>     String[] eCipher = sslEngine.getEnabledCipherSuites();
>     System.out.println("TrustManager::SERVER Mode::Enabled Ciphersuites:: ");
>     for (int i = 0; i < eCipher.length; i++)
>     {
>       System.out.println("- " + eCipher[i]);
>     }
> 		
>     // Set Client / Server Mode. This is needed by the application to send
>     // the right messages
>     sslEngine.setUseClientMode(false);
> 		
>     // Adds a new SslHandler that uses the instantiated SSLEngine to the pipeline
>     pipeline.addLast("ssl", new SslHandler(sslEngine));
> 		
>     // Return the pipeline
>     return pipeline;
>
>
> everything seems to be working fine, until the client tries to connect to
> the server - at that point, the server replies that there are no common
> ciphersuites with the client and exists. I also tried to connect with
> OpenSSL, but I get the same type of error from the server.
>
> There is definitely something I am forgetting in the initialization of the
> server, probably, but I can't find what. Here's the trace:
>
> 607 [pool-5-thread-1] INFO org.apache.avro.ipc.NettyServer - [id: 0x21c61075, /127.0.0.1:47913
=> /127.0.0.1:65000] OPEN
> 608 [pool-6-thread-1] INFO org.apache.avro.ipc.NettyServer - [id: 0x21c61075, /127.0.0.1:47913
=> /127.0.0.1:65000] BOUND: /127.0.0.1:65000
> 608 [pool-6-thread-1] INFO org.apache.avro.ipc.NettyServer - [id: 0x21c61075, /127.0.0.1:47913
=> /127.0.0.1:65000] CONNECTED: /127.0.0.1:47913
> 631 [pool-6-thread-1] WARN org.apache.avro.ipc.NettyServer - Unexpected exception from
downstream.*javax.net.ssl.SSLHandshakeException: no cipher suites in common*
> 	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1362)
> 	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:513)
> 	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:793)
> 	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:761)
> 	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> 	at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:938)
> 	at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:656)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:286)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:208)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:94)
> 	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:364)
> 	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:238)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:38)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:724)*Caused by: javax.net.ssl.SSLHandshakeException:
no cipher suites in common*
> 	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> 	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1630)
> 	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:278)
> 	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:266)
> 	at sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:894)
> 	at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:622)
> 	at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:167)
> 	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
> 	at sun.security.ssl.Handshaker$1.run(Handshaker.java:808)
> 	at sun.security.ssl.Handshaker$1.run(Handshaker.java:806)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1299)
> 	at org.jboss.netty.handler.ssl.SslHandler$3.run(SslHandler.java:1067)
> 	at org.jboss.netty.handler.ssl.ImmediateExecutor.execute(ImmediateExecutor.java:31)
> 	at org.jboss.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1064)
> 	at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:954)
> 	... 12 more
> Exception in thread "main" org.apache.avro.AvroRemoteException: javax.net.ssl.SSLException:
Received fatal alert: handshake_failure
> 	at org.apache.avro.ipc.specific.SpecificRequestor.invoke(SpecificRequestor.java:104)
> 	at com.sun.proxy.$Proxy5.send(Unknown Source)
> 	at org.datafascia.tests.testIPC.main(testIPC.java:153)*Caused by: javax.net.ssl.SSLException:
Received fatal alert: handshake_failure*
> 	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
> 	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1630)
> 	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1598)
> 	at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1767)
> 	at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1063)
> 	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:887)
> 	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:761)
> 	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> 	at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:938)
> 	at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:656)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:286)
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:208)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:94)
> 	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:364)
> 	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:238)
> 	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:38)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:724)
> 635 [pool-6-thread-1] INFO org.apache.avro.ipc.NettyServer - [id: 0x21c61075, /127.0.0.1:47913
:> /127.0.0.1:65000] DISCONNECTED
> 636 [pool-6-thread-1] INFO org.apache.avro.ipc.NettyServer - [id: 0x21c61075, /127.0.0.1:47913
:> /127.0.0.1:65000] UNBOUND
> 636 [pool-6-thread-1] INFO org.apache.avro.ipc.NettyServer - [id: 0x21c61075, /127.0.0.1:47913
:> /127.0.0.1:65000] CLOSED
> 637 [pool-6-thread-1] INFO org.apache.avro.ipc.NettyServer - Connection to /127.0.0.1:47913
disconnected.
>
>
> Another question is: shall I use external libs (eg., BouncyCastle) to
> enable real TLS support ?
>
> Cheers,
> Max
>
>
> On 09/26/2013 08:17 AM, Connor Doyle wrote:
>
> Hi Max,
>
> I did something similar recently to handle RPC calls from Node.js to our Scala services.
>
> We use a WebSocket connection over SSL/TLS.  This reduces the overhead associated with
handling a bunch of HTTP headers for every request.  Each connection begins with the client-server
handshake as described in the spec.
>
> To allow responses to flow back to each client in the order they complete, the client
writes a sequence number in the metadata for each request.  The server writes this same sequence
number into the metadata for the corresponding response.  This requires both endpoints to
keep a little more state around.
>
> --
> Connor
>
>
>
> --
> Best Regards,
> Dr. Massimiliano Pala
> Senior Security Research Scientist
> DataFASCIA
>
>


-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal

Mime
View raw message