Currently, the process of establishing a connection to a server goes through a state machine that:
1) Gathers relevant information from the peer (e.g. certificates, OCSP responses, CT information)
2) Verifies the certificate
a. Construct the possible certificate chain(s), which may involve one or more network requests
b. Evaluate the chain, also considering application-level overrides (passed in as verify flags from the SSLConfig) and application-level blacklists (CRLSets)
c. Returns the 'best' chain and error information
3) Verifies the OCSP response
4) Extracts the SCTs and verifies the signatures on those SCTs to match with known logs
5) Evaluates whether or not any policy overrides exist for CT policy
6) Evaluates the set of SCTs provided to determine compliance with CT policy
Along with several other related steps, which include HSTS, HPKP, Expect-CT, and Expect-Staple policies.
When pooling connections, we do something 'similar', in which presuming a valid certificate, we extract the set of hostnames, and make sure that the Expect-CT, Expect-Staple, and other policies are 'consistent' with the existing connection.
This means that there's some duplication of state machine (including reordering) between TLS and QUIC, there's duplication in the HTTP/2 pooling logic, and it's duplicative of work for Signed Exchanges. Further, the work for the pooling logic doesn't for some scenarios (e.g. Issue 622142)
Comment 1 by kinuko@chromium.org
, May 31 2018