Most internet protocols include a mechanism for changing themselves. Before a browser and a server exchange anything that matters, the browser announces the newest version it speaks, and the server is supposed to reply with the best version both share. For years, the rules for TLS, the encryption that protects most web traffic, said exactly that. Nothing in them could guarantee that anyone had tested the mechanism.
In February 2017, Chrome 56 began offering TLS 1.3. In Maryland's Montgomery County schools, a district representative reported that upwards of 30 percent of about 50,000 Chromebooks were stuck looping at the login screen. The cause was a Blue Coat web filter sitting between students and the internet, one of the inspection boxes engineers call middleboxes. It didn't recognize the browser's greeting and dropped the connection. The district rolled back to Chrome 55, and Google paused the rollout.
Blaming the filter's makers would be easy and not entirely fair. Their product had to make sense of every message passing through, and a message it couldn't parse was one it couldn't vouch for. They built against the traffic that existed, and no customer pays for compatibility with a version that hasn't shipped. When a field carries the same value for years, every program that reads it learns, without anyone deciding, that the value never changes. Engineers call this ossification. Like deferred maintenance, it saves the vendor testing now and sends the cost, years later, to someone else's login screen.
The designers' first response was camouflage. TLS 1.3 still stamps its opening message with TLS 1.2's version number and tucks the real negotiation into an optional section that older equipment tends to skip. The specification is candid about why: "Unfortunately, some middleboxes fail when presented with new values." Hiding the version number wasn't enough. In Chrome's initial deployment, 92.3 percent of handshakes succeeded, against 98.3 percent for TLS 1.2. So the designers made the whole exchange pass for a TLS 1.2 session resumption, down to dummy records that do nothing. In a later Chrome experiment, 98.8 percent succeeded, effectively level with TLS 1.2.
A disguise, though, only gets you through one upgrade. Google's Adam Langley had already put the longer lesson plainly: "have one joint and keep it well oiled." His colleague David Benjamin designed a technique called GREASE: browsers mix reserved, meaningless values among their real options on ordinary connections. Software that chokes on the unfamiliar now breaks right away, in the vendor's own testing, instead of on the day a real change arrives. The cost of rigidity shifts from the student at the login screen to the implementer, who can actually fix it.
QUIC, a newer protocol that browsers now use to load many web pages, takes the idea furthest. RFC 9369 defines a QUIC version 2 with no new features. Its version number, 0x6b3343cf, was chosen to look random so equipment can't learn to expect small integers, and its stated purpose is to "exercise the version negotiation framework." Firefox 155 began using it in September. Each connection that settles on version 2 shows that QUIC can still change, which the old TLS rules asserted but never demonstrated.
Shifting the cost onto implementers also separates it from the benefit. Browser makers want future changes, so the exercise serves them. The vendors who must fix whatever greasing exposes may, as a current Internet Architecture Board draft concedes, see no benefit at all.
Exercise also prevents only accidental rigidity, not deliberate refusal. Cisco advises customers of one of its filtering products to block QUIC outright, because the product cannot reliably enforce its policies on that traffic. A protocol keeps its ability to change only where someone keeps using it and whoever runs the network lets it through.
- How common intolerance was: A 2016 exploratory scan by Red Hat's Hubert Kario found that 469 of 12,606 trusted hosts rejected a TLS 1.3 greeting, and his report to the TLS working group lays out how that early, non-representative estimate was gathered.
- Firefox's parallel test: Eric Rescorla's December 2017 Firefox Beta results found no statistically significant difference in failures between TLS 1.2 and the disguised TLS 1.3 handshake, using a different experimental design from Chrome's.
- Inside one failing box: David Benjamin bought a Cisco Firepower device and found that its decrypt-and-resign mode passed unknown extensions along while rewriting other fields, producing a handshake that contradicted itself.
- Encryption's unfinished business: The IETF's analysis of transport header confidentiality explains why hiding protocol fields protects metadata and limits ossification but does not end it, since observers can come to depend on timing and traffic patterns instead.
