Data in Transit Protection: TLS, VPNs, and Internal Networks

When engineering teams discuss securing data in transit, the immediate response is usually simple: “Put HTTPS on it.” For public web traffic, TLS has become the default baseline. Yet treating transit encryption as an automatic check box obscures how network security actually works, where protocols fail, and how attackers intercept traffic inside modern environments.

Data in transit encompasses every byte traversing a network wire, radio wave, or virtual overlay. Protecting that traffic requires answering three distinct questions:

1. How do you verify the identity of the system at the other end?
2. How do you prevent eavesdroppers from reading the payload?
3. How do you prevent intermediaries from altering the data unnoticed?

To build defensible architectures and meet standards like PCI DSS Requirement 4, engineers must understand how TLS operates under the hood, what it does (and does not) guarantee, and how internal network hops, containerised clusters, and VPNs change the equation.

How TLS Works: The TCP Handshake and TLS Negotiation #

Transport Layer Security (TLS, currently standard in versions 1.2 and 1.3) sits between the transport layer (TCP) and the application layer (HTTP, SMTP, gRPC). Before a single byte of encrypted application data moves, two sequential handshakes must complete: the TCP 3-way handshake and the TLS cryptographic handshake.

Step 1: The TCP 3-Way Handshake #

TCP establishes a reliable, bidirectional stream connection across the network:

1. SYN: The client sends a Synchronise packet with an initial sequence number.
2. SYN, ACK: The server responds with a Synchronise and Acknowledgement packet containing its own sequence number.
3. ACK: The client sends the final Acknowledgement. The raw TCP socket is now established, but completely unencrypted.

Step 2: The TLS Cryptographic Handshake (TLS 1.3) #

In modern TLS 1.3 (specified in RFC 8446), the security handshake completes in a single round-trip:

1. ClientHello: The client sends supported cipher suites and an ephemeral Diffie-Hellman public key share (step 4 in the sequence).
2. ServerHello & Key Exchange: The server selects the cipher suite, provides its own public key share, and presents its digital X.509 certificate (step 5).
3. Session Key Derivation & Finished: Both sides independently calculate identical symmetric encryption keys without ever transmitting the secret key over the wire, and the client confirms completion (step 6).
4. Application Traffic: Encrypted application data exchange begins immediately (step 7).

The Critical Nuance: Identity vs Encryption #

A common misunderstanding is assuming that a valid TLS certificate guarantees end-to-end security. In reality, TLS solves three separate problems: Authentication, Integrity, and Confidentiality.

• Authentication (Identity): The digital certificate proves that the server owning the domain name matches the public key presented. This relies on trusted Certificate Authorities (CAs).
• Integrity: Message Authentication Codes (HMAC or AEAD tags) ensure packets cannot be modified in flight.
• Confidentiality (Encryption): Symmetric ciphers (such as AES-256-GCM or ChaCha20-Poly1305) obscure the content.

A valid TLS certificate guarantees who you are talking to, but it does not guarantee that the connection is using the latest security protocols, or even any encryption at all. Historically, protocol specifications allowed “null cipher” suites that authenticated the host while transmitting data in cleartext. Furthermore, misconfigured servers can silently downgrade to deprecated protocols (like TLS 1.0 or 1.1) with weak ciphers. This is why so many frameworks and regulatory bodies enforce a known strong set of ciphers, such as those strictly mandated in the TLS 1.3 cipher suite.

The Edge Termination Problem: Public vs Internal Networks #

Under PCI DSS Requirement 4, organisations must use strong cryptography and security protocols to protect sensitive cardholder data during transmission over open, public networks (such as the Internet, cellular networks, or public Wi-Fi).

Most organisations accomplish this at the edge using a Reverse Proxy, Application Delivery Controller (ADC), or Cloud Load Balancer:

The Security Gap Inside the LAN and Containerised Environments #

Once TLS terminates at the edge load balancer, internal traffic between microservices, database clusters, and internal caches often travels in cleartext HTTP over the private local network (LAN, VPC, or container network overlays).

