javax.net.ssl, https clients and close_notify

Question

Simple Netty implementation of https server utilizing javax.net.ssl, with a self-signed certificate. Server is up, and then a request is made using DHC by Restlet. On the server side I get:

io.netty.handler.ssl.SslHandler setHandshakeFailure WARNING: SSLEngine.closeInbound() raised an exception due to closed connection. javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack? at sun.security.ssl.Alerts.getSSLException(Unknown Source) at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source) at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source) at sun.security.ssl.SSLEngineImpl.closeInbound(Unknown Source) at io.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:905) at io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:576) at io.netty.channel.DefaultChannelHandlerContext.invokeChannelInactive(DefaultChannelHandlerContext.java:819) at io.netty.channel.DefaultChannelHandlerContext.access$1300(DefaultChannelHandlerContext.java:38) at io.netty.channel.DefaultChannelHandlerContext$5.run(DefaultChannelHandlerContext.java:808) at io.netty.channel.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:259) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:305) at io.netty.channel.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:110) at java.lang.Thread.run(Unknown Source)

And on the client side:

No response. Is the certificate valid? Click here to check.

Issuing the same request at Chrome's address bar, the same server-side exception. Issuing the same at Firefox's address bar, the same exception while Firefox is displaying its warning page about the certificate not being from a trusted CA. This exception seems very generic and not directly indicating what the state of the protocol is. Does it mean these 3 clients (Chrome, Firefox, DHC by Restlet), are not playing the protocol nicely and just disappearing on the server rather than sending a close_notify? or is that a client-side behavior mandated by SSL RFC's or just a security oriented client-side design?

Zipah

Seems all clients I tried just skip sending a close_notify. Perhaps it's good for the client to just drop out immediately, though leaving the server a bit puzzled as to what may be the detailed reason... – Zipah

Hi Matt. I am making https request from Dev HTTP Client and having the same situation on the client side. How did you manage it? – Manhattan

@AntonioAcevedo, it seems that common clients behave in the following manner when connecting to an untrusted certificate - they close the connection and prompt the user. So all the server sees is the client disappearing on them, but the client doesn't notify the server about its reason. This makes sense security-wise from the client perspective (dispensing least amount of information upon a security issue to a 2nd party is a good practice). So this situation doesn't require 'solving' but only accepting it as a given. – Zipah

So if you wish to have more information about the specific security issue, extract more information on the client side. Or, if your goal is to 'skip' security and just 'get it to work', configure your client for looser security. – Zipah

This is with testing purposes so I think the better is to configure the client for looser security. How did you do it? Dev HTTP CLient's options doesn't seem to have any one related to this topic. – Manhattan

I don't remember already, but you can take SSL out, that should work. I guess if you insist on tweaking the SSL security level of Chrome Dev HTTP Client you can either search the project's mailing list, or configure SSL more perfectly by adding your own CA to the list of root CA's in the browser/OS and wiring the server name and the DNS settings, which sounds like potential for a lot of fun.... – Zipah

Answer 1

I have contacted with DHC by Restlet team and they have told me a workaround:

Chrome doesn't provide an API for managing certificates. In other words, we have no API to automatically accept your certificate nor a way how to raise 'untrusted certificate' dialog. But, you can use a little workaround:

1. Open the https URL in another tab.
2. Manually accept the certificate.
3. Go back to DHC and it will work because your certificate has been accepted manually (is stored in your Chrome) by the previous step.

Usually you have to do this just once.

Manhattan

Cool solution. I think it may fit as it's own 'answer your own question' as the original question here was why and whether indeed close_notify is not being sent by popular clients.... cool workaround! glad to help! – Zipah

Answer 2

I faced this issue when I was installing open JDK version of java on linux machine, when I changed the java version to Oracle JDK the issue disappeared.

The exact application that threw this exception is Information Workbench (fluid ops product) and java version was 8 Using which version of java wasn't mentiond in system prerequists by fluid ops people.

Niersteiner