How GREASE from Google Protects the Future of Secure Connections and SSL Certificate Compatibility

The Transport Layer Security (TLS) protocol that secures connections between your browser and websites has evolved significantly over the past two decades.

Each new version brings improved security, faster performance, and better protection against emerging threats.

However, updating such a widely deployed protocol presents a unique challenge. When millions of servers, network devices, and software implementations exist worldwide, even small changes can cause widespread connection failures.

Generate Random Extensions And Sustain Extensibility (GREASE) is a protocol mechanism developed by Google engineer David Benjamin to address a phenomenon called protocol ossification.

By randomly injecting unknown values into Transport Layer Security (TLS) connections, GREASE ensures that servers and network devices properly handle new protocol features rather than rejecting them.

This article explains how GREASE works, why it matters for the future of secure connections, and its relationship to SSL Certificate deployment.

The Problem of Protocol Ossification

Protocol ossification occurs when implementations of a protocol become rigid and unable to handle changes, even when the protocol was designed to be extensible. Like a door hinge that rusts shut from lack of use, protocol extension points can become unusable when they are rarely exercised.

The Transport Layer Security (TLS) protocol was designed with extensibility in mind. Clients advertise capabilities they support, and servers select from those capabilities to establish a secure connection.

When a server encounters a capability it does not recognize, it should simply ignore that value and proceed with the options it does understand. This design allows new features to be added without breaking existing implementations.

How Ossification Happens

In theory, this extensibility model works perfectly. In practice, software bugs cause some implementations to reject connections when they encounter unknown values rather than ignoring them as specified.

These buggy implementations still work correctly with existing clients because no unknown values are being sent. The bug remains hidden, allowing the flawed software to become widely deployed.

Years later, when a new Transport Layer Security (TLS) feature is defined and clients begin advertising it, these buggy servers suddenly start rejecting connections. The protocol's extension points have effectively rusted shut because they were never exercised.

Adam Langley, a Google security engineer, described this phenomenon using the metaphor of an unused door hinge. If you rarely open a door, its hinge is more likely to rust and become stuck. Protocol extension points behave the same way. Without regular use, implementations make assumptions that break when change finally comes.

The Transport Layer Security (TLS) 1.3 Deployment Crisis

The most dramatic example of protocol ossification occurred during the development of Transport Layer Security (TLS) 1.3. This major protocol update had been in development for years and represented significant security and performance improvements over Transport Layer Security (TLS) 1.2.

When browser vendors began testing Transport Layer Security (TLS) 1.3 connections in early 2017, the results were alarming.

A significant percentage of connections failed when browsers advertised Transport Layer Security (TLS) 1.3 support. Some servers rejected the connection entirely when they saw an unfamiliar version number.

Network middleboxes including firewalls, load balancers, and inspection devices also caused failures. These devices had been parsing Transport Layer Security (TLS) connections for years and had made assumptions about what those connections should look like.

The Transport Layer Security (TLS) protocol had not introduced a new version in approximately eight years. During that time, countless implementations had been written that incorrectly handled version negotiation. These bugs spread undetected because there was nothing to trigger them. Learn More About SSL Certificate Browser Compatibility 🔗

How Generate Random Extensions And Sustain Extensibility (GREASE) Works

Generate Random Extensions And Sustain Extensibility (GREASE) addresses protocol ossification by proactively exercising extension points before they rust shut.

Instead of waiting for new features to expose buggy implementations, GREASE has clients regularly advertise meaningless unknown values.

Properly implemented servers ignore these values and continue normally. Buggy servers fail immediately, exposing the problem before it becomes widespread.

The GREASE Mechanism

When a Transport Layer Security (TLS) client that implements GREASE establishes a connection, it randomly selects from a set of reserved GREASE values and includes them in its connection request. These values appear in the same places where legitimate capabilities would appear, such as cipher suites, extensions, supported groups, and protocol versions.

The server receives this connection request containing a mix of real capabilities and GREASE values. A correctly implemented server ignores the GREASE values it does not recognize and selects from the legitimate options. The connection proceeds normally, and neither the server nor the end user notices anything different.

