If amount of origins that have early-data disabled exceeds certain amount, disable early-data for all origins
This is controlled by prefs.
Differential Revision: https://phabricator.services.mozilla.com/D126555
This is needed to make sure the experimental User Agent string is applied immediately after starting the browser, not just whenever the Nimbus data changes as part of the NimbusFeatures::OnUpdate handler.
Differential Revision: https://phabricator.services.mozilla.com/D126774
Before this bug TLS handshake was only driven by forcing writes. SecurtyInfo was set during a write code path. That is not anymore true and the TLS handshake can be driven by reading from a socket. That causes an issue where the SecurtyInfo was not set in case a TLS handshake fails. This bug added the setting of the SecurtyInfo to the read code path, but that causes problems when the transaction is closed due to corrupted response.
This patch fixes this by moving the setting of SecurtyInfo to Close() function.
Do not call HandshakeDoneInternal if the connection has been closed between posting the HandshakeDoneInternal runable and executing it.
Differential Revision: https://phabricator.services.mozilla.com/D125666
In this case necko should poll for read (not for write) and reset the poll flags when the handshake is done.
The other option is to inspect the resumption ticket before adding it to the nss socket and find out which alpn will be used and disable the early-data if the version is http/1.1 and the transaction cannot send early-data. This currently only works on Nightly. When we roll out the necko’s token cache we can consider making this change.
Additional changes:
Consolidate mEarlyDataNegotiated and mWaitingFor0RTTResponse into mEarlyDataState
Differential Revision: https://phabricator.services.mozilla.com/D123928
HandshakeDone will be called after a handshake is finished and also after the certificate verifications are done.
The code relies on HandshakeDone to signal that the handshake is done. When early-data is not available HandshakeDone is responsible for setting up a Http2 session if needed. There are 2 outcomes when early-data is used:
1) early-data is accepted and transaction continues polling for read,
2) early-data is rejected. In this case, the transaction is restarted as well as polling flags, i.e. the connection will stop polling for read and start polling for write.
Another difference is that a transaction that is started during the early-data period will behave as a normal transaction, i.e. it will write data and continue polling for read to receive response. The special cases during early-data(mWaitingFor0RTTResponse==true) are removed from nsHttpConnection::OnSocketWritable().
EnsureNPNComplete is only responsible for driving handshake and checking the early-data availability. All logic for finishing a handshake (i.e. checking whether early-data is accepted and checking alpn value) has been moved to HandshakeDone.
The patch also extracts FinishNPNSetup that is responsible for the bookkeeping after a handshake is done or fails, e.g. resetting transactions if 0Rtt is used but handshake fails, updating timings and sending telemetry.
HandshakeDone needs to be dispatched so that it is not called inside nss locks. The side effect of this is that nsHttpConnection::OnSocketWritable() may be called in between HandshakeDone being dispatched and executed. Therefore we still need to keep CheckCanWrite0RTTData(). This can be fixed in a follow up patch.
Side cleanups:
Remove mNotTrustedMitmDetected - his was used for ESNI, but it is not used anymore
Differential Revision: https://phabricator.services.mozilla.com/D123824
Extract Check0RttEnabled
The old code checks 0RTT state then does a DriveHandshake then checks 0RTT again. This is done in this way because before DriveHandshake is called for the first time 0RTT states are not set. DriveHandshake is sometimes called as a side effect by IsAlive() check. The new code makes this less complex and just calls DriveHandshaek before checking 0RTT.
Extract code for setting 0RTT telemetry values.
Remove some code that set timing because the same code is called a bit later again.
Differential Revision: https://phabricator.services.mozilla.com/D123645
Before this patch, we fetch HTTPS RR in `nsHttpChannel::MaybeStartDNSPrefetch`, which is too early. It's possible that this http request is blocked by an extension but we still send the query for HTTPS RR.
To improve this, we move the time of fetching HTTPS RR a bit late.
Differential Revision: https://phabricator.services.mozilla.com/D125931
Since `nsHttpTransaction::mConnection` could be `Http2Session` and `Http2Session` supports weak reference, we should make sure `Http2Session` to be always released on socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D125510
Before this bug TLS handshake was only driven by forcing writes. SecurtyInfo was set during a write code path. That is not anymore true and the TLS handshake can be driven by reading from a socket. That causes an issue where the SecurtyInfo was not set in case a TLS handshake fails. This bug added the setting of the SecurtyInfo to the read code path, but that causes problems when the transaction is closed due to corrupted response.
This patch fixes this by moving the setting of SecurtyInfo to Close() function.
Do not call HandshakeDoneInternal if the connection has been closed between posting the HandshakeDoneInternal runable and executing it.
Differential Revision: https://phabricator.services.mozilla.com/D125666
In this case necko should poll for read (not for write) and reset the poll flags when the handshake is done.
The other option is to inspect the resumption ticket before adding it to the nss socket and find out which alpn will be used and disable the early-data if the version is http/1.1 and the transaction cannot send early-data. This currently only works on Nightly. When we roll out the necko’s token cache we can consider making this change.
Additional changes:
Consolidate mEarlyDataNegotiated and mWaitingFor0RTTResponse into mEarlyDataState
Differential Revision: https://phabricator.services.mozilla.com/D123928
HandshakeDone will be called after a handshake is finished and also after the certificate verifications are done.
The code relies on HandshakeDone to signal that the handshake is done. When early-data is not available HandshakeDone is responsible for setting up a Http2 session if needed. There are 2 outcomes when early-data is used:
1) early-data is accepted and transaction continues polling for read,
2) early-data is rejected. In this case, the transaction is restarted as well as polling flags, i.e. the connection will stop polling for read and start polling for write.
Another difference is that a transaction that is started during the early-data period will behave as a normal transaction, i.e. it will write data and continue polling for read to receive response. The special cases during early-data(mWaitingFor0RTTResponse==true) are removed from nsHttpConnection::OnSocketWritable().
EnsureNPNComplete is only responsible for driving handshake and checking the early-data availability. All logic for finishing a handshake (i.e. checking whether early-data is accepted and checking alpn value) has been moved to HandshakeDone.
The patch also extracts FinishNPNSetup that is responsible for the bookkeeping after a handshake is done or fails, e.g. resetting transactions if 0Rtt is used but handshake fails, updating timings and sending telemetry.
HandshakeDone needs to be dispatched so that it is not called inside nss locks. The side effect of this is that nsHttpConnection::OnSocketWritable() may be called in between HandshakeDone being dispatched and executed. Therefore we still need to keep CheckCanWrite0RTTData(). This can be fixed in a follow up patch.
Side cleanups:
Remove mNotTrustedMitmDetected - his was used for ESNI, but it is not used anymore
Differential Revision: https://phabricator.services.mozilla.com/D123824
Extract Check0RttEnabled
The old code checks 0RTT state then does a DriveHandshake then checks 0RTT again. This is done in this way because before DriveHandshake is called for the first time 0RTT states are not set. DriveHandshake is sometimes called as a side effect by IsAlive() check. The new code makes this less complex and just calls DriveHandshaek before checking 0RTT.
Extract code for setting 0RTT telemetry values.
Remove some code that set timing because the same code is called a bit later again.
Differential Revision: https://phabricator.services.mozilla.com/D123645
Previously we called `ProcessCrossOriginEmbedderPolicy` in
`nsHttpChannel::ContinueProcessResponse1`, but we only loaded the cached
response headers in `ContinueProcessResponse3`, meaning that we incorrectly
reported a missing header for the revalidated resource.
This change moves the header checking calls to `ContinueProcessNormal` and
`AsyncProcessRedirection` instead, so they get executed after processing
the cached headers.
Differential Revision: https://phabricator.services.mozilla.com/D125184
Jens Stutte
june wilde
Marian-Vasile Laza
Alexandru Michis
Noemi Erli
Valentin Gosu
Gijs Kruitbosch
Emilio Cobos Alvarez
Dragana Damjanovic
Kershaw Chang
Dennis Schubert
Shane Caraveo
Sean Feng
Butkovits Atila
Yury Delendik
Cristian Tuns