0

We have an application lets say A (written in Java + GWT) deployed on server box "X" From application A lets say we load some reports located on server box "Y"

The flow of the every incoming request is something like below

web user(client) -> apache -> jboss(application A is deployed here on server X) -> server box Y from where reports are being pulled.

Once the request comes to apache then session inactivity timeout is set to 30 minutes.

When a request is being made from jboss(server X) -> server Y to pull reports, we have made sure to timeout that request after 25 minutes, so that this will prevent the apache from showing a 503 when the server Y takes too long to respond.

Even after that its getting timed out after 20 minutes. Probable reason could be firefox browser may have its own timeout of 20 minutes for any request to handle.

Some of the code snippet for reference

HttpClient httpclient = HttpClientBuilder.create().setDefaultRequestConfig(getRequestConfig()).setRedirectStrategy(new LaxRedirectStrategy()).setSSLSocketFactory(getSSLContext()).build();

HttpClientContext context = HttpClientContext.create(); 

HttpPost httppost = new HttpPost(urlString); // urlString is reports server url

HttpResponse httpResponse = httpclient.execute(httppost, context);

Now to fix firefox browser issue, we thought of changing existing RequestConfig from

private RequestConfig getRequestConfig() {
        return RequestConfig.custom().setSocketTimeout(REPORT_SERVER_READ_TIMEOUT_IN_SECONDS * 1000).build();
    }

to 

private RequestConfig getRequestConfig() {
        return RequestConfig.custom().setConnectTimeout(REPORT_SERVER_READ_TIMEOUT_IN_SECONDS * 1000).setSocketTimeout(REPORT_SERVER_READ_TIMEOUT_IN_SECONDS * 1000).build();
    }

REPORT_SERVER_READ_TIMEOUT_IN_SECONDS is set to 1100 seconds.

With this change it times out after 1100 seconds, but we see an error message on browser as

"The connection to the server was reset while the page was loading"

On server log we see error-log as

Exception: : java.io.IOException: Internal TLS error, this could be an attack
        at org.bouncycastle.crypto.tls.TlsProtocol.failWithError(Unknown Source) [:1.57.0]
        at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source) [:1.57.0]
        at org.bouncycastle.crypto.tls.TlsProtocol.readApplicationData(Unknown Source) [:1.57.0]
        at org.bouncycastle.crypto.tls.TlsInputStream.read(Unknown Source) [:1.57.0]
        at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:136) [:4.0.1]
        at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:152) [:4.0.1]
        at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:270) [:4.0.1]
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) [:4.3.6]
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) [:4.3.6]
        at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260) [:4.0.1]
        at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:161) [:4.3.3]
        at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:153) [:4.3.6]
        at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271) [:4.0.1]
        at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123) [:4.0.1]
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254) [:4.3.6]
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) [:4.3.6]
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) [:4.3.6]
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) [:4.3.6]
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) [:4.3.6]
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) [:4.3.6]
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) [:4.3.6]

Anyone has any idea about fixing browser specific timeout?

while creating HttpClient I set setSSLSocketFactory. The way I set it like below: 

