Encrypted Alert message

8,557 views
Skip to first unread message

Jeffrey Argo

unread,
Feb 24, 2014, 11:16:36 AM2/24/14
to google-we...@googlegroups.com
HI,

I am working on an application that is deployed on Tomcat 7.0 and when I make a RPC call from the client to the server after 1 minute the connection is reset, because of an Alert Encrypted message from the server.  The alert message type is a 21, which means that the connection should be reset.  I have read some articles that say this message is due to an encryption error and others say that it could just be part of the SSL./TLS handshake protocol.  My question is does anyone know if this is part of the handshake process or not.  The other question is does anyone know how I can make the RPC connection ignore this alert and continue to wait for the RPC process to end normally.  Thank you in advance for any help you can provide, because this is driving me crazy and causing problems.

Jens

unread,
Feb 24, 2014, 12:24:46 PM2/24/14
to google-we...@googlegroups.com
TLS defines the alert protocol and alert code 21 means "Decryption failed", see: http://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol

Quoting wikipedia: 

"This record should normally not be sent during normal handshaking or application exchanges. However, this message can be sent at any time during the handshake and up to the closure of the session. If this is used to signal a fatal error, the session will be closed immediately after sending this record, so this record is used to give a reason for this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs (before doing so, the remote may also send its own signal)."

So it can happen at any time. I guess you have to check log files (maybe increase log level) and maybe its worth a try to check if other TLS alerts are send before code 21 occurs. Might gives you hints about whats going wrong.

From a GWT point of view you can not do anything about it. You can only create a new connection to the server but that does not solve your problem.

-- J.

Jeffrey Argo

unread,
Feb 24, 2014, 1:16:52 PM2/24/14
to google-we...@googlegroups.com
Thanks for your answer Jens, I am new to GWT so I don't know if my next question is doable or not.  From logs I can see that the service is still running on the server after I get the alert message. So when I detect this error can I go back and restart another callback that will wait again for the original RPC to finish. If this is possible can you give me a high level idea on how it would be done.  Thanks for your help.

Michael Joyner

unread,
Feb 24, 2014, 1:19:38 PM2/24/14
to google-we...@googlegroups.com
On 02/24/2014 01:16 PM, Jeffrey Argo wrote:
> Thanks for your answer Jens, I am new to GWT so I don't know if my
> next question is doable or not. From logs I can see that the service
> is still running on the server after I get the alert message. So when
> I detect this error can I go back and restart another callback that
> will wait again for the original RPC to finish. If this is possible
> can you give me a high level idea on how it would be done. Thanks for
> your help.
>

Just to jump into the middle here... are you proxying through Apache? If
yes, you might need to increase timeout in the proxy settings.

Jens

unread,
Feb 24, 2014, 2:25:11 PM2/24/14
to google-we...@googlegroups.com
Thanks for your answer Jens, I am new to GWT so I don't know if my next question is doable or not.  From logs I can see that the service is still running on the server after I get the alert message. So when I detect this error can I go back and restart another callback that will wait again for the original RPC to finish. If this is possible can you give me a high level idea on how it would be done.  Thanks for your help.

That will only work if your server processes your requests asynchronously and immediately hands out a taskId to the client on the first request. Then the client can regularly check if a given task (identified by a taskId) on a server is already done or not.

BUT you should really fix your configuration error instead of changing your server implementation unless you want the above behavior anyways. 

If your problem always occurs after 1 minute then it is most likely that you hit some kind of a timeout that you can probably configure to your needs. 

-- J.
Reply all
Reply to author
Forward
0 new messages