Peakhour.IO - HTTP

RFC 9460

2023-11-16T00:00:00+11:00

RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.

Understanding the Current Process

Traditionally, when a browser connects to a website, it follows a sequence:

Browser requests site via HTTP.
Server redirects request to HTTPS.
Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.

The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.

The Impact of SVCB and HTTPS Records

SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.

Adoption and Industry Response

Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.

As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.

What the Records Look Like

A typical SVCB record might look like this:

_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")

This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.

An HTTPS record could be:

example.com. 3600 IN HTTPS 0 svc.example.net.

This record suggests that example.com should be accessed securely through svc.example.net.

Apex Domains and the Importance of SVCB/HTTPS Records

One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.

These records enhance capability

1. Load Balancing:

Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.

example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")

In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.

2. Failover Mechanism:

For a service that requires high availability, SVCB records can express failover directly:

critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")

Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.

3. Apex Domain Usage:

A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.

example.com. IN HTTPS 0 cdn-provider.example.net.

This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.

4. Encrypted ClientHello Support:

Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.

secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")

This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.

5. Directing Traffic to Specific Protocols:

For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.

api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")

Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.

The Long Wait

HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.

It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.

Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies

Final Thoughts

RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.

HTTP/2 Rapid Reset Attack Deepdive

2023-10-12T00:00:00+11:00

Distributed Denial of Service (DDoS) attack vectors keep changing. The recent spike in HTTP/2-based DDoS attacks has been notable for its volume, with some attacks surpassing 398 million requests per second. Peakhour observed these attacks and worked through how to understand and mitigate them. This article explains how they work and what operators can do to reduce exposure.

The Rise of HTTP/2 in DDoS Attacks

HTTP/2 was designed to make web traffic more efficient. The same features that improve performance for legitimate users can also be abused in DDoS traffic.

Much of HTTP/2's efficiency lies in "stream multiplexing." It allows multiple messages to be sent over a single TCP connection. While HTTP/1.1 processes each request serially, HTTP/2 can manage multiple concurrent streams on a single connection. This means a client can send multiple requests in a single round trip, increasing how much work each connection can drive.

The 'Rapid Reset' Attack Explained

The "Rapid Reset" attack is a specific DDoS technique built around HTTP/2. The attacker starts by opening multiple streams, much like in a standard HTTP/2 attack. However, instead of waiting for responses, they cancel each request immediately.

The client does this by sending a RST_STREAM frame, indicating that a previous stream should be cancelled. The rapid request-and-reset sequence means the server spends resources processing the request, only for it to be cancelled before a response is generated. This tactic amplifies the server's workload without the attacker needing to wait for responses, which increases the pressure each connection can place on the server.

Variants of the Rapid Reset Attack

Attackers also used variations of the Rapid Reset attack:

One variant involves delaying the reset action. The attacker opens multiple streams, waits, then cancels the streams and instantly opens new ones. This method can evade some rate-based defences.
Another variant avoids stream cancellations. Instead, the attacker tries to open more streams than the server allows. This aims to keep the server continually busy, processing a near-constant flow of requests.

Effective Mitigation Techniques

Mitigation is not as simple as blocking individual malicious requests. A more effective approach is to close the entire TCP connection when malicious activity is detected. The HTTP/2 protocol supports connection termination through the GOAWAY frame. This feature needs to be used aggressively to prevent Rapid Reset attacks, rather than relying on the more passive, standard implementation.

Deciding which connections to treat as malicious is a challenge. One potential strategy is to monitor connection statistics. If a connection exceeds a set threshold of cancelled requests, it might be deemed malicious. Responses to suspect activity could range from sending a GOAWAY frame to terminating the TCP connection.

For the non-cancelling variant, the best approach is to shut down connections that breach the concurrent stream limit, either immediately or after a few violations.

Broader Protocol Implications

These attack techniques are specific to HTTP/2, but the wider protocol lesson still matters. The HTTP/3 (QUIC) protocol isn't directly vulnerable in the same way. As a precaution, server implementations should consider limiting the work done by a single connection.

The Importance of Industry Collaboration

When the threat of the Rapid Reset attack became apparent, the industry collaborated to address the issue. The vulnerability was disclosed to key HTTP/2 implementers, helping to devise and distribute effective countermeasures. The vulnerability is logged against CVE-2023-44487.

HTTP/2 'Rapid Reset' DDoS attacks pose a serious risk to services using the protocol. To reduce exposure, service providers should promptly apply available software patches and updates.

Learn how Peakhour's Application Security Platform helps protect against Layer 7 DDoS attacks, including the HTTP/2 Rapid Reset vulnerability. Contact our team to secure your infrastructure.

