A reverse proxy terminates TLS for a city API and forwards requests to the application over HTTP on the internal segment. Which statement reflects end-to-end encryption principles for APIs?
Select an answer to reveal the explanation.
Short Explanation
Unlocking the letter at the front desk and walking it down the hall in plain sight leaves a gap. Re-encrypt to the app—or terminate only there—if you want the principle applied end to end.
Full Explanation
TLS termination at a reverse proxy decrypts traffic for that hop. When a city API proxy forwards to the application over HTTP on an internal segment, the cleartext segment after termination is a confidentiality gap unless traffic is re-encrypted to the app or TLS ends only on the application itself. End-to-end encryption principles ask where plaintext exists—not merely whether any TLS appeared at the edge.
Claiming any TLS termination automatically encrypts the backend hop fails: termination ends encryption unless a new TLS session is established upstream. Saying cleartext after the proxy is acceptable because Base64 bodies cannot be decoded on LANs fails both encoding-vs-encryption and LAN threat models (insider, misconfigured mirror, compromised host). Requiring IPsec instead of TLS on every HTTP resource overscopes; TLS on the API path is the usual control, with IPsec as a separate network design choice.
Exam caveat: mTLS between proxy and app, or TLS passthrough to the app, both close the gap; HTTP on a presumed “safe” VLAN remains a design tradeoff the exam wants you to recognize. Document trust boundaries for auditors.
Operational check: map the path from citizen client → proxy → app, label each segment TLS or cleartext, and remediate any cleartext segment that carries tokens or personal data.