Encryption: Data-in-transit

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

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.

As of October 1, 2024, we support these cipher suites:

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

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

We have applications that run directly on the VPN server which translate MLLP into HTTPS and vice versa, meaning that we never have unencrypted MLLP being exchanged.

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:

• Guide to IPsec VPNs
• Transitioning the use of cryptographic algorithms and key lengths
• Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography

Redox has a two-step process for accepting 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 may close the integration due to:

• a lack of activity
• an incomplete integration
• internal Redox failure

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, and once opened, they remain open until another request is sent across the active socket, or until there has been 2 hours of inactivity. Requests are processed in a first in, first out order.

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

SFTP uses RSA SSH private keys. We rotate the SSH 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.