Handling TLS Exceptions?

["이희승 (Trustin Lee)"]

Hi Marc-André,

I think closing the connection immediately on SSLException is a 
reasonable behavior.  It's better to consider as a transport level 
failure like dropped connection in my opinion.  Also, SSLEngine as far 
as I know sends proper alert when a client needs to know about it.

HTH,
Trustin

Marc-André Laverdière wrote:
> Hi everyone,
>
> Every now and then, we get a TLS error due to invalid padding. The
> current processing logic is to only ignore the exception. So what ends
> up happening is that the connection is eventually disconnecting after
> a timeout is reached.
>
> I would like to know if there is any better/cleaner way to do this in
> Netty. Should I just close the connection right away? Is there any way
> to send a TLS alert? Or ask for a re-handshake?
>
> There is exception we get.
>
> javax.net.ssl.SSLHandshakeException: Invalid padding
>
> 	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1490)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:924)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:837)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:713)
> ~[na:1.6]
>
> 	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607) ~[na:1.6]
>
> 	at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:868)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:605)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at myhandler.messageReceived(LoadMonitoringHandler.java:121) ~[classes/:na]
>
> 	at org.jboss.netty.handler.logging.LoggingHandler.handleUpstream(LoggingHandler.java:231)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:90)
> ~[netty-3.2.4.Final.jar:na]
>
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> [na:1.6.0_25]
>
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> [na:1.6.0_25]
>
> 	at java.lang.Thread.run(Thread.java:662) [na:1.6.0_25]
>
> Caused by: javax.crypto.BadPaddingException: Invalid TLS padding: 5
>
> 	at com.sun.net.ssl.internal.ssl.CipherBox.removePadding(CipherBox.java:406)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.CipherBox.decrypt(CipherBox.java:247) ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.InputRecord.decrypt(InputRecord.java:153)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:238)
> ~[na:1.6]
>
> 	at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:906)
> ~[na:1.6]

-- 
Trustin Lee, http://gleamynode.net/