However, a buggy server that incorrectly rejects unknown values will fail when it encounters GREASE. The connection does not succeed, and the bug is immediately apparent. Because GREASE is deployed in widely used browsers, these buggy implementations are discovered quickly before they can spread throughout the ecosystem.

Reserved GREASE Values

The Internet Engineering Task Force (IETF) formally standardized GREASE as RFC 8701 in January 2020. This standard reserves specific values that will never be assigned to real Transport Layer Security (TLS) features, ensuring that GREASE values remain meaningless forever.

These reserved values follow a recognizable pattern but are distributed sparsely across the available numbering space. This sparse distribution discourages server implementations from simply hard-coding the specific GREASE values while still rejecting other unknown values. The goal is to ensure servers properly ignore all unknown values, not just the specific GREASE values.

GREASE values are reserved for cipher suites, extensions, named groups for key exchange, signature algorithms, protocol versions, Pre-Shared Key (PSK) exchange modes, and Application-Layer Protocol Negotiation (ALPN) identifiers. This comprehensive coverage exercises nearly all the extension points in the Transport Layer Security (TLS) protocol.

Client and Server Behavior

Clients implementing GREASE randomly select which GREASE values to advertise in each connection. This randomization prevents servers from conditioning their behavior on any specific pattern. The varying content and length of GREASE extensions further ensures that implementations handle diverse unknown values correctly.

Servers must treat GREASE values the same as any other unknown value. They must ignore unknown values in client-offered lists and must never select a GREASE value in their responses. If a server ever responds with a GREASE value, the client must reject the connection because this indicates a serious implementation flaw.

The Relationship Between GREASE and Transport Layer Security (TLS) Versions

GREASE played a crucial role in enabling the successful deployment of Transport Layer Security (TLS) 1.3 and will continue to facilitate future protocol versions.

Understanding this relationship helps explain why GREASE matters for ongoing internet security.

Version Intolerance

When browsers attempted to deploy Transport Layer Security (TLS) 1.3, they encountered widespread version intolerance.

Many servers rejected connections simply because they saw an unfamiliar version number in the client's connection request. The correct behavior would have been to ignore the unsupported version and negotiate a mutually supported version like Transport Layer Security (TLS) 1.2.

This version intolerance had accumulated over the eight years since Transport Layer Security (TLS) 1.2 was released. Without any new versions to test against, buggy implementations proliferated unchecked. By the time Transport Layer Security (TLS) 1.3 was ready for deployment, a significant percentage of servers could not handle it.

The Transport Layer Security (TLS) 1.3 designers ultimately worked around this problem by having Transport Layer Security (TLS) 1.3 connections disguise themselves as Transport Layer Security (TLS) 1.2 connections in certain fields. The actual version negotiation moved to a new extension, avoiding the ossified version field. While this solved the immediate problem, it added complexity to the protocol.

Preventing Future Ossification

GREASE ensures that version intolerance and similar problems do not recur. With major browsers sending GREASE values in every connection, buggy implementations are discovered and fixed before they become widespread.

When Transport Layer Security (TLS) 1.4 or another future version is eventually developed, the ecosystem will be prepared to handle it.

Google Chrome has included GREASE since version 55, released in 2016. Other browsers and Transport Layer Security (TLS) implementations have adopted GREASE as well. This widespread deployment means the entire internet ecosystem is continuously tested for proper extensibility handling.

Beyond Version Numbers

GREASE exercises more than just version negotiation. Cipher suites, extensions, key exchange groups, and signature algorithms are all covered. This comprehensive approach ensures that future enhancements to any aspect of Transport Layer Security (TLS) can be deployed without encountering ossification.

When new cryptographic algorithms are standardized to replace aging ones, or when new security features are added to the protocol, GREASE will have prepared the ecosystem to accept them. The extension points remain flexible and usable rather than rusting shut from disuse. Learn More About SSL Certificate Encryption Algorithms 🔗

GREASE and Middleboxes

Network middleboxes present unique challenges for Transport Layer Security (TLS) evolution. These devices, including firewalls, load balancers, intrusion detection systems, and content inspection appliances, often parse Transport Layer Security (TLS) connections to perform their functions. When they encounter unexpected protocol elements, problems can occur.

