This fixes a race condition: In the server crypto setup, we would send
protocol.EncryptionForwardSecure on the aeadChan as soon as the SHLO was
composed, but before it was written to the crypto stream. This lead to
Listener.Accept returning the session already. If the server was ready
to write a lot of data then, this data could be sent before the crypto
setup would write on the crypto stream, therefore sending a lot of
undecryptable packets to the client, which would eventually lead to a
connection error (too many undecryptable packets).
This commit splits up handling of the crypto stream and the other streams in the framer, crypto setup, and the packer.
- Crypto stream data is handled separately and should never be sent unencrypted or FW-secure. Fixes#544.
- Non-crypto stream data is only sent with FW encryption on the server and only with non-FW or FW encryption on the client. Fixes#611.
The crypto stream is current excluded from flow control (#657), but that shouldn't be an issue in practice for now.
Pass the diversification nonce via a channel instead of setting it
directly. That way there is no need to protect the diversificationNonce
member by a mutex. Also prevents a possible deadlock that occurred when
SetDiversificationNonce was called before maybeUpgradeCrypto returned.
Fixes#411.
Chrome sends the FHL2 when it wants to perform a head-of-line blocking
experiment, introduced in QUIC version 36 (see
https://codereview.chromium.org/2115033002). We don’t support this
experiment. By sending a Public Reset when receiving this tag we force
Chrome to use the TCP fallback.
The packet containing the SHLO is the only packet that is sent with
initial encryption. If it is lost, we need to make sure that the
diversification nonce is included in the PublicHeader, otherwise the
client will not be able to derive the keys for the forward-secure
encryption.
