# Encryption: Data-in-transit With Redox, encrypted data is exchanged either over TLS, VPN, or SFTP, depending on your communication method. > **Key takeaways** > > - Redox encrypts all data in transit using a method based on your connection type. > - **API connections**: Encrypted using **TLS 1.2** or **TLS 1.3**. > - **MLLP connections**: Encrypted using an **IPsec VPN** tunnel with **IKEv2**. > - **SFTP connections**: Encrypted using **SSH** with RSA keys. ## 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: - [Guide to IPsec VPNs](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf) - [Transitioning the use of cryptographic algorithms and key lengths](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf) - [Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf) ### 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.