The Middlebox Problem

During Transport Layer Security (TLS) 1.3 deployment testing, researchers discovered that many connection failures were caused by middleboxes rather than the actual web servers.

These network devices had been designed based on assumptions about how Transport Layer Security (TLS) connections should look. When Transport Layer Security (TLS) 1.3 changed certain aspects of the protocol, these middleboxes interfered with or blocked connections.

Unlike web servers that can be easily updated, middleboxes are often deeply embedded in enterprise networks with infrequent update cycles. Some organizations deploy security appliances and do not update them for years. These devices become sources of ossification that affect all traffic passing through them.

GREASE Limitations with Middleboxes

GREASE primarily targets server implementations rather than middleboxes.

When a client sends GREASE values, the target server either handles them correctly or fails visibly.

Middleboxes that interfere with connections are harder to identify and diagnose because they sit invisibly between client and server.

However, GREASE still provides indirect benefits for middlebox tolerance. Vendors of network appliances have become more aware of ossification risks. Products that fail when encountering GREASE values are identified during testing and interoperability reviews. This awareness has improved middlebox implementations even though GREASE does not directly test them.

Related Efforts

The Transport Layer Security (TLS) and broader internet standards community has undertaken additional efforts to combat middlebox ossification.

Encrypted Client Hello (ECH) aims to encrypt more of the Transport Layer Security (TLS) handshake, preventing middleboxes from making assumptions about connection content.

The QUIC protocol, which underpins HTTP/3, was designed from the start with anti-ossification properties.

These complementary efforts work alongside GREASE to ensure the internet's security protocols can continue evolving to meet new challenges.

Implications for SSL Certificate Deployment

While GREASE operates at the Transport Layer Security (TLS) protocol level rather than the SSL Certificate level, it has important implications for organizations deploying SSL Certificates and maintaining secure web infrastructure.

Server Compatibility

If your web server software incorrectly handles unknown Transport Layer Security (TLS) values, connections from modern browsers may fail. Browsers that implement GREASE will expose these bugs through connection failures. Keeping your server software updated ensures compatibility with GREASE and proper handling of future protocol extensions.

Older server software or appliances that have not been updated may exhibit GREASE intolerance. If you experience unexplained connection failures from certain browsers, GREASE handling is one area to investigate. Most modern server software properly ignores unknown values, but legacy systems may require updates or configuration changes.

Testing and Validation

When deploying or updating SSL Certificates, testing connections from various browsers helps identify compatibility issues including GREASE-related problems. A successful connection from Google Chrome, which implements GREASE, indicates your server properly handles unknown values.

SSL Certificate testing tools may not specifically check for GREASE handling, but browser-based testing naturally exercises this functionality. If your site works correctly in Chrome and other modern browsers, your server is likely handling GREASE appropriately.

Future Protocol Support

GREASE prepares the ecosystem for future Transport Layer Security (TLS) versions and features. Organizations that maintain properly implemented server software benefit from this preparation automatically. When new protocol versions or cryptographic algorithms are standardized, servers that correctly handle GREASE values will transition smoothly.

Conversely, organizations running outdated or improperly implemented server software may find themselves unable to support future Transport Layer Security (TLS) features. Staying current with server software updates ensures ongoing compatibility and security.

GREASE Beyond Transport Layer Security (TLS)

The success of GREASE in maintaining Transport Layer Security (TLS) extensibility has inspired similar approaches in other protocols. The principle of proactively exercising extension points to prevent ossification applies broadly to protocol design.

HTTP/2 and HTTP/3

The HTTP/2 protocol incorporated lessons from Transport Layer Security (TLS) ossification in its design. HTTP/2 uses Application-Layer Protocol Negotiation (ALPN), a Transport Layer Security (TLS) extension, to negotiate the protocol version rather than relying on fields that might ossify.

HTTP/3, built on the QUIC transport protocol, includes explicit anti-ossification measures. QUIC encrypts most of its packet headers and metadata, preventing middleboxes from making assumptions about packet contents. Reserved frame types in HTTP/3 function similarly to GREASE values, ensuring implementations handle unknown frames correctly.