A Secure Internet

2023-08-16T00:00:00+10:00

Here at Peakhour, we track browser security changes because they affect how sites are delivered and how users experience warnings. Google Chrome has made another move towards encrypted and authenticated traffic by expanding HTTPS-First Mode. Here is what Chrome unveiled on August 16, 2023, and what it means for HTTPS by default.

Automatic Upgrades to HTTPS

Chrome aims to make HTTPS the standard protocol by automatically upgrading all HTTP navigations to HTTPS. Even if you click a link explicitly declaring HTTP, Chrome will try HTTPS first. If the upgrade fails because of an invalid certificate or another issue, Chrome will fall back to HTTP.

The change is part of an experiment in Chrome version 115. It does not protect against active network attackers, but it does shift more everyday traffic away from passive eavesdropping and towards HTTPS as the default.

Warning on Insecurely Downloaded Files

Chrome is also adding warnings before users download high-risk files over insecure connections. Downloaded files can contain malicious code that compromises a computer. The warning gives users a clearer signal before they proceed, while still allowing the download if they accept the risk. The rollout of these warnings is expected to start in mid-September.

Expanding HTTPS-First Mode Protections

Chrome's longer-term goal is to enable HTTPS-First Mode for all users. It is expanding those protections in several areas:

Enabling HTTPS-First Mode for users in Google's Advanced Protection Program who are also signed into Chrome.
Planning to enable HTTPS-First Mode by default in Incognito Mode for a more secure browsing experience.
Experimenting with automatically enabling HTTPS-First Mode on sites frequently accessed over HTTPS.
Exploring automatically enabling HTTPS-First Mode for users who rarely use HTTP.

Try it Out

For users who want to try HTTPS upgrading or insecure download warnings before the full rollout, Chrome has provided options in the browser's settings to enable these features.

Peakhour's HTTPS Redirection Feature at the Edge

At Peakhour, HTTPS redirection is a practical edge control. It helps enforce encrypted and authenticated connections before a request reaches the origin.

When a user attempts to access a site over HTTP, our edge identifies the unsecured connection. Instead of allowing that connection through, we redirect the request to the HTTPS version of the site.

Enhanced Security: By enforcing HTTPS, data transmitted between your website and your users is encrypted and protected from potential attackers.
Compliance with Best Practices: This feature aligns with industry standards and recent browser policies, including Chrome's push towards HTTPS-first mode.
User Trust: A secure connection gives users a clearer reason to trust the site, improving the user experience and potentially supporting higher conversion rates.

We also offer options for customisation, allowing you to set specific rules and behaviours for how HTTP requests are handled and redirected to HTTPS. Peakhour's HTTPS redirection feature at the edge is a small control with a clear job: move HTTP traffic onto HTTPS automatically, protect users, and keep sites aligned with current browser expectations.

Final Thoughts

Chrome's push towards a secure-by-default web is another step towards a fully encrypted and authenticated internet. It also matches the way Peakhour thinks about everyday security controls: enforce the basics at the edge, and make the safe path the default.

Chrome's changes may require developers, enterprises, and users to adapt. The direction is still clear: less plain HTTP, more HTTPS by default, and fewer silent insecure paths. If your organisation is reviewing its HTTP handling, Peakhour can help you apply the right redirects and edge rules.

Understanding HTTP Link Headers

2023-05-24T13:00:00+10:00

HTTP headers are part of browser requests and server responses. They carry information about the connecting client, the requested resource, the server, and other request context. An HTTP header has a case-insensitive name followed by a colon (:), then its value. Headers are used for authentication information, content negotiation, and related protocol behaviour. Here are some sample request headers sent by my browser when requesting a page on the Peakhour website:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-AU,en;q=0.9
Connection: keep-alive
Cookie: _ga_NRWSVE0PSC=GS1.1.1685943893.13.0.1685943893.0.0.0
Host: www.peakhour.io
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4.1 Safari/605.1.15

The HTTP Link header

An HTTP Link header lets a server send context about a document back to a client. It can identify related resources or the direct location of a specific asset. For page-load optimisation, Link headers can be an alternative to putting preload/preconnect/prefetch hints in the HTML.

History

HTTP Link headers were proposed as a standard in the late 1990s, around the same time the HTTP/1.1 protocol was defined. However, it wasn't until 2010 that HTTP Link headers were officially recognised by the Internet Engineering Task Force (IETF) in RFC 5988, which described their purpose and functionality.

Uses

HTTP Link headers have several uses in web development. Some common examples are:

Pagination: Say we have a blog site with hundreds of posts, and we display 10 posts per page. When a user requests a page, we can use Link headers to provide URLs for the next and previous pages. This helps navigation through the large list of posts. Here's an example of how it might look:
```
Link: </posts?page=2>; rel="next", </posts?page=4>; rel="prev"
```
Preloading: Suppose we have a heavy image or a large CSS file that we know will be required for a webpage. We can use a Link header to tell the browser to start downloading it early, improving the perceived page load speed. For instance:
```
Link: </images/big-picture.jpg>; rel=preload; as=image
```
Resource Hints: Link headers can give the browser hints about resources that might be needed in the future, so the browser can decide whether to fetch them ahead of time. For instance:
```
Link: </scripts/myscript.js>; rel=prefetch
```

Comparison to Link Tags and Why Headers Can Be Better

Now you might be wondering, "Why use Link headers when we can use HTML Link tags?" There are several reasons HTTP Link headers might be a better choice:

Faster Processing: Since HTTP Link headers are part of the HTTP response, they arrive before the HTML document. This allows browsers to start preloading or prefetching resources sooner, which can improve page load times.
Greater Flexibility: HTTP Link headers can be used in situations where HTML Link tags cannot. For instance, they can be used with file types that don't support HTML, like JSON or XML. They can also be added by a third party, e.g., an edge delivery layer such as Peakhour, without the need to parse and rewrite the HTML document.
Less Clutter: Link headers can make your HTML less cluttered, as you can avoid filling the HTML document with numerous Link tags.

Conclusion

HTTP Link headers are a small part of HTTP, but they are useful for performance and flexibility. An edge delivery layer can add Link headers without the overhead of parsing or manipulating the main document, which makes them useful for optimising website performance.

TLS Fingerprinting

2023-02-02T13:00:00+11:00

What is Fingerprinting?

Fingerprinting is a technique that may be used to identify the specific device, web browser, and operating system making a request, regardless of what the client says in its user-agent header. By helping organisations identify and characterise the attributes of a client's connection, fingerprinting can improve network security and help protect against malicious traffic.

Fingerprinting can also refer to techniques for following or uniquely identifying individual users across the web. That is a separate set of techniques and is not discussed in this article.

Transport Layer Security (TLS) Fingerprinting determines the specific characteristics of a client's TLS implementation by examining the initial TLS handshake packet, known as the "Client Hello." This packet contains fields and parameters such as supported cipher suites, extensions, and the client's preferred order of those parameters, which can be used to create a unique "fingerprint" of the client's TLS implementation.

Why is it used?

Fingerprinting has several uses, including bot protection, DDoS protection, and client identification. By identifying and characterising the attributes of a client's connection, fingerprinting can improve network security and help protect against malicious traffic.

How does TLS Fingerprinting work?

TLS Fingerprinting examines the initial TLS handshake packet, known as the "Client Hello". The Client Hello packet is sent by the client during the initial phase of the TLS handshake, which establishes a secure connection between the client and the server. It contains information about the client's preferred encryption methods, extensions, and parameters, including:

Protocol Version: The version of the TLS protocol desired by the client.
Random: A 32-byte random value generated by the client, used in key generation and derivation.
Session ID: An optional session identifier for resuming a previous session.
Cipher Suites: A list of supported encryption algorithms, ordered by preference.
Compression Methods: A list of supported compression algorithms, ordered by preference.
Extensions: Optional extensions that can negotiate additional parameters, such as Server Name Indication (SNI) and Elliptic Curve Supported (ECS).

The Client Hello packet is central to the operation and security of the TLS connection because it provides information the server uses to select encryption algorithms and parameters. The packet also enables the client and server to negotiate an appropriate encryption method for their communication. The Client Hello's variable content, based on the TLS version, library, cipher suites, extensions, and settings supported by the client, makes it a strong candidate for fingerprinting.

Common components used to create a TLS fingerprint include:

Cipher Suites: The order of cipher suites supported by the client.
Extensions: Supported extensions included in the Client Hello packet, such as SNI and ECS.
TLS Point Formats: Encoding of cryptographic parameters in a format that can be transmitted as part of the TLS protocol, used in elliptic curve cryptography (ECC).
TLS Curves: The specific elliptic curves used in ECC, a type of public-key cryptography used in the TLS protocol.

TLS fingerprinting has been a topic of research for several years, with a number of tools and techniques developed from that work. Notable examples include JA3, developed by John Althouse, Jeff Atkinson, and Josh Atkins of Salesforce, which uses a hash of the client's SSL/TLS parameters as a unique identifier for tracking and analysing SSL/TLS traffic. Another tool, Mercury by David McGrew and Blake Anderson, can be used to fingerprint client connections and identify the device, operating system, and application making the connection.