Engineers historically assumed that private networks were inherently trusted. However, several threats break this assumption:

• Shared Cloud Infrastructure: Cross-tenant vulnerabilities or misconfigured VPC routing.
• Compromised Internal Containers: If an attacker gains remote code execution on one container, running packet capture tools (tcpdump, wireshark) on an unencrypted container network captures east-west traffic from all adjacent services.
• Monitoring and Logging Proxies: Network taps and service mesh sidecars logging unencrypted HTTP bodies.

If you store sensitive records, pairing transit security with our guide on data obfuscation techniques and separating data from systems ensures that compromised internal nodes cannot reconstruct full credentials.

Alternative Approaches to Transit Protection #

Depending on the network layer and architectural requirements, engineering teams use several transit protection models:

1. Mutual TLS (mTLS) and Service Meshes #

While standard TLS only verifies the server identity, Mutual TLS (mTLS) requires both client and server to present and validate X.509 certificates.

Client (Presents Client Cert) ◄────[mTLS Bidirectional Auth]────► Server (Presents Server Cert)

• How it works: Used extensively in service meshes (such as Istio, Linkerd, or Envoy) and Zero Trust internal architectures.
• Advantage: Automatically encrypts all pod-to-pod east-west traffic inside containerised clusters while enforcing strict service identity policies.
• Trade-off: Requires dedicated internal Public Key Infrastructure (PKI) to manage certificate issuance, automated rotation, and revocation.

2. Virtual Private Networks (VPNs) and IPsec Overlays #

VPNs operate at the network layer (Layer 3) rather than the application layer (Layer 7):

• IPsec (IP Security): Encrypts IP packets between network gateways or individual hosts using Encapsulating Security Payload (ESP).
• WireGuard / OpenVPN: Creates encrypted point-to-point tunnels between remote servers or branch offices.
• Role in Compliance: PCI DSS recognises properly configured IPsec or WireGuard tunnels as sufficient for securing traffic over untrusted networks, even when underlying application protocols lack native encryption.
• Limitation: A VPN secures the tunnel between two network gateways. Once packets exit the tunnel interface, they travel in plaintext on the internal subnet.

3. Application-Layer Payload Encryption (JWE / Envelope Encryption) #

For high-assurance banking environments, transport-layer encryption alone may still fall short. Regulatory bodies like the Bank of Thailand mandate application-layer payload encryption for sensitive payment channels, as discussed in our breakdown of Bank of Thailand API payload encryption rules.

By encrypting the JSON payload directly with JSON Web Encryption (JWE) before sending it over TLS, the data remains unreadable even if TLS terminates at intermediate gateways, reverse proxies, or edge caches.

Comparison Matrix: Transit Protection Mechanisms #

Architectural Decision Framework for Transit Protection #

Use this flow to select the appropriate transit protection mechanism for your workloads:

Key Takeaways #

1. TLS guarantees server identity, not backend safety: A green padlock in the browser proves who owns the domain, but says nothing about how securely data is handled once received.
2. Do not leave east-west traffic unencrypted: Terminating TLS at the load balancer leaves internal microservices and database queries open to internal network sniffing.
3. Use mTLS for containerised architectures: Mutual TLS provides cryptographic identity and encryption for container-to-container communication without requiring manual code changes.
4. Isolate your network trust boundaries: Segregate critical payment environments and databases behind strict VPC boundaries and firewall access controls.
5. Combine transit security with storage protection: Encryption in transit only protects data while it moves. Once written to disk, rely on proper data obfuscation, hashing, and tokenisation to defend persistent records.

Where to Go From Here #

• Audit API security controls: Schedule an API & Application Security Review to test TLS implementation, token security, and endpoint defences.
• Verify compliance boundaries: Run a PCI DSS Gap Assessment to evaluate your encryption across public and private networks under Requirement 4.
• Conduct network penetration testing: Validate your internal segmentation and network encryption controls with our Penetration Testing Services.