Problems with SslHandler
Frederic Bregier
fredbregier at free.fr
Thu Aug 13 03:09:51 EDT 2009
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
--
View this message in context: http://n2.nabble.com/Problems-with-SslHandler-tp3420920p3435988.html
Sent from the Netty User Group mailing list archive at Nabble.com.
More information about the netty-users
mailing list