getting javax.net.ssl.SSLException: illegal change cipher spec msg, state = 6

Virat Gohil virat4lug at gmail.com
Mon Jun 22 02:32:58 EDT 2009


Hi Trustin,

Thanks for the insight into the reason(s) for the errors. I guess you might
be correct, I am closing the connections from the handler (if read timeouts
occur). That might be the cause of these exceptions, I will try to re-test
it without the timeouts.

I do observe timeouts in my logs, however I am yet to figure out as to why
these timeouts occur in the first place. My clients are configured to send a
heartbeat message every 20 seconds and ReadTimeout timer is configured to 60
seconds, so timeouts should not occur in the first place.

Will keep you updated with my investigations, meanwhile switching to the
latest Netty! :)

Thanks for the great work!

Regards,

Virat

On Thu, Jun 18, 2009 at 7:43 PM, "이희승 (Trustin Lee)" <trustin at gmail.com>wrote:

> I did some Googling and found that the exception you mentioned is raised
> here in SSLEngineImpl.java:
>
>    case Record.ct_change_cipher_spec:
>        if ((connectionState != cs_HANDSHAKE
>                    && connectionState != cs_RENEGOTIATE)
>                || inputRecord.available() != 1
>                || inputRecord.read() != 1) {
>            fatal(Alerts.alert_unexpected_message,
>                 "illegal change cipher spec msg, state = "
>                 + connectionState);
>        }
>        ...
>
> connectionState '6' means 'cs_CLOSED', which means:
>
> 1) Server closed the connection (i.e. you called Channel.close() by
> yourself),
> 2) Client closed the connection, or
> 3) SSLEngine has shut itself down due to some prior fatal error during
> communication.
>
> The case 2 cannot occur in this problem because the client cannot send
> the 'change_cipher_spec' message to the closed connection.
>
> If the case 3 is true, you should have get a prior exception. Did you?
> You might want to set a global breakpoint for 'SSLException' to make
> sure no prior exception was raised.
>
> If the case 1 is true, it means the client sent the 'change_cipher_spec'
> message while you try to close the channel, consequently initiating SSL
> closure.  Could you let me know if the exception is raised when you call
> Channel.close()?
>
> There is possibility that the SSL message has been corrupted for some
> reason, but I'm not sure this is the case considering the exception
> message you're getting is always same.
>
> HTH,
> Trustin
>
> On 2009-06-18 오후 10:06, "이희승 (Trustin Lee) wrote:
> > I tried to reproduce the problem with the following test code.  Can you
> > reproduce the problem with it?
> >
> > public class Tester {
> >
> >     public static void main(String[] args) throws IOException {
> >
> > SSLContext.setDefault(SecureChatSslContextFactory.getClientContext());
> >         Socket s =
> > SSLSocketFactory.getDefault().createSocket("127.0.0.1", 9080);
> >
> >         InputStream in = s.getInputStream();
> >         OutputStream out = s.getOutputStream();
> >
> >         byte[] msg = new byte[] { 'H','E', 'L', 'L', 'O', 0x04 };
> >
> >         for (int i = 0;; i ++) {
> >             if (i % 1000 == 0) {
> >                 System.out.println(i);
> >             }
> >             out.write(msg);
> >
> >             //for (;;) {
> >             //    int c = in.read();
> >             //    if (c == 0x04 || c < 0) {
> >             //        break;
> >             //    }
> >             //}
> >         }
> >     }
> > }
> >
> > Please note that I used the bogus context factory which is provided with
> > the Netty SecureChat example.  I'm testing against Netty trunk on
> > Windows (no access to Solaris at the moment.)
> >
> > Please feel free to modify the tester and let me know if you succeeded
> > to reproduce the problem.
> >
> > Thanks,
> > Trustin
> >
> > On 2009-06-18 오후 9:41, Virat Gohil wrote:
> >> Hi Trustin,
> >>
> >> some more information about my setup:
> >>
> >> I have about 3000 NE (Client), which connect to the server. The
> >> connections are persistent, i.e the connections are never meant to be
> >> closed. you may keep the connections open forever. and send a message
> >> from the client every 20 seconds.
> >>
> >> As soon as the client's connection is accepted (i.e TCP handshake is
> >> finished), the client will start sending the messages from its queue, on
> >> an average the queue size would be 5 messages. so you may want to
> >> replicate this behavior as well.
> >>
> >> E.g:
> >> 1. Client connects to the server.
> >> 2. Client sends Message M1, waits for the server to acknowledge the
> >> message (timeout is 5 secs).
> >> 3. if the server fails to acknowledge the message within 5 seconds, then
> >> the client re-sends the same message. Else sends the next message.
> >> 4. The acknowledgment from server to client is at application level, you
> >> may replicate by echoing the same message.
> >>
> >> I am running Sun Solaris 10, with Sun's hotspot JVM 1.5.
> >>
> >> Please let me know if you need more information on my setup.
> >>
> >> Thanks,
> >>
> >> Virat
> >>
> >> I will either find a way or make one.
> >>
> >>
> >> On Thu, Jun 18, 2009 at 6:04 PM, "이희승 (Trustin Lee)"
> >> <trustin at gmail.com <mailto:trustin at gmail.com>> wrote:
> >>
> >>     Do I need to keep handshaking making a new connection every time for
> 20
> >>     minutes, or just keep the connection open and keep sending messages?
> >>
> >>     On 2009-06-18 오후 8:45, Virat Gohil wrote:
> >>     >
> >>     > Hi All,
> >>     >
> >>     > I am getting the following exception after about 20 minutes of
> >>     running time
> >>     > using my server:
> >>     >
> >>     >  EXCEPTION: javax.net.ssl.SS
> >>     > LException: illegal change cipher spec msg, state = 6
> >>     > javax.net.ssl.SSLException: illegal change cipher spec msg, state
> = 6
> >>     >         at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
> >>     > Source)
> >>     >         at
> >>     com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
> >>     >         at
> >>     com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
> >>     >         at
> >>     com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(Unknown
> >>     > Source)
> >>     >         at
> >>     com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown
> >>     > Source)
> >>     >         at
> >>     com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)
> >>     >         at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
> >>     >         at
> >>     > org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:699)
> >>     >         at
> >>     > org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:445)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:244)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)
> >>     >         at
> >>     >
> org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)
> >>     >         at
> >>     >
> org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)
> >>     >         at
> >>     >
> >>
> org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)
> >>     >         at
> >>     java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> >>     > Source)
> >>     >         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> >>     > Source)
> >>     >         at java.lang.Thread.run(Unknown Source)
> >>     >
> >>     > I am attaching an example server along with this email, the
> >>     clients may send
> >>     > any random string with ascii char (0x04) as delimiter.
> >>     >
> >>     > http://n2.nabble.com/file/n3104250/NioServer.tar.bz2NioServer.tar.bz2
> >>     >
> >>     > Kindly suggest a solution or cause to this issue.
> >>     >
> >>     > Thanks,
> >>     >
> >>     > Virat
> >>
> >>
> >>     --
> >>     -- Trustin Lee, http://gleamynode.net/
> >>
> >>
> >>     _______________________________________________
> >>     netty-users mailing list
> >>     netty-users at lists.jboss.org <mailto: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
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > netty-users mailing list
> > netty-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/netty-users
>
>
> --
> -- Trustin Lee, http://gleamynode.net/
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20090622/72045f60/attachment.html 


More information about the netty-users mailing list