TLS fingerprinting has a variety of uses, including bot protection, DDoS protection, malware identification and client identification. By enabling organisations to identify and characterise the attributes of a client's TLS implementation, TLS fingerprinting can improve network security and help protect against malicious traffic.

In production, TLS fingerprints are most useful when combined with IP intelligence and residential proxy detection, rather than treated as a standalone verdict.

Representation of a TLS Fingerprint

A TLS fingerprint is commonly represented as a string or hash that summarises the important components of the Client Hello packet. The most common components used to create a TLS fingerprint include the supported cipher suites, extensions, and TLS point formats. The cipher suites are represented as a list of hexadecimal values in the order they are presented by the client, while extensions and point formats are represented as a list of hexadecimal values or a unique identifier.

Raw JA3 signatures are represented by the following fields, which are then hashed with MD5:

SSLVersion, Cipher, SSLExtension, EllipticCurve, EllipticCurvePointFormat

An example raw signature is:

 771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-34-51-43-13-45-28-21,29-23-24-25-256-257,0

An MD5 hash is then applied, resulting in the final signature.

579ccef312d18482fc42e2b822ca2430

Mercury signatures are represented by:

"tls/1" (TLS_Version) (TLS_Ciphersuite) [ Extension* ]

An example signature is:

tls/1/
(0303)
(130213031301c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f00ff)
[
   (0000)
   (000a000c000a001d0017001e00190018)
   (000b000403000102)
   (000d0030002e040305030603080708080809080a080b080408050806040105010601030302030301020103020202040205020602)
   (0016)
   (0017)
   (0023)
   (002b0009080304030303020301)
   (002d00020101)
   (0033)
]

Hash Functions for Representing TLS Fingerprints

Hashing algorithms, such as MD5, are commonly used to create a unique representation of a TLS fingerprint. These hash functions take the client's TLS parameters as input and produce a fixed-length output, which serves as a unique identifier for the client. The hash value can be compared against a database of known TLS fingerprints to help determine the identity of the client.

Other techniques for representing TLS fingerprints include base64 encoding of the client's TLS parameters, such as in the Mercury fingerprint.

Challenges with TLS fingerprinting

TLS fingerprinting is not a foolproof method for identifying clients and their attributes. It has several limitations that need to be considered.

False Positives: TLS fingerprinting relies on the assumption that the client's Client Hello packet uniquely identifies a connecting process by its TLS implementation. However, it is possible for a client to alter the Client Hello packet by customising TLS parameters, which affects the Client Hello packet and can result in a false positive identification. This makes it important to use multiple methods for identifying clients. For example, Mercury takes into account destination ports to add additional context.
False Negatives: While TLS fingerprinting can identify many different clients and their attributes, it is not capable of identifying all clients. Some clients may have a unique or unusual TLS implementation that cannot be accurately fingerprinted. Additionally, some clients may actively attempt to evade fingerprinting by customising TLS parameters or using tools to anonymise their connections.
Forging of TLS Fingerprints: It is possible for attackers to deliberately forge or modify the information contained in their Client Hello packet to appear as a different client. This makes it difficult for fingerprinting tools to accurately identify the true identity of a client and can be used for malicious purposes, such as evading security measures or disguising the origin of an attack.
Incomplete Data: TLS fingerprinting is limited by the information contained in the Client Hello packet, which may not contain all of the necessary data to accurately identify a client. For example, a client may not send a full list of supported cipher suites or extensions, may use a modified version of the TLS protocol that is not recognised by the fingerprinting tool, or the fingerprint may not be present in available databases.

Different fingerprinting implementations can result in different hashes for the same TLS connection, even though the underlying SSL/TLS protocol remains unchanged. This happens due to the various algorithms, parameters, and representations used by different fingerprinting tools.

For instance, implementation differences when generating the TLS fingerprint may cause hashes found in public databases to be inconsistent with a locally generated hash.

Final Thoughts

Be aware of the limitations and differences between fingerprinting implementations, and choose the right tool and representation for your specific use case. Standardising the representation of fingerprints and using common hash algorithms can help avoid confusion and improve interoperability between databases.

Cache-Status

2022-02-25T13:00:00+11:00

Diagnosing CDN caching can be complex, with multiple cache layers, Origin Shielding, and local caching. Understanding how these layers interact can mean spending weeks working through RFCs for the finer details of ETag, Cache-Control, and Last-Modified headers - before you even account for advanced controls that override them.

When you have a problem, or are trying to optimise caching, the first thing you need is visibility into how a request was handled.

