Encryption in transit

For browser and API transfers the usual mechanism is TLS, specified for version 1.3 in RFC 8446 and guided for deployments in NIST SP 800-52. For SFTP, the SSH transport plays the same role.

The control ends where the session ends. TLS terminates at the server you connected to. That server decrypts the upload and can store the file in the clear. A load balancer that terminates TLS has the same view. Anyone who calls the channel "end to end" without saying who holds the keys is skipping that hop. End-to-end, in the strict sense, means intermediaries cannot read the payload. Transit encryption does not promise that.

A clinic uploads a 40 MB records PDF over HTTPS to a portal. The packet capture on the clinic Wi-Fi shows TLS records, not the PDF. The portal receives the file, writes it to a disk volume with no storage encryption, and emails a link. Transit encryption did its job on the upload. It did nothing for the disk, the backup, or the link that fetches the file later. The download needs its own TLS session. A recipient who uses a plain HTTP mirror gets the file in the clear even though the upload was encrypted.

SSL is the old name. Current deployments negotiate TLS. A certificate error is a failed check on who you reached, not a failed cipher. Operators who click through the warning have a encrypted channel to an unverified host. The bytes are scrambled. The endpoint may be the wrong one.

FTPS adds TLS to FTP's control and data connections. SFTP does not use TLS; it uses SSH. Both are encryption in transit. Neither is encryption at rest. A compliance questionnaire that accepts one as a substitute for the other is asking about different phases of the same file.