We have a ngix reverse proxy that we use to run a number of perspective sessions. Perspective sessions inside the network continue as normal.
Connection through the reverse proxy are closed, and looking at the packet capture the gateway sends the following response ' TLSv1.2 alert (level fatal description illegal parameter)'
I found references to a bugs in openSSL, but I don't think it's applicable or in use.
Is there anywhere on the gateway I can enable additional logging to capture what's causing the error or which cypher so I can disable it? The nginx proxy is managed by others, so I'm unable to review it's configuration.
Thanks
Hmm. No clues in the initial handshake from the capture?
You can add -Djavax.net.debug=all to the additional parameters section of ignition.conf and then restart the gateway. This will produce some very verbose logging that goes only to the wrapper.log files, and might help in troubleshooting.
Currently I only have a screenshot of the capture, hopefully I'll get a copy shortly.
I'll give that a try!
Thanks for the suggestion!
Thanks again Kevin.
Just as a warning to anyone else who enables debug, you may need to increase your file size maximum to capture the data you need.
During the TLS negotiation, connections traversing the reverse proxy are sending a null session id and failing with the error:
javax.net.ssl|ALL|B3|webserver-59|2023-10-26 xx:xx:xx.xxx xxx|null:-1|Can't resume, the existing session is not rejoinable
Clients on the local network have a session id present in the ClientHello.
I'm unsure if this is a new behavior from nginx or if 8.1.33 modified how it handles null session ids.
8.1.33 upgraded Java from 11 to 17, I wouldn't be surprised if there are some subtle changes in TLS behavior.
Is the connection attempt being made with TLS 1.3? AFAIK it's not valid to send a null/empty session ID in that case.
It's using TLS 1.2, the product we're using doesn't support TLS 1.3 sadly.
I'll have the team that manages the access reach out to their support.
Thanks for the help.
I missed read your reply last night, if the negotiation is using TLSv1.2, a null session ID on initial contact should be acceptable?
I think so? I’m not sure if the log statement you posted above is actually the error that terminates the connection or if it’s informational, just stating the connection can’t be resumed.
Can you share the full logs and Wireshark capture in your support ticket, and not just a snippet and a screenshot?
Alright, so I think I found your actual issue. The empty/null session id is not relevant.
Here's the real error:
| javax.net.ssl|ERROR|44|webserver-68|2023-10-26 18:44:00.218 CDT|null:-1|Fatal (ILLEGAL_PARAMETER): Illegal server name, type=host_name(0), name=redacted:8043, value={6361722D6F747369706730332E386176652D6F742E636F6D3A38303433} (
| "throwable" : {
| javax.net.ssl.SSLProtocolException: Illegal server name, type=host_name(0), name=redacted:8043, value={6361722D6F747369706730332E386176652D6F742E636F6D3A38303433}
| at java.base/sun.security.ssl.ServerNameExtension$CHServerNamesSpec.<init>(Unknown Source)
| at java.base/sun.security.ssl.ServerNameExtension$CHServerNamesStringizer.toString(Unknown Source)
| at java.base/sun.security.ssl.SSLExtension.toString(Unknown Source)
| at java.base/sun.security.ssl.SSLExtensions.toString(Unknown Source)
| at java.base/sun.security.ssl.ClientHello$ClientHelloMessage.toString(Unknown Source)
| at java.base/sun.security.ssl.SSLLogger$SSLSimpleFormatter.formatObject(Unknown Source)
| at java.base/sun.security.ssl.SSLLogger$SSLSimpleFormatter.formatParameters(Unknown Source)
| at java.base/sun.security.ssl.SSLLogger.log(Unknown Source)
| at java.base/sun.security.ssl.SSLLogger.fine(Unknown Source)
| at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown Source)
| at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
| at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
| at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source)
| at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown Source)
| at java.base/java.security.AccessController.doPrivileged(Unknown Source)
| at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown Source)
| at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:657)
| at org.eclipse.jetty.server.HttpConnection.fillRequestBuffer(HttpConnection.java:368)
| at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:265)
| at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:314)
| at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
| at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:558)
| at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:379)
| at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:146)
| at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100)
| at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
| at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:416)
| at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:385)
| at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:272)
| at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.lambda$new$0(AdaptiveExecutionStrategy.java:140)
| at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:411)
| at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:969)
| at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1194)
| at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1149)
| at java.base/java.lang.Thread.run(Unknown Source)
| Caused by: java.lang.IllegalArgumentException: The encoded server name value is invalid
| at java.base/javax.net.ssl.SNIHostName.<init>(Unknown Source)
| ... 35 more
| Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
| at java.base/java.net.IDN.toASCIIInternal(Unknown Source)
| at java.base/java.net.IDN.toASCII(Unknown Source)
| ... 36 more}
|
| )
There seems to be some issue with the hostname (redacted:8043) or the way it's encoded... I'm not sure yet, but some validation step in the Java TLS implementation is rejecting it.
edit: oh, duh, it's a hostname, i.e. it should not include the port at the end :8043, and : is the "non-LDH" character it's probably complaining about (letters-digits-hyphen).
Thanks, we'll talk to the other vendor support. I appreciate the help!
Would you be able to hide the host-name and domain?
I personally use HAProxy instead of NGINX, but typically you have to pass the X-Forwarded headers, and could it possibly be misconfigured? Here's what it would typically look like I believe:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
Also, under the Ignition configuration for Networking/Web Server, do you have the Use Proxy Forwarded Headers checked/enabled?
Thanks Michael, it has been resolved.
If you're using Akamai EAA product, you also need to set the Internal Host property, otherwise the FQDN and port number for the application server are used as the server name.
Over the thanks giving break, just out of interest, we're going to look into the 8.1.30 server to see how JAVA is handling those requests.
1 Like