This is where the new Cache-Status header helps. The new draft RFC, RFC draft-ietf-httpbis-cache-header-08, aims to:

  aide debugging by standardising the format of various non-standard debug headers
  used by major CDN providers. The semantics of these headers are often unclear and vary
  between implementations.

The draft RFC proposes a new header, Cache-Status, with a uniform format for showing how multiple caching providers interact and handle a request. The Cache-Status header forms a list. Each member of the list represents a cache that has handled the request, and the last member belongs to the cache that most recently served the user. The header is only applicable to responses directly generated by an origin server. Each member can add a parameter indicating how it handled the request.

A Cache-Status header looks like this:

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; fwd=uri-miss;

It is formatted and labelled, with each cache in the line separated in list format by a ','.

The format of the Cache-Status header is a list comprising of the following possible parameters:

hit = boolean
fwd = (bypass, method, uri-miss, vary-miss, request, stale, partial)
fwd-status = integer
ttl = integer
stored = boolean
collapsed = boolean
key = string
detail = token / string

What the parameters mean

Hit

The hit parameter signifies that a request was satisfied by the cache. It is a boolean parameter meaning that its presence indicates a cache hit.

For example:

  Cache-Status: Peakhour.IO; hit

Fwd

The Fwd parameter indicates when a response was forwarded to an origin server - and why. The Fwd parameter contains one of the following arguments:

bypass - The cache was configured to not handle this request
method - The request method's semantics require the request to be forwarded
uri-miss - The cache did not contain any responses that matched the request URI
vary-miss - The cache contained a response that matched the request URI, but could not select a response based upon this request's headers and stored Vary headers.
miss - The cache did not contain any responses that could be used to satisfy this request (to be used when an implementation cannot distinguish between uri-miss and vary-miss)
request - The cache was able to select a fresh response for the request, but the request's semantics (e.g., Cache-Control request directives) did not allow its use
stale - The cache was able to select a response for the request, but it was stale
partial - The cache was able to select a partial response for the request, but it did not contain all of the requested ranges (or the request was for the complete response)

For example:

  Cache-Status: Peakhour.IO; fwd=uri-miss

Fwd-status

The fwd-status parameter indicates the status code the next hop returned in response to the request. It is only meaningful when "fwd" is present. For example, a complete miss would look like fwd=uri-miss and the HTTP status code of the downstream response would be supplied in the fwd-status:

The following example shows that the cache did not satisfy the request and that the downstream server indicated an HTTP 304 response - HTTP Not Modified.

  Cache-Status: Peakhour.IO; fwd=uri-miss; fwd-status=304

ttl

Each cache item is associated with a lifetime, referred to as the Time To Live (TTL). A TTL is in seconds and indicates the remaining freshness of the resource. This value is calculated by the cache.

For example, a cache hit showing that the resource has a freshness of 376 seconds.

  Cache-Status: ExampleCache; hit; ttl=376

Another example shows a cache hit with negative freshness - a stale resource.

  Cache-Status: ExampleCache; hit; ttl=-412

stored

Indicates whether the received response was stored by the cache. This example shows a cache miss and the cache storing the response for the next hit.

  Cache-Status: ExampleCache; fwd=uri-miss; stored;

collapsed

Indicates whether the received response was collapsed with another request.

key

The key is the lookup index into a cache. Cache keys convey a representation of how the cache will look up the resource used for the response. The cache key is implementation-specific.

This example shows a cache hit, the cache key and secondary key, and the remaining TTL of the resource.

  cache-status: peakhour.io; hit; key="https://example.com/calendar.css"; secondary-key="encoding::gzip"; ttl=30674859

detail

Allows additional implementation-specific information not captured by other parameters.

Multiple layers of caching

The header allows multiple layers of caching. For example, a global CDN may sit in front of a local varnish server. Each cache appends its cache-status to the header, so the last item is the closest cache to the actual application and the first item is the closest cache to the accessing user.

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; hit; ttl=545

Security

There are security implications to consider with this header. Making it public gives an attacker insight into how the cache is configured, which may help them bypass a cache entirely and access an origin server directly. Cache header security is provider-specific, but could involve enabling it only when required, restricting access to specific IP addresses, or requiring a custom request header to trigger the cache-status header.

Peakhour.IO regularly sees automated scans sending other providers' headers to trigger a cache-status header response.

Conclusion

The Cache-Status header gives clear insight into how cache layers interact on a website. It provides a standardised format for showing how a cache handled a request and allows multiple caches to report their part of the request path.

Peakhour fully supports this new header, and it can be enabled/disabled and secured in the dashboard.