private SSLConnectionSocketFactory getSSLContext() throws Exception {
    return new SSLConnectionSocketFactory(new TLSSocketConnectionFactory(), new String[] { "TLSv1.2" }, null, SSLConnectionSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
}

When I looked at SSLConnectionSocketFactory

public SSLConnectionSocketFactory(SSLSocketFactory socketfactory, String supportedProtocols[], String supportedCipherSuites[], X509HostnameVerifier hostnameVerifier)
    {
        this.socketfactory = (SSLSocketFactory)Args.notNull(socketfactory, "SSL socket factory");
        this.supportedProtocols = supportedProtocols;
        this.supportedCipherSuites = supportedCipherSuites;
        this.hostnameVerifier = hostnameVerifier == null ? BROWSER_COMPATIBLE_HOSTNAME_VERIFIER : hostnameVerifier;
    }

SSLSocketFactory is deprecated. Can that cause an issue?

Shivraj
  • 462
  • 2
  • 9
  • 27
  • See this [How to detect an end of stream properly when tls psk encryption isused](https://stackoverflow.com/questions/40636982/how-to-detect-an-end-of-stream-properly-when-tls-psk-encryption-is-used) it looks like the report server might be closing the connection prematurely which causes the other server to receive truncated data, e.g. no EOF. I dont think you need to worry about the browser right now, that SSL error is bad enough and no matter what you do on the browser, its not going to help with the true problem which is the inter server communication. – JGlass Feb 07 '18 at 17:46
  • Your socket timeout is likely causing the issue. Remove the socket timeouts and then work on the browser timeout. – JGlass Feb 07 '18 at 17:46
  • Changing browser timeout [How can i change the connection timeout setting in firefox](https://superuser.com/questions/303217/how-can-i-change-the-connection-timeout-setting-in-firefox) but this doesnt really help you, how many endd users do you have and what types of browsers are they running, you'd need to adjust all of them. IMHO, why dont you try zipping the data thats being sent? – JGlass Feb 07 '18 at 17:48
  • Hi JGlass you said "Your socket timeout is likely causing the issue. Remove the socket timeouts and then work on the browser timeout." Is there any way to work with browser timeout from Java? Also as the error is seen on client end, its not good idea to ask client to make changes to browser configuration at their end. Any alternative? – Shivraj Feb 07 '18 at 21:14
  • I think you slightly misunderstood - you definitely dont want to deal with making changes to peoples browsers - but you can if you need to but only from the browser itself, the last comment of mine. The SSL error on the server is likely because one of the servers is timing out, closing the socket which causes the SSL exception/error you see. Try and remove those timeouts for now. If everything ends up loading, even if you just have to temporarily increase the browser timeout on your own browser, then look into compressing/zip things between the server to increase speed – JGlass Feb 07 '18 at 21:35
  • The second server could then either uncompress and give to client, or give it to client as a zip – JGlass Feb 07 '18 at 21:36
  • I tried to make changes as suggested by you. but that didn't work. However I think issue is something else – Shivraj Feb 07 '18 at 23:34
  • updated my question in description. seems like an issue with SSLConnectionSocketFactory – Shivraj Feb 07 '18 at 23:37
  • Did it get rid of this error "TLS error, this could be an attack". I ask, as that error IIRC and in searching is usually caused by getting a truncated response from the other reports server, it never got the EOF, end of file marker. Thats why I believed it was being caused by the socket timeouts you set. The deprecated *shouldn't* matter at this point but it's something you want to look into. Try increasing the browser timeout to something like 1 hour temporarily and try your test again (without you setting socket timeouts). If you get an error in browser or server post it. – JGlass Feb 08 '18 at 00:04
  • You also say this "With this change it times out after 1100 seconds", thats only 18.33 minutes and you need at least 25. Another recommendation, try bypassing Apache and go directly to app server to reduce the complexity of the situation. – JGlass Feb 08 '18 at 00:08
  • Unfortunately I can't make changes to apache server timeout. please see my response in an answer below as comment can't allow more characters. – Shivraj Feb 08 '18 at 00:48
  • I'd suggest rereading my last two comments and trying things out - I didnt mention touching the apache timeout. – JGlass Feb 08 '18 at 13:35
  • I tried to set Timeout 1500 in apache httpd.conf file and it worked for me. However, the problem is it needs to be fixed for request made from jboss server X to another server Y when Y takes more time to respond. Not sure fixing it in apache is good idea. – Shivraj Feb 08 '18 at 19:06
  • So it completely worked with that, you were able to load the data in the browser with the Apache timeout change? If that is 100% the case, then you can probably switch back to this `return RequestConfig.custom().setSocketTimeout(REPORT_SERVER_READ_TIMEOUT_IN_SECONDS * 1000).build();` *but* youre going to want to try and catch the exception, if you get a socket timeout exception or the `java.io.IOException:Internal TLS error, this could be an attack` or possibly any exception, then return a response to the user web page (manually write some HTML(or something)) saying we're sorry, servers busy. – JGlass Feb 08 '18 at 19:15
  • Sure @JGlass I have added one more question, kind of extenstion to this: https://stackoverflow.com/questions/48697267/difference-between-location-and-proxy-in-httpd-apache see if you can help. – Shivraj Feb 09 '18 at 15:53

0 Answers0