Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- CloudFront-Viewer-ISP can be forwarded only with an origin request policy, not a cache policy or legacy cache settings. CloudFront omits it when it cannot determine the ISP.
- TLS-Details is a JSON object with six string fields describing the viewer-to-CloudFront connection. Forward it with an origin request policy, not a cache policy.
- A resumed TLS 1.2 session can set all three cryptographic fields to NONE. A resumed TLS 1.3 session retains a newly negotiated keyExchange but sets both signature fields to NONE. An empty string means CloudFront could not determine a field.
- X25519MLKEM768 is an example keyExchange value, not proof that every algorithm in the connection is post-quantum. Origin logs cover origin requests and cannot count every viewer on their own.
Which connection do the headers describe?
Amazon's October 30, 2026 announcement adds two optional viewer-detail headers that CloudFront can forward to an origin. CloudFront-Viewer-ISP carries the viewer's internet service provider (ISP) name. CloudFront-Viewer-TLS-Details carries a JSON description of the TLS session negotiated between the viewer and CloudFront. They can help an origin group requests by observed network or inspect the viewer-facing handshake.
That boundary matters: TLS Details is not a report of CloudFront's separate connection to your origin. An ISP label does not identify a person, prove a residential IP type, establish eligibility for a platform, or show that an application request succeeded.
Forward them with an origin request policy
Use an origin request policy to forward either header. AWS explicitly says CloudFront-Viewer-ISP can be added only through an origin request policy, not a cache policy or legacy cache settings. TLS-related headers, including CloudFront-Viewer-TLS-Details, also belong in an origin request policy, not a cache policy. An origin request policy controls what is sent with an origin request; a cache policy controls what contributes to the cache key.
Attach the policy to the cache behavior serving the test path and origin. These two headers cannot be added to a cache policy; keep origin forwarding separate from the cache key. The ISP header also cannot be added through legacy cache settings.
Distinguish absent, empty, and NONE
CloudFront does not percent-encode ISP values; handle the value as a header, not a URL component. It omits CloudFront-Viewer-ISP when it cannot determine the viewer's ISP. If your origin log lacks it, check whether a value existed, whether the selected behavior forwards it, and whether the request reached the origin. Requests served directly from cache do not necessarily reach the origin, so origin logs do not cover every viewer request.
An empty string inside the TLS-Details JSON means CloudFront could not determine that field. NONE means something different: the field does not apply to a resumed session. TLS 1.2 session resumption sets keyExchange, signatureScheme, and signaturePublicKeyType to NONE. TLS 1.3 session resumption still has a newly negotiated keyExchange, but its two signature fields are NONE. Do not collapse these states into one generic missing-value category.
Read post-quantum signals field by field
CloudFront-Viewer-TLS-Details has six fields: tlsVersion, cipherSuite, handshakeType, keyExchange, signatureScheme, and signaturePublicKeyType. A hypothetical origin observation could be {"tlsVersion":"TLSv1.3","cipherSuite":"TLS_AES_128_GCM_SHA256","handshakeType":"fullHandshake","keyExchange":"X25519MLKEM768","signatureScheme":"ecdsa_secp256r1_sha256","signaturePublicKeyType":"ecdsa_secp256r1"}. All six values are strings. This illustrates the documented format; it is not a measurement.
X25519MLKEM768 names the negotiated key-exchange group and signals only the viewer-to-CloudFront leg. It does not prove every cryptographic component or signature is post-quantum safe; the example's ECDSA signature scheme and public-key type are classical. The header says nothing about TLS from CloudFront to the origin.
The origin sees only requests that reach it, and CloudFront sends an origin request on a cache miss. An origin log sample can describe origin observations, but it cannot by itself represent every viewer or establish a post-quantum percentage for all viewers. For a broader rate, confirm that the dataset covers viewer requests and define the denominator.
Validate only on a test distribution you own
On a test distribution you are authorized to manage, choose one cache behavior and path, attach an origin request policy containing these headers, and request an uncached test object so it reaches the origin. Inspect the raw ISP header and parse the six TLS fields as strings. Record a missing header, an empty JSON string, and NONE as distinct states.
If a test request is served directly from cache, the absence of an origin record does not prove forwarding failed. First check the behavior and policy that handled it, then inspect a request that actually reached the origin. This is a suggested validation sequence; no distribution test results are reported here.
Sources
Frequently Asked Questions
I already use CloudFront-Viewer-TLS. What does TLS-Details add?
The older header provides the TLS version, cipher suite, and handshake type. TLS-Details includes that information and adds keyExchange, signatureScheme, and signaturePublicKeyType. Parse the new header as JSON when you need key-exchange or certificate-signature details; do not reuse the old colon-separated parser.
Do NONE and an empty string mean the same thing?
No. An empty string means CloudFront could not determine the field. NONE means the field does not apply to a resumed session. TLS 1.2 resumption sets all three cryptographic fields to NONE; TLS 1.3 resumption keeps keyExchange and sets the two signature fields to NONE.
Does X25519MLKEM768 prove the whole connection is post-quantum?
No. It is the keyExchange value for the viewer-to-CloudFront connection. Signature fields may still use classical algorithms, and this header does not describe the origin connection. Interpret each field and connection boundary separately.