TLS

Most production databases now accept encrypted client connections, and many accept nothing else. This page covers how DBVoyeur behaves when the SQL traffic it monitors is protected by TLS, and what to consider when choosing a TLS version for your database listeners.

TLS 1.3 and Informix

TLS 1.3 is supported by current Informix releases and provides improved security, faster connection establishment, and more efficient cryptographic algorithms than earlier TLS versions. Informix can be configured to support TLS 1.3 alone or to allow both TLS 1.2 and TLS 1.3, enabling clients and servers to negotiate the highest protocol version supported by both ends of the connection.

Successful use of TLS 1.3 requires support from both the Informix server and the client software. If either side does not support TLS 1.3, the connection will fall back to TLS 1.2 when permitted by the server configuration. This allows organizations to migrate to TLS 1.3 while maintaining compatibility with existing applications and client environments.

Organizations should also consider compatibility with their cryptographic libraries, operating system, and any security policies such as FIPS mode, as these may influence the protocol version that can be negotiated. When deploying TLS 1.3, it is recommended to use modern certificates and key sizes that meet current industry best practices to ensure long-term security and interoperability.

What DBVoyeur sees on an encrypted listener

DBVoyeur is a passive monitor. It does not sit in the connection path, does not terminate TLS, and does not alter a single byte between client and server — so enabling encryption never changes how your applications connect or how the database responds. What encryption does change is how much of the conversation is legible to an observer.

Practical guidance

If you are unsure which applies to your estate, the troubleshooting page covers confirming what a listener negotiates, and operations covers where DBVoyeur runs relative to the database host.

TLS 1.2 versus TLS 1.3

TLS 1.3 is a redesign of the protocol rather than an incremental revision of TLS 1.2. It simplifies the handshake, removes features that had become obsolete or unsafe, and improves security and performance together — which is unusual, since the two normally trade against each other.

Handshake

TLS 1.2 needs two network round trips before any application data can flow:

Client  ----------------------->  ClientHello
Server  <-----------------------  ServerHello + Certificate
Client  ----------------------->  Key Exchange + Finished
Server  <-----------------------  Finished
                                  application data begins

TLS 1.3 completes the same work in one:

Client  ----------------------->  ClientHello
Server  <-----------------------  ServerHello + Certificate + Finished
Client  ----------------------->  Finished
                                  application data begins

On high-latency WAN links this can halve connection setup time.

Key exchange and forward secrecy

TLS 1.2 permits several key exchange mechanisms, including RSA. Under RSA key exchange the client encrypts a secret with the server's public key and sends it, which means that if the private key is ever compromised, traffic captured earlier can potentially be decrypted retrospectively.

TLS 1.3 removes RSA key exchange entirely. Every connection uses ephemeral Diffie-Hellman — ECDHE or DHE — generating a fresh temporary key pair per session. Because those keys are discarded when the session ends, obtaining the server's certificate and key later does not unlock previously recorded traffic. That property is perfect forward secrecy, and in TLS 1.3 it is not optional.

Cipher suites

A TLS 1.2 suite name specifies key exchange, authentication, encryption and integrity all at once — for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 — which yields hundreds of permutations. TLS 1.3 negotiates key exchange separately, leaving a short list such as TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. The result is easier to implement correctly and markedly easier to configure.

Algorithms removed

TLS 1.3 drops mechanisms now regarded as obsolete or weak, leaving only authenticated encryption (AEAD) ciphers:

• RSA key exchange and static Diffie-Hellman
• DES, 3DES and RC4
• MD5, and SHA-1 for handshake integrity
• CBC-mode cipher suites
• Compression, which removes the CRIME attack entirely
• Renegotiation

Handshake encryption

In TLS 1.2 much of the handshake crosses the network in clear text, so an observer can read the certificate chain and the algorithms offered and chosen. TLS 1.3 encrypts everything after the ServerHello, improving privacy and making passive traffic analysis considerably harder.

0-RTT resumption

TLS 1.3 adds optional zero round trip time resumption: a client that has connected before can send application data immediately, using material from the earlier session. Reconnects become dramatically faster, which suits APIs and web services. The trade-off is that 0-RTT data can be replayed, so it is only safe for idempotent operations. Database clients typically avoid or disable it, because replaying a transaction can have consequences a read-only request would not.

What this means for an Informix deployment

• Faster connection establishment, most noticeably over higher-latency networks.
• Mandatory perfect forward secrecy, so captured traffic stays protected even if keys are compromised later.
• Stronger defaults, with obsolete algorithms no longer available to negotiate.
• Simpler configuration, from a much smaller set of secure suites.
• Better privacy, because most of the handshake is encrypted.

For long-lived database sessions the performance gain is modest, since the handshake happens only at connection time. The substantial benefits are in security, and in environments where applications open many short-lived connections or reconnect frequently.