Wrong SNI when using a socks proxy

[herste]

Describe the bug
Whenever a proxy is used, the proxy hostname is used in the TLS handshake server_name extension (SNI). This leads to problems in various TLS contexts

To Reproduce
start a initiator session at least with the following settings active:
SocketConnectHost=[your-connect-host]
ProxyType=socks
ProxyVersion=5
ProxyHost=[your-socks-proxy-host]
ProxyPort=[your-proxy-port]

whenever you are connecting, [your-socks-proxy-host] is now set as SNI which is wrong.

Expected behavior
the expected result is that [your-connect-host] is used as SNI in the TLS handshake packet. if multiple connect hosts are given, the appropriate host that is currently connected to is to be set.

system information:

• OS: Linux
• Java version: Temurin-17.0.15+6
• QFJ Version 2.3.1 and 2.3.2

Additional context
2.3.2 has removed the option to enable/disable SNI. Seems that it is now always on which also might break connections where now a SNI is implicitely set .

[herste]

... assumption is that session.getRemoteAddress() in SSLFilter.java:73 always returns the address where mina will open the network connection to which - in case of a socks proxy - will be the proxy address.
But this is just a very wild guess as I am completely unfamiliar with the code and libraries used.

[chrjohn]

@the-thing are you able to give me a hand with this? Thank you :)

[the-thing]

@chrjohn @herste

To disable SNI it is enough to remove EndpointIdentificationAlgorithm configuration property, but enabling it and connecting via proxy will probably cause problems.

Looking at 3.0.0 QuickFIXj milestone branch and the MINA 2.2.4 version there is no concept of PEER_HOST anymore so adding the flag back to enable / disable SNI will help. I will have to look at org.apache.mina.filter.ssl.SslFilter#createEngine as well.

I think the bigger problem is that SNI support in QuickFIXj is not feature complete. There is no way to provide javax.net.ssl.SSLParameters#setServerNames, because MINA does not support it.

@herste

Could you please provide your handshake messages censoring any sensitive data where required? I don't think you will be able to see SNI extension - server_name in TLS handshake, because SNI hostnames are never set.

[herste]

hello @the-thing

as per my tests with 2.3.2, server_name is always set. EndpointIdentificationAlgorithm should - at least to my understanding - not relate to SNI at all. This option configures the validation of the server certificate received back which does not necessarily needs to match the SNI (e.g. wildcard, SAN, etc).

Please find attached the tests having openssl s_server running on the receiver side so we can see a good trace of the TLS handshake. Also the quickfix config that was used is attached (named .log to be able to upload).

server.log

qf.config.log

[herste]

Taking a look at a mina test might help, they seem to use a CustomSslFilter to inject the appropriate values. See https://github.com/apache/mina/blob/2.2.4/mina-core/src/test/java/org/apache/mina/filter/ssl/SslIdentificationAlgorithmTest.java

[the-thing]

EndpointIdentificationAlgorithm should - at least to my understanding - not relate to SNI at all.

I assumed it is for both. Test cases that I wrote some time ago to test some scenarios with specially crafted certificates (but no proxy).

quickfix.mina.ssl.SSLCertificateTest#shouldAuthenticateServerNameUsingServerCommonName
quickfix.mina.ssl.SSLCertificateTest#shouldAuthenticateServerNameUsingSNIExtension
quickfix.mina.ssl.SSLCertificateTest#shouldFailWhenHostnameDoesNotMatchServerName

I will have a look at tests as soon as I can. This weekend or sometime next week.

server.log

Interesting. I was wiresharking SSL tests scenarios mentioned and I didn't see it.

Taking a look at a mina test might help, they seem to use a CustomSslFilter to inject the appropriate values. See https://github.com/apache/mina/blob/2.2.4/mina-core/src/test/java/org/apache/mina/filter/ssl/SslIdentificationAlgorithmTest.java

I wrote it, but Emmanuel manually cherry pics with him as author :)

https://github.com/apache/mina/pull/26/files

There were some updates that use SNINames which probably can be done via injection via custom filter or javax.net.ssl.SSLParameters#setServerNames

[the-thing]

@herste

I did some testing and now I understand why it wasn't working for me. "localhost" is never passed in SNI extension, but anything that is a valid DNS is. I configured a local DNS and it worked.

avax.net.ssl|FINE|1C|ssl-exec-0|2025-09-14 13:14:14.845 CEST|ClientHello.java:668|Consuming ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "59 3D D5 8C F6 1B 35 94 BF 21 AC 31 F6 B1 2C 4D C9 23 3A 15 4C 61 56 52 D5 EE 3D B7 65 11 98 9F",
  "session id"          : "63 FC 4C 6F 0D 86 20 28 4D E6 2B FF 44 82 1D AE 9D 00 70 BF 6E 70 15 E3 23 02 B9 BA AD 33 3E E8",
  "cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302)]",
  "compression methods" : "00",
  "extensions"          : [
    "server_name (0)": {
      type=host_name (0), value=abc.foo.bar
    },

Moreover the same effect can be achieved by providing server names explicitly - more than one server name for each type. It also allows to provide SNI that is different than destination.

sslParameters.setServerNames(Arrays.asList(new SNIHostName("foo")));

SocketConnectHost: localhost
Server Name: foo

"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "AB B3 A4 3B 93 CD 2A C2 26 E4 0B 07 2B 6D 4A 5B 36 CA 79 01 9A D0 AB 07 22 45 35 4C 64 6A B5 B1",
  "session id"          : "23 EE BF 05 D3 E8 2F B8 D1 02 DB 6E BB CF 3B AB 15 3B AC 03 A4 41 5C C4 D4 AE 84 8F EB 89 8C CC",
  "cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302)]",
  "compression methods" : "00",
  "extensions"          : [
    "server_name (0)": {
      type=host_name (0), value=foo
    },

I have a feeling that the fix for this would be to bring in a custom SSL filter for the initiator with the flag UseSNI (not really required as it is set anyway). When enabled, it would take the hostname from SocketConnectHost and set it as the SNI hostname parameter (not necessarily fiddle with the remote address in the Mina SSLFilter).

I'm not sure if there is a need to add an extra QuickFIX/j setting to be used as an SNIHostName?

Also, for SNI to work, the acceptor/server needs to have some SNI matchers configured — otherwise, to my understanding, this extension will be ignored. QuickFIX/j doesn't allow SNI matchers to be set easily. Does that mean the server you are connecting to possibly uses a different engine than QuickFIX and already has these matchers configured, or that the SNI matchers are somehow injected into the JVM?

[herste]

I do not have the acceptor side using QuickFIX/J - it is a custom load balancer that offloads TLS. I just focused on the initiator.

Furthermore, I would strongly recommend to have an optional setting to override the SNI hostname as this is very useful if the acceptor is using a load balancer in Kubernetes or OpenShift environments to route traffic using SNI. Default should obviously always be SocketConnectHost or the appropriate SocketConnectoHost if multiple hosts are being used.

For compatibility purposes to earlier versions, UseSNI can of course be helpful to turn off SNI at all if thats possible code-wise.

[the-thing]

Thanks for the suggestions. Makes sense.

• "SNIHostName" - it seems that it will be useful, but you can't have more than one SNIServerName of the same type (SNIHostName with type 0 is the only used atm).

• "UseSNI". Not sure about this one as you can't really turn it off. If set to 'N' then we do not set anything explicitly, which means it will be set to SocketConnectHost value (after applying proxy fix mentioned that currently doesn't work). So Y / N doesn't really make a difference unless we want to keep the proxy bug.

I will prototype something probably tomorrow.