commit 8b353f389af49f667b4b10060f9f2b0abd5a05fe
author QUICHE team <quiche-dev@google.com> Tue Apr 09 13:49:10 2019 -0700
committer Copybara-Service <copybara-worker@google.com> Tue Apr 09 16:20:43 2019 -0700
tree 00d9ca8574e5930fe4735b4cad22633ad0c50e5b
parent 66dea072431f94095dfc3dd2743cb94ef365f7ef

Test QUIC behavior in the worst-case Leto fallback situation

Today, the worst-case QUIC handshake involves sending three CHLO messages.  With Leto, that increases to four, since if GFE realizes that Leto is down, it will reject an otherwise-kosher CHLO in order to swap out the ServerConfig whose private key lives on Leto for one generated locally on the GFE.

QUIC clients limit the number of CHLOs they're willing to send per handshake to three.  This CL's intent is to increase that limit to four.

However, there is a bug in the QUIC client-side CHLO counting code, which means that the de facto limit was actually four all along.  In order to avoid confusion, this CL both increases the constant from three to four, and also fixes the conditional so that the actual limit remains four.

The CHLO-limiting constant is checked in one other spot, but since we're increasing it the change should have no observable effect there.

This CL also adds a test for this behavior, which creates a gigantic certificate to force a three-CHLO handshake, and then brings down Leto to force a four-CHLO handshake, and explicitly verifies the number of CHLOs.

gfe-relnote: Test changes only in GFE code, no-op changes in QUIC code.
PiperOrigin-RevId: 242732499
Change-Id: I7e83ac37269ee5e8d541d058c3f851d0d9a7ff06