Why is it not enough to encrypt only data crossing the internet, and what does it mean to also encrypt internal service-to-service traffic with something like mutual TLS?

technical-conceptual · Junior level · cloud-devops-security

What the interviewer is really asking

Assess whether the candidate understands that internal links are part of the threat model (zero-trust), and grasps that mutual TLS both encrypts east-west traffic and authenticates BOTH endpoints, unlike ordinary one-way TLS.

What to say

• Challenge the assumption: encrypting only the public edge (north-south) assumes the internal network is trusted, but an attacker who gets a foothold inside, or a misconfigured peer, can sniff or impersonate on supposedly-private links — zero trust says don't assume the internal network is safe.
• Explain mutual TLS specifically: ordinary TLS authenticates the server to the client; mutual TLS (mTLS) has BOTH sides present certificates, so each service proves its identity to the other — a caller can't be spoofed by a rogue workload, and traffic is encrypted in transit between services.
• Connect it to operations: this is typically done with workload identities/certificates issued automatically (often by a service mesh) so you get encrypted, mutually-authenticated east-west traffic without each team hand-managing certs.

What to avoid

• Saying internal traffic doesn't need encryption because it 'never leaves our network' — that's the flat-trust assumption zero trust exists to reject, and it ignores insider threat and lateral movement.
• Describing mTLS as just 'TLS but internal' without noting the key difference: both endpoints authenticate, not just the server.
• Confusing transport encryption (mTLS, in transit) with encryption at rest, or claiming mTLS authenticates end users — it authenticates the services/workloads to each other.

Example answers

Strong: Encrypting only the edge assumes everything inside is trusted, but if an attacker lands on one internal host they can sniff or impersonate on those 'private' links — so zero trust treats internal traffic as untrusted too. Mutual TLS fixes both halves: it encrypts service-to-service traffic and, unlike normal TLS, both sides present certificates so each service authenticates the other. We got this 'for free' by enabling mTLS in our service mesh, which issued and rotated the workload certs, so a rogue pod couldn't impersonate a legitimate caller.

Weak: Internal traffic stays inside our network, so it's already safe — we only need TLS on the public endpoints.