General Protocol Design Principles

GREASE has influenced how the internet standards community approaches protocol design. New protocols are evaluated for ossification risk, and mechanisms to prevent ossification are incorporated from the beginning rather than retrofitted later.

The concept of greasing extension points has become a recognized best practice. Protocol designers now consider not just whether a protocol is theoretically extensible, but whether that extensibility will remain usable in practice as implementations proliferate.

The Origin of GREASE

The GREASE mechanism emerged from observations about protocol evolution and the challenges of deploying new Transport Layer Security (TLS) features. Understanding its origin provides context for why this approach was chosen.

Adam Langley's Insights

Google engineer Adam Langley wrote extensively about protocol ossification and the challenges of evolving deployed protocols. His essays on the topic used the metaphor of joints and hinges to explain how extension points become unusable when they are not exercised.

Langley observed that protocols should be designed with the assumption that extensibility is only theoretical until proven practical. He advocated for regularly exercising extension points to keep them functional, even if no real new features were being deployed at that moment.

David Benjamin's Implementation

David Benjamin, working on Chrome's Transport Layer Security (TLS) implementation at Google, designed and implemented GREASE based on these insights. He proposed the mechanism to the Internet Engineering Task Force (IETF) and worked through the standardization process that ultimately produced RFC 8701.

The acronym GREASE cleverly captures the mechanism's purpose. Just as mechanical grease keeps joints moving freely, protocol GREASE keeps extension points working properly. The full expansion, Generate Random Extensions And Sustain Extensibility, describes exactly what the mechanism does.

Chrome Deployment and Standardization

Google deployed GREASE in Chrome starting with version 55 in late 2016. This early deployment provided valuable data about server tolerance for unknown values and helped refine the mechanism before formal standardization.

The Internet Engineering Task Force (IETF) published RFC 8701 in January 2020, officially standardizing GREASE for Transport Layer Security (TLS). This standardization ensures that GREASE values remain reserved and that the mechanism is documented for all implementers to follow.

Trustico® and Transport Layer Security (TLS) Compatibility

Trustico® SSL Certificates work with all modern Transport Layer Security (TLS) implementations including those that implement GREASE. Our SSL Certificates are issued by Certificate Authorities (CAs) that follow industry standards and support current Transport Layer Security (TLS) versions.

When you install an SSL Certificate from Trustico® the Transport Layer Security (TLS) handshake that establishes secure connections operates at the protocol level, separate from the SSL Certificate itself. Your server software handles GREASE values as part of the connection negotiation, and a properly implemented server works correctly regardless of which SSL Certificate is installed.

Frequently Asked Questions

Administrators and security professionals often have questions about GREASE and its implications for their infrastructure.

Does GREASE Affect My SSL Certificate?

No, GREASE operates at the Transport Layer Security (TLS) protocol level and does not affect SSL Certificates themselves.

Your SSL Certificate contains identity information and public keys that are used after the Transport Layer Security (TLS) handshake completes.

GREASE values appear during the initial handshake negotiation, before your SSL Certificate is presented.

Why Do Browsers Send Fake Values?

Browsers send GREASE values to exercise Transport Layer Security (TLS) extension points and identify servers that incorrectly reject unknown values.

These fake values are harmless and are ignored by properly implemented servers.

By continuously exercising extension points, GREASE prevents them from becoming unusable due to buggy implementations.

Can GREASE Cause Connection Failures?

GREASE can cause connection failures, but only to servers that are already broken.

A server that fails when receiving GREASE values would also fail when receiving legitimate new protocol features. GREASE exposes these bugs early so they can be fixed before new features are widely deployed.

How Do I Know If My Server Handles GREASE Correctly?

If your website works correctly in Google Chrome and other modern browsers, your server is handling GREASE appropriately.

Chrome has included GREASE since 2016, so any server that accepts Chrome connections is already proven to handle unknown values correctly.

Is GREASE Required for SSL Certificate Installation?

No, GREASE is a client-side mechanism that browsers implement. Your server does not need to send GREASE values. Your server simply needs to correctly ignore unknown values when clients send them, which is the standard behavior specified in Transport Layer Security (TLS) protocol standards.