Home
Basics
Security
Encryption: Data-in-transit

Encryption: Data-in-transit

Last updated: Nov 13, 2025
HEALTH TECH VENDOR
HCO

With Redox, encrypted data is exchanged either over TLS, VPN, or SFTP, depending on your communication method.

TLS

Data exchanged over API can be encrypted with TLS, which is specifically for encrypting data going between servers and web browsers. We use TLS to encrypt data when exchanging data via API.

Supported cipher suites

As of October 1, 2024, we removed support for various ciphers with TLS to improve Redox’s and our customers’ security. Currently, we only accept traffic from TLSv1.2 and TLSv1.3. See the table below for supported cipher suites.

Supported cipher suite
Protocol
TLS_AES_128_GCM_SHA256
TLS 1.3
TLS_AES_256_GCM_SHA384
TLS 1.3
TLS_CHACHA20_POLY1305_SHA256
TLS 1.3
ECDHE_ECDSA_AES128_GCM_SHA256
TLS 1.2
ECDHE_RSA_AES128_GCM_SHA256
TLS 1.2
ECDHE_ECDSA_AES256_GCM_SHA384
TLS 1.2
ECDHE_RSA_AES256_GCM_SHA384
TLS 1.2

We no longer support or exchange traffic using these (and other) cipher suites:

  • ECDHE-RSA-AES256-SHA
  • ECDHE-RSA-AES128-SHA
  • AES256-GCM-SHA384
  • AES128-GCM-SHA256
  • AES256-SHA256
  • AES128-SHA256
  • AES256-SHA
  • AES128-SHA

VPN

VPNs are encrypted tunnels for sharing data privately between systems. Redox leverages Internet Protocol Security (IPsec) site-to-site, policy-based VPNs.

We have apps that run directly on the VPN server, which translate MLLP into HTTPS and vice versa. This means we never have unencrypted MLLP being exchanged. Keep in mind that we don’t support HTTPS over VPN.

We require that you use the IKEv2 protocol with Diffie-Hellman (DH) groups 14 or DH21 to establish VPN tunnels.

If you want more technical details, check out these NIST special publications:

Processing requests

Redox has a two-step process for accepting and processing requests:

  1. Communication. A communication step focuses exclusively on receiving and enqueuing requests for processing.
  2. Application. An application step interprets and processes the payload, which could be HL7v2, X12, or CCD.

Redox acts as a TCP server, meaning we constantly listen and await a TCP client to initiate a request. Any port designated to accept MLLP traffic is within the range of 9960 to 11794. We support multiple active integrations on a given port.

We expect the TCP client to open and close ports as needed, but in some cases, Redox might close the integration due to:

  • lack of activity
  • incomplete integration
  • internal Redox failure

Initiating requests

Redox has a two-step process for initiating requests:

  1. Application. An application step queues requests and translates data from Redox JSON into HL7v2.
  2. Communication. A communication step focuses on sending requests.

Requests are sent over MLLP from a TCP Proxy through the VPN. Sending ports are randomly chosen in the range of 32768 and 60999. Once opened, they remain open until another request is sent across the active socket, or until there has been two hours of inactivity. Requests are processed in a first-in, first-out (FIFO) method order.

Redox doesn’t initiate multiple simultaneous requests to the same IP/Port combination, but waits for an acknowledgment before continuing to the next enqueued request.

SFTP

SFTP uses RSA SSH private keys. We periodically rotate our SSH public key used to validate connections.

If Redox hosts the folder, we use the following:

  • Hostname: sftp.redoxengine.com
  • Port: 22

Credentials are sent securely via encrypted messaging.