SSL/TLS Connectivity

Eurex requires TLS encryption on the ETI low frequency (LF) gateways. This section describes how the Handler establishes an encrypted connection, which TLS version it negotiates, and what to check when the TLS handshake fails.

Enabling Encryption

Set HandlerSettings::sslEnabled to true and connect to the encrypted Connection Gateway IP/port pair published by the exchange. The unencrypted and the encrypted gateways listen on different ports, so the setting must match the port in use.

Nothing else has to be configured: the Handler authenticates the session with the credentials of the ETI logon, so it needs no client certificate and no private key of your own.

Supported TLS Versions

The Handler does not implement TLS itself. It delegates to the OpenSSL library it is linked against and exposes no setting to select the protocol version: the highest version both that OpenSSL and the gateway support is negotiated, which is TLS 1.3 with OpenSSL 1.1.1 or later.

Important

TLS 1.3 requires OpenSSL 1.1.1 or later. The Handler throws an exception at construction when HandlerSettings::sslEnabled is true and the OpenSSL it was built against is older than that. The check is made at compile time, so it says nothing about the OpenSSL the process loads at run time.

Each distribution package is built against the system OpenSSL of its platform. Where that OpenSSL is older than 1.1.1 — as it is on CentOS 7 — the exception above makes encrypted connections unavailable altogether.

Troubleshooting the TLS Handshake

Handler::connect throws, and the log records an OpenSSL error mentioning protocol_version, wrong version number, unsupported protocol or handshake failure. Check the following:

1. The OpenSSL version. Two of them matter: the one the package was built against, which decides whether TLS 1.3 is available at all, and the one the process actually loads, which does the negotiating. openssl version reports neither — it reports the command-line tool found on PATH; inspect what the process itself links against.
2. The port. Connecting to an unencrypted gateway with HandlerSettings::sslEnabled set to true fails the handshake as well, usually as wrong version number.
3. What sits in between. A TLS-terminating proxy or firewall negotiates its own protocol version with the gateway, independently of the Handler.

Note

The mirror case of the second point is silent. With HandlerSettings::sslEnabled left false against an encrypted gateway, no TLS handshake is attempted at all, so no OpenSSL error is logged; the connection instead fails or times out later, while the session logon is being negotiated.