Problems with SslHandler

Mike McGrady mmcgrady at topiatechnology.com
Fri Aug 14 15:12:27 EDT 2009 

Trustin,

This was helpful.

I will be putting my info about my trials and tribulations (minor) in  
once I have them in a form that will be of use in the future.  Things  
are going well at this stage.

Mike

On Aug 14, 2009, at 12:03 PM, 이희승 (Trustin Lee) wrote:

> Hi Frederic,
>
> StartTLS and SSL/TLS are different from each other.  StartTLS is the
> communication pattern that secures the wire in the middle of the
> plaintext connection.  Please note that it is different from SSL/TLS,
> that secures the wire from the beginning of the connection.
>
> I updated the Javadoc to avoid misunderstanding. :)
>
> Trustin
>
> On 08/13/2009 04:09 PM, Frederic Bregier wrote:
>>
>> Hi Trustin,
>>
>> I use this thread to report what is not a problem but what was a
>> miscomprehension for me from API doc.
>>
>> The API says that:
>> - server must create a SslHandler instance with the startTLS flag  
>> set to
>> true
>> - client as opposite should do a creation with the startTLS set to  
>> false
>>
>> The chat example shows:
>>
>> SSLEngine engine;
>>
>> if (handler instanceof SecureChatClientHandler) {
>>  engine =  
>> SecureChatSslContextFactory.getClientContext().createSSLEngine();
>>  engine.setUseClientMode(true);
>> } else {
>>  engine =  
>> SecureChatSslContextFactory.getServerContext().createSSLEngine();
>>  engine.setUseClientMode(false);
>> }
>> pipeline.addLast("ssl", new SslHandler(engine));
>>
>> so I do:
>> - similar engine creation, setting setUseClientMode respectively  
>> for the
>> server and client to false and true
>> - server: new SslHandler(sslEngine, true);
>> - client: new SslHandler(sslEngine, false);
>>
>> Then the sslHandler was buggy in the way that after the handshake,  
>> the
>> server will not send any encoded data, but directly data (contrary to
>> client) thus leading to errors.
>>
>> Since in the Chat example the SslHandler was not defined using the  
>> true or
>> false, I remove it and then it works like a charm. I did not test  
>> to not set
>> the setUseClientMode, but perhaps those booleans are contrary to  
>> each other
>> ?
>>
>> Cheers,
>> Frederic
>>
>>
>> Trustin Lee wrote:
>>>
>>> What changes did you make to fix the problem?  I'd like to see the
>>> 'before & after' code so that what user behavior triggers such a
>>> problem.  Then I can make SslHandler more robust to user errors.
>>>
>>> Thanks in advance,
>>> Trustin
>>>
>>> On 08/13/2009 02:44 AM, Michael McGrady wrote:
>>>> Thank you for answering so quick.  I have solved the problem and  
>>>> like
>>>> in the old Pogo cartoons, the problem is me.  I was having client
>>>> channels stomp all over each other.  Part of my learning process.
>>>>
>>>> Mike
>>>>
>>>> On Aug 11, 2009, at 7:40 PM, 이희승 (Trustin Lee) wrote:
>>>>
>>>>> Hi Mike,
>>>>>
>>>>> It's very difficult to track down this issue without a  
>>>>> reproduceable
>>>>> test application.  Would you mind if you could provide a simple
>>>>> client /
>>>>> server that reproduces the problem?
>>>>>
>>>>> Thanks,
>>>>> Trustin
>>>>>
>>>>> On 08/11/2009 09:32 AM, Mike McGrady wrote:
>>>>>> I worked with SslHandler for days with no problem then suddenly  
>>>>>> have
>>>>>> this problem on an intermittant basis.  I noticed it used to be
>>>>>> present
>>>>>> but had been fixed.  I am using netty-3.1.0.GA.  The result is
>>>>>> extremely
>>>>>> unpredicatable but always starts immediately rather than along  
>>>>>> the
>>>>>> way
>>>>>> on a chunked handler.
>>>>>>
>>>>>> MG
>>>>>>
>>>>>>
>>>>>> Mike McGrady
>>>>>> Principal Investigator AF081-028 AFRL SBIR
>>>>>> Senior Engineer
>>>>>> Topia Technology, Inc.
>>>>>> 1.253.720.3365
>>>>>> mmcgrady at topiatechnology.com  
>>>>>> <mailto:mmcgrady at topiatechnology.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> SslHandler messageReceived: UpstreamMessageEvent message:
>>>>>> BigEndianHeapChannelBuffer: BigEndianHeapChannelBuffer(ridx=0,
>>>>>> widx=100,
>>>>>> cap=1024)
>>>>>> SSL SslHandler unwrap: BigEndianHeapChannelBuffer(ridx=0,  
>>>>>> widx=100,
>>>>>> cap=1024)
>>>>>> SSL SslHandler wrap non app datajava.nio.HeapByteBuffer[pos=0
>>>>>> lim=17689
>>>>>> cap=17689]
>>>>>> SslHandler messageReceived: UpstreamMessageEvent message:
>>>>>> BigEndianHeapChannelBuffer: BigEndianHeapChannelBuffer(ridx=0,
>>>>>> widx=43,
>>>>>> cap=1024)
>>>>>> SSL SslHandler unwrap: BigEndianHeapChannelBuffer(ridx=0,  
>>>>>> widx=43,
>>>>>> cap=1024)
>>>>>> SslHandler exceptionCaught
>>>>>> SslHandler messageReceived: UpstreamMessageEvent message:
>>>>>> BigEndianHeapChannelBuffer: BigEndianHeapChannelBuffer(ridx=0,
>>>>>> widx=75,
>>>>>> cap=960)
>>>>>> SSL SslHandler unwrap: BigEndianHeapChannelBuffer(ridx=0,  
>>>>>> widx=75,
>>>>>> cap=960)
>>>>>> SSL SslHandler wrap non app datajava.nio.HeapByteBuffer[pos=0
>>>>>> lim=17689
>>>>>> cap=17689]
>>>>>> Aug 10, 2009 5:12:16 PM
>>>>>> com
>>>>>> .topiatechnology
>>>>>> .karma.spi.adapter.netty.handler.KarmaReceiverCodecHandler
>>>>>> WARNING: EXCEPTION, please implement
>>>>>> com
>>>>>> .topiatechnology
>>>>>> .karma
>>>>>> .spi
>>>>>> .adapter 
>>>>>> .netty.handler.KarmaReceiverCodecHandler.exceptionCaught()
>>>>>> for proper handling.
>>>>>> javax.net.ssl.SSLException: Algorithm missing:
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .net
>>>>>> .ssl
>>>>>> .internal 
>>>>>> .ssl.SSLEngineImpl.changeReadCiphers(SSLEngineImpl.java:526)
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .net 
>>>>>> .ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:
>>>>>> 981)
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .net
>>>>>> .ssl 
>>>>>> .internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:787)
>>>>>> at
>>>>>> com
>>>>>> .sun 
>>>>>> .net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:
>>>>>> 663)
>>>>>> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:566)
>>>>>> at  
>>>>>> org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java: 
>>>>>> 759)
>>>>>> at  
>>>>>> org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java: 
>>>>>> 485)
>>>>>> at
>>>>>> org
>>>>>> .jboss
>>>>>> .netty
>>>>>> .handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java: 
>>>>>> 292)
>>>>>> at
>>>>>> org
>>>>>> .jboss
>>>>>> .netty
>>>>>> .handler 
>>>>>> .codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:
>>>>>> 226)
>>>>>> at
>>>>>> org 
>>>>>> .jboss.netty.channel.Channels.fireMessageReceived(Channels.java:
>>>>>> 342)
>>>>>> at
>>>>>> org 
>>>>>> .jboss.netty.channel.Channels.fireMessageReceived(Channels.java:
>>>>>> 329)
>>>>>> at  
>>>>>> org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:
>>>>>> 330)
>>>>>> at
>>>>>> org
>>>>>> .jboss
>>>>>> .netty
>>>>>> .channel 
>>>>>> .socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282)
>>>>>> at  
>>>>>> org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:
>>>>>> 203)
>>>>>> at
>>>>>> org
>>>>>> .jboss
>>>>>> .netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java: 
>>>>>> 53)
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor
>>>>>> $Worker.runTask(ThreadPoolExecutor.java:651)
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor
>>>>>> $Worker.run(ThreadPoolExecutor.java:676)
>>>>>> at java.lang.Thread.run(Thread.java:613)
>>>>>> Caused by: java.security.NoSuchAlgorithmException: Could not  
>>>>>> create
>>>>>> cipher RC4/128
>>>>>> at
>>>>>> com 
>>>>>> .sun.net.ssl.internal.ssl.CipherBox.newCipherBox(CipherBox.java:
>>>>>> 124)
>>>>>> at
>>>>>> com.sun.net.ssl.internal.ssl.CipherSuite
>>>>>> $BulkCipher.newCipher(CipherSuite.java:443)
>>>>>> at
>>>>>> com
>>>>>> .sun 
>>>>>> .net.ssl.internal.ssl.Handshaker.newReadCipher(Handshaker.java:
>>>>>> 335)
>>>>>> at
>>>>>> com
>>>>>> .sun
>>>>>> .net
>>>>>> .ssl
>>>>>> .internal 
>>>>>> .ssl.SSLEngineImpl.changeReadCiphers(SSLEngineImpl.java:522)
>>>>>> ... 17 more
>>>>>> Caused by: java.lang.IllegalArgumentException: Missing argument
>>>>>> at javax.crypto.spec.SecretKeySpec.<init>(DashoA12275)
>>>>>> at  
>>>>>> com.sun.net.ssl.internal.ssl.CipherBox.initCipher(CipherBox.java:
>>>>>> 144)
>>>>>> at
>>>>>> com 
>>>>>> .sun.net.ssl.internal.ssl.CipherBox.newCipherBox(CipherBox.java:
>>>>>> 119)
>>>>>> ... 20 more
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> netty-users mailing list
>>>>>> netty-users at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>
>>>>> _______________________________________________
>>>>> netty-users mailing list
>>>>> netty-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>
>>>> Mike McGrady
>>>> Principal Investigator AF081-028 AFRL SBIR
>>>> Senior Engineer
>>>> Topia Technology, Inc
>>>> 1.253.720.3365
>>>> mmcgrady at topiatechnology.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netty-users mailing list
>>>> netty-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>
>>>
>>
>>
>> -----
>> Hardware/Software Architect
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgrady at topiatechnology.com

More information about the netty-users mailing list