RFC 8188 / START HERE
Encrypted HTTP content, before the details
Encrypted Content-Encoding is a descriptive name, not an acronym. HTTP means Hypertext Transfer Protocol; its message body carries the content.
The aes128gcm content coding encrypts a body in records, so a stored or forwarded copy can stay unreadable to a service that does not have the key. Each record also has a check for unauthorized changes.
The idea in one picture
Prepare content
Encrypt records
Recipient checks
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
TLS protects a network connection, but a server normally sees its contents after that connection ends. This RFC describes payload encryption for stored and streamed content; it leaves key management to a larger system.
A familiar example
An app can store an encrypted file and let a recipient with separately supplied keying material read it later. Ordinary HTTP fields and message sizes can still reveal information, and a valid record tag does not identify one unique sender.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Keep content encrypted in storageHTTP content coding transforms the message body. aes128gcm keeps content encrypted after a network connection ends; a recipient needs separately acquired keying material.→
- Read the binary coding headerThe encrypted body begins with a binary prefix: salt, record size, key-identifier length and key identifier. This prefix is inside the body, not an HTTP header field. An octet is an eight-bit byte.→
- Derive the key and each nonceHKDF, the HMAC-based Extract-and-Expand Key Derivation Function, derives a per-message key and nonce base. Each record combines that base with its own sequence number.→
- Frame and validate each recordA record encrypts data, one delimiter and trailing zero padding, then includes a 16-octet AES-GCM authentication tag. The delimiter distinguishes an intermediate record from the final one.→
- Reproduce the published examplesThe RFC provides complete binary examples, shown using Base64url for presentation. Decoding and checking them makes byte counts and record framing concrete.→
- Stop on invalid or incomplete contentAuthenticated records do not remove the need for whole-message checks, safe key usage, trusted application policy and protection of visible metadata.→
This introduction explains RFC 8188 (2017). Read the original RFC ↗