GREASE operates by inserting pseudo-random, unassigned values into the negotiation fields of protocols like TLS and HTTP. By sending these intentionally unknown parameters, a client forces servers to correctly ignore unrecognized values rather than failing or rejecting the connection. This mechanism actively tests and enforces the robustness of the protocol's extensibility design, ensuring that future legitimate extensions do not break interoperability.
Glossary
GREASE
GREASE (Generate Random Extensions And Sustain Extensibility) is a protocol hardening technique where clients inject random, invalid values into TLS extensions and HTTP headers to prevent servers from relying on brittle, hardcoded assumptions about specific implementations.
PROTOCOL HARDENING
What is GREASE?
GREASE (Generate Random Extensions And Sustain Extensibility) is a protocol hardening technique where clients inject random, invalid values into TLS extensions and HTTP headers to prevent servers from relying on brittle, hardcoded assumptions about specific implementations.
The technique was formalized by Google engineers to combat widespread server ossification, where critical infrastructure became dependent on specific, undocumented behaviors of a single browser's implementation. When a server encounters a GREASE value, it must respond according to the protocol specification—typically by ignoring it—preventing the ecosystem from developing hardcoded assumptions that stifle innovation and the deployment of new standards.
PROTOCOL HARDENING
Frequently Asked Questions
Explore the mechanics and strategic importance of GREASE, a critical technique for preventing protocol ossification and ensuring the long-term extensibility of the internet's core communication standards.
GREASE (Generate Random Extensions And Sustain Extensibility) is a protocol hardening mechanism defined in RFC 8701. It works by having clients inject random, invalid, or unknown values into specific fields of network protocol handshakes—primarily TLS Client Hello messages and HTTP/2 frames. The core mechanism involves reserving a set of code points that are intentionally unassigned by the IANA. Clients randomly select from these reserved values and insert them into lists of extensions, cipher suites, or application-layer protocol negotiation (ALPN) identifiers. Servers that correctly implement the protocol specification must ignore these unknown values and proceed with the handshake using only recognized parameters. If a server fails to handle the GREASE value—for example, by rejecting the connection entirely—it reveals a bug where the server has hardcoded assumptions about specific implementations rather than following the protocol's extensibility rules. This forces server operators to fix their brittle code, preventing the internet's infrastructure from becoming dependent on a single vendor's quirks.
PROTOCOL HARDENING
How GREASE Works in TLS and HTTP
GREASE (Generate Random Extensions And Sustain Extensibility) is a protocol hardening technique where clients inject random, invalid values into TLS extensions and HTTP headers to prevent servers from relying on brittle, hardcoded assumptions about specific implementations.
The GREASE mechanism operates by reserving a set of values in the TLS and HTTP registries that have no assigned meaning. Clients randomly select from these reserved values and inject them into Client Hello messages or request headers. A properly implemented server must ignore these unknown values, while a brittle server that relies on hardcoded parsing logic will fail, exposing a protocol ossification vulnerability before it reaches production.
Defined in RFC 8701, GREASE combats the tendency of network middleboxes and servers to reject traffic containing unrecognized extension points. By continuously injecting these random sentinel values, the protocol ensures that new legitimate extensions can be deployed in the future without being blocked by intermediaries that incorrectly assume only a fixed set of known parameters is valid.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read morePROTOCOL HARDENING
Key Characteristics of GREASE
GREASE (Generate Random Extensions And Sustain Extensibility) is a protocol hardening technique where clients inject random, invalid values into TLS extensions and HTTP headers to prevent servers from relying on brittle, hardcoded assumptions about specific implementations.
01
Random Value Injection
The core mechanism of GREASE involves inserting randomly generated values into reserved but unassigned code points within protocol handshakes. In TLS, this means advertising fake cipher suites, extensions, and named groups that no legitimate implementation would use. In HTTP, it involves sending pseudo-header fields with random names. The server must ignore these unknown values per protocol specification. If a server breaks or rejects the connection upon encountering a GREASE value, it reveals a hardcoded implementation flaw that assumes a fixed set of known parameters. This forces server developers to write robust, specification-compliant parsers rather than brittle allowlists.
02
TLS Extension GREASE
In the TLS 1.3 ecosystem, GREASE operates by reserving a specific block of 16 code points for each extensible parameter space:
- GREASE Cipher Suites: Values like
0x0A0Aand0x1A1Aare advertised in the Client Hello - GREASE Extensions: Random extension types such as
0x0A0Awith zero-length payloads - GREASE Named Groups: Elliptic curve groups like
0x0A0Ain supported_groups - GREASE Signature Algorithms: Algorithm identifiers like
0x0A0Ain signature_algorithms These values are explicitly reserved by the IETF in RFC 8701 and must never be assigned to real parameters. Chrome, Firefox, and Edge all implement TLS GREASE to ensure ecosystem extensibility.
03
HTTP/2 and HTTP/3 GREASE
Beyond TLS, GREASE extends to application-layer protocols to prevent ossification of HTTP semantics:
- HTTP/2 GREASE: Clients send random SETTINGS frame parameters with identifiers in the reserved range (
0x0A0Ato0x1A1A). Receiving endpoints must ignore unknown SETTINGS identifiers per RFC 7540 - HTTP/3 GREASE: QUIC transport parameters and HTTP/3 frame types include GREASE values to ensure intermediaries and servers handle unknown frame types gracefully
- Pseudo-header GREASE: Browsers inject random pseudo-header fields that servers must ignore, preventing middleware from assuming a fixed set of
:method,:path,:authority,:scheme, and:statusheaders This application-layer GREASE prevents network appliances and load balancers from hardcoding assumptions about HTTP framing.
04
Preventing Protocol Ossification
The primary threat GREASE mitigates is protocol ossification—the phenomenon where deployed infrastructure becomes dependent on specific implementation quirks rather than the written specification. Ossification occurs when:
- Middleboxes (firewalls, NATs, load balancers) reject traffic containing unknown protocol elements
- Server implementations fail gracefully when encountering unrecognized extensions
- Interoperability testing only validates against known, popular implementations By continuously injecting random noise into the protocol ecosystem, GREASE creates a constant selection pressure against non-compliant implementations. Any server or intermediary that breaks on GREASE values is identified and fixed before it can constrain future protocol evolution. This was critical for TLS 1.3 deployment, where middlebox intolerance initially caused connection failures.
05
RFC 8701 Specification
The GREASE mechanism is formally defined in RFC 8701 (January 2020), authored by David Benjamin of Google. Key specification details include:
- Reserved Values: A deterministic algorithm generates GREASE values from a seed based on the protocol version, ensuring consistent randomness without coordination
- Value Generation:
GREASE_value = 0x0A * (0x10 + seed), where seed is derived from the Client Hello's random field - Advertising Rules: GREASE values must appear in every extensible field, not just a subset, to prevent servers from selectively ignoring them
- Correct Server Behavior: Servers must ignore all GREASE values and continue the handshake normally. Rejection, termination, or error responses indicate non-compliance
- Correct Client Behavior: Clients must advertise at least one GREASE value per parameter space and must not complete a handshake if the server selects a GREASE cipher suite (indicating a broken server implementation)
06
User-Agent GREASE
A parallel application of the GREASE philosophy exists in User-Agent string diversification. Chrome periodically injects random, nonsensical tokens into its User-Agent string to prevent websites from parsing it with brittle regex patterns. For example, a Chrome User-Agent might include (Not;Brand followed by random version numbers. This forces web developers to use feature detection rather than User-Agent sniffing. The User-Agent Client Hints API (Sec-CH-UA) formalizes this by providing structured, verifiable browser attributes instead of a monolithic string. This GREASE-like approach ensures that websites remain compatible with future browser versions and prevents the ecosystem from hardcoding assumptions about specific browser identifiers.
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us