In bug 1626057 we added support for steering. There we made the distinction
between a default network.trr.uri pref, and a user-set one by using
`Preferences::HasUserValue`. However, it seems that enterprise policies change
the default branch of the pref, so this would lead to it having a lower
priority than DoHRollout or steering.
In bug 1713036 we introduced `network.trr.default_provider_uri` and made
`network.trr.uri` an empty string, so checking hasUserValue isn't required
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D126961
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
To differentiate the storage permission is granted by either the
permission or the allowList, we need to change the hasStoragePermission
to an enum to represent the storage permission state.
This patch also changes the name of the attribute to make it reasonable
with respect to this change.
Differential Revision: https://phabricator.services.mozilla.com/D126276
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
Kershaw Chang
Valentin Gosu
Manuel Bucher
Dragana Damjanovic
Olli Pettay
Dennis Schubert
Tim Huang
Shane Caraveo
ffxbld
lyavor
Sean Feng
Narcis Beleuzu
Christoph Kerschbaumer
Butkovits Atila
Marian-Vasile Laza
Yury Delendik