summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMoonchild <moonchild@palemoon.org>2023-11-09 23:48:50 +0100
committerMoonchild <moonchild@palemoon.org>2023-11-11 17:21:54 +0100
commitd858ff342bddad365d4580670069afcc2d82569c (patch)
treed1d9970ebe3031f966057b42a770b8d18a843ff3
parentb9488c0c3238578613e3d2d6ee5ebf170bb6bff0 (diff)
downloadpalemoon-d858ff342bddad365d4580670069afcc2d82569c.tar.gz
No issue - Limit TLS 1.3 protocol fallback.
Since it's more common these days that there's an incorrect TLS 1.3 hello downgrade request when there's a certificate error and the resulting malformed hello error isn't very informative, it makes more sense to simply not allow any downgrades from TLS 1.3 to 1.2. This makes our handling of connections a little less flexible, but avoids user confusion and actually allows exceptions to be made in case of a low-risk cert error like an expiration or incomplete trust chain as it will then present a certificate trust error instead of the malformed hello in case of a downgrade that is caught by our downgrade sentinel. This will not affect any straight-up TLS 1.2 or 1.3 protocol negotiation and only changes what we do in case of a downgrade attempt.
-rw-r--r--palemoon/branding/shared/pref/preferences.inc3
1 files changed, 3 insertions, 0 deletions
diff --git a/palemoon/branding/shared/pref/preferences.inc b/palemoon/branding/shared/pref/preferences.inc
index 997a43f04..367f2efed 100644
--- a/palemoon/branding/shared/pref/preferences.inc
+++ b/palemoon/branding/shared/pref/preferences.inc
@@ -86,6 +86,9 @@ pref("general.useragent.compatMode.gecko", true);
pref("general.useragent.compatMode.firefox", true);
pref("general.useragent.compatMode.version", "102.0");
+// Limit protocol fallback from TLS 1.3
+pref("security.tls.version.fallback-limit", 4);
+
// ============================================================================
// ===| DevTools |=============================================================