bug 1404824 - reconcile inconsistent TLS version range settings by erring on the conservative side r?mayhemer
Before this patch, if a user set their TLS version range preferences to only
allow TLS 1.3, any connections made with the BE_CONSERVATIVE flag or via the
telemetry studies flags would fail because we would attempt to set an
inconsistent TLS version range (the minimum was greater than the maximum). This
fixes that by setting the minimum to the flag-configured maximum. This
intentionally overrides the user's preferences because it is in the context of
browser-critical services (i.e. update servers) or telemetry studies.
MozReview-Commit-ID: 1kKE5nOVQz8
--- a/security/manager/ssl/nsNSSIOLayer.cpp
+++ b/security/manager/ssl/nsNSSIOLayer.cpp
@@ -2616,16 +2616,25 @@ nsSSLIOLayerSetOptions(PRFileDesc* fd, b
infoObject->SharedState().IOLayerHelpers()
.adjustForTLSIntolerance(infoObject->GetHostName(), infoObject->GetPort(),
range);
MOZ_LOG(gPIPNSSLog, LogLevel::Debug,
("[%p] nsSSLIOLayerSetOptions: using TLS version range (0x%04x,0x%04x)\n",
fd, static_cast<unsigned int>(range.min),
static_cast<unsigned int>(range.max)));
+ // If the user has set their minimum version to something higher than what
+ // we've now set the maximum to, this will result in an inconsistent version
+ // range unless we fix it up. This will override their preference, but we only
+ // do this for sites critical to the operation of the browser (e.g. update
+ // servers) and telemetry experiments.
+ if (range.min > range.max) {
+ range.min = range.max;
+ }
+
if (SSL_VersionRangeSet(fd, &range) != SECSuccess) {
return NS_ERROR_FAILURE;
}
infoObject->SetTLSVersionRange(range);
// when adjustForTLSIntolerance tweaks the maximum version downward,
// we tell the server using this SCSV so they can detect a downgrade attack
if (range.max < maxEnabledVersion) {