Data Protection and Encryption in Practice Questions

Direct answer: Roll mutual TLS, or mTLS, where both the client and server in a connection present and verify a certificate, proving both identities rather than just the server's, out in phases: permissive before strict, service by service rather than cluster-wide, using the mesh's built-in certificate authority to handle issuance and rotation automatically so no team hand-manages certificates, and give legacy services that can't join the mesh a gateway exception rather than blocking the whole rollout on them.

Structured elaboration:

Automated certificate issuance and rotation. A service mesh, such as Istio or an Envoy-based mesh, ships its own certificate authority that automatically issues each workload a short-lived certificate, often valid for hours rather than months, tied to that workload's identity, and rotates it before expiry with no manual step. This is what makes mTLS operationally viable at scale, since nobody is manually reissuing certificates per service.

Enforcing mTLS without breaking traffic. Start with an inventory: identify every service and its current traffic partners before touching any policy. Then enable the mesh's permissive mode, where sidecars accept both plaintext and mTLS traffic; this lets you deploy the mTLS infrastructure everywhere with zero behavior change yet, while the mesh's own metrics show you which traffic is already using mTLS versus still plaintext. Once a namespace or service shows fully mTLS traffic in those metrics for a sustained period, flip that specific scope to strict mode, where plaintext connections are rejected, rather than flipping the whole mesh at once. Treat each namespace's move to strict as its own deploy, with the ability to revert to permissive immediately if it breaks something the metrics didn't catch.

Handling legacy services that can't join the mesh. Route their traffic through a dedicated gateway, an ingress or egress proxy that is itself part of the mesh, which terminates plain TLS or even plaintext from the legacy service on one side and speaks mTLS to the rest of the mesh on the other. This isolates the exception to one well-monitored chokepoint instead of leaving a scattered set of plaintext-tolerant services throughout the mesh. Track legacy exceptions as a list with a named owner and a target sunset date, not as a permanent architectural feature, since every exception is a gap in the zero-trust boundary the rollout is trying to build.

flowchart TB
    subgraph ControlPlane[Mesh control plane]
        CA[Built in certificate authority]
    end
    CA -->|issues short lived cert| SA[Sidecar A]
    CA -->|issues short lived cert| SB[Sidecar B]
    SA -->|mTLS handshake| SB
    SvcA[Service A container] --> SA
    SB --> SvcB[Service B container]
    Legacy[Legacy service, no sidecar] -->|plain TLS| GW[Egress and ingress gateway]
    GW -->|mTLS to mesh| SA

Trade-offs and pitfalls: Flipping enforcement to strict mode before traffic metrics genuinely show full mTLS adoption for that scope is the single most common way this rollout causes an outage; a service that only occasionally calls a rarely-used dependency can look fully migrated for days before that dependency is finally called and fails. Treating the gateway exception path as temporary without a real owner and deadline is the other common failure, it quietly becomes permanent.

Direct answer: TLS (Transport Layer Security, the protocol that encrypts and authenticates traffic between a client and a server) protects data in transit by having the client and server agree on a shared secret key over a public network without ever sending that key in the clear, then encrypting everything that follows with it. Reviewing a server's configuration means checking four things: which cipher suites (the specific combination of algorithms used for key exchange, encryption, and integrity checking) are enabled, which protocol versions are allowed, whether certificate validation is strict, and whether renegotiation is handled safely.

Structured elaboration:

The handshake, at a high level. First, the client sends a ClientHello proposing a TLS version and a list of cipher suites it supports. The server replies with a ServerHello picking a cipher suite from that list, plus its certificate, which proves its identity by being signed by a certificate authority the client already trusts. Both sides then derive a shared symmetric session key through a key exchange, most modern TLS uses a Diffie-Hellman-based exchange, which lets both sides compute the same secret from public values even though an eavesdropper sees those same public values. Finally, both sides confirm the handshake wasn't tampered with, and every message after that point is encrypted with the shared session key. TLS 1.3 compresses this into fewer round trips than TLS 1.2, but the underlying shape, agree on parameters, exchange keys, confirm, then encrypt, is the same.

What to check when reviewing a server's configuration. Cipher suites: disable legacy or weak suites, anything using RC4, 3DES, or export-grade cryptography, or that lacks forward secrecy (a property where each session uses a fresh key, so stealing the server's long-term key later cannot decrypt past recorded traffic), and prefer AEAD (authenticated encryption with associated data, a cipher mode that encrypts and checks integrity in one step) ciphers such as AES-GCM. Protocol versions: disable SSLv3, TLS 1.0, and TLS 1.1; require TLS 1.2 as a floor and prefer TLS 1.3 wherever every supported client can use it. Certificate validation: confirm the certificate chains to a trusted root, hasn't expired, and its subject or SAN (Subject Alternative Name, the field listing which hostnames a certificate is valid for) actually matches the hostname being served, and confirm revocation checking via OCSP or a certificate revocation list is configured, since an expired-but-unchecked certificate is a common gap. Renegotiation: TLS renegotiation is a client or server re-running the handshake on an already-open connection to refresh keys or parameters; disable client-initiated renegotiation, or at minimum ensure secure renegotiation is enforced, since insecure renegotiation was the root of a well-known man-in-the-middle class of attack against older TLS deployments.

Certificate validation in practice means checking the whole trust chain, not just the leaf certificate: the chain runs from the server's own certificate up through one or more intermediate certificate authorities to a root the client already trusts, and a server that omits an intermediate certificate will fail validation for clients that don't already cache it, even though the leaf certificate itself is fine. Mutual TLS, or mTLS, where both sides present a certificate rather than just the server, is called for when you need cryptographic proof of the client's identity too, which is the normal case for service-to-service traffic inside a zero-trust network, or for a business-to-business API where you want to authenticate the calling organization by certificate rather than, or in addition to, an API key.

Worked example: A server offering TLS 1.0 alongside TLS 1.3, with a cipher list that still includes a 3DES suite, and no OCSP stapling configured, fails this review on three of the four checks: drop TLS 1.0 and the 3DES suite, and add OCSP stapling, where the server proactively attaches revocation-status proof to its own handshake instead of making every client query the certificate authority separately.

Trade-offs and pitfalls: Disabling old protocol versions and weak ciphers can break traffic from clients that genuinely can't be upgraded, some older devices only speak TLS 1.0. That's usually still the right trade to make, but it needs to be a deliberate, communicated decision rather than a surprise outage.