Closed
Bug 861310
Opened 11 years ago
Closed 9 years ago
Require TLS 1.2 (and only TLS 1.2) for TLS False Start
Categories
(Core :: Security: PSM, enhancement)
Core
Security: PSM
Tracking
()
RESOLVED
FIXED
mozilla37
People
(Reporter: mcmanus, Assigned: briansmith)
References
()
Details
Attachments
(1 file)
1.86 KB,
patch
|
keeler
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
wrt nsNSSCallbacks.cpp::CanFalseStartCallback()
>
> use similar logic that we use for cipher suites to prevent downgrade
> attacks from TLS 1.1 -> TLS 1.0 when we add TLS 1.1 support.
>
Assignee | ||
Updated•11 years ago
|
Comment 1•11 years ago
|
||
I'm confused about what's really meant here. Is this general about downgrade attacks, or is this only related to FalseStart? In which cases is FalseStart still used? As I understand it, chrome stopped using it except for sites that have TLS with support for next protocol negiotation to negiotation SPDY.
Comment 2•11 years ago
|
||
TLS downgrade is nicely outlined at http://jbp.io/2013/07/07/tls-downgrade/ False start is outlined at https://www.imperialviolet.org/2012/04/11/falsestart.html I'm also not sure which problem wants to address this bug.
Assignee | ||
Comment 3•9 years ago
|
||
From https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-01#section-6.2: Clients MUST NOT use the False Start protocol modification in a handshake unless the protocol version chosen by ServerHello.server_version has been whitelisted for this use. Generally, implementations should whitelist only the protocol version(s) for which they would not send TLS_FALLBACK_SCSV [downgrade-scsv].
Assignee: nobody → brian
Summary: Disable False Start in TLS1 without previous TLS1 full handshake after we have TLS1.1 → Require TLS 1.2 (and only TLS 1.2) for TLS False Start
Target Milestone: --- → mozilla37
Version: 20 Branch → Trunk
Assignee | ||
Comment 4•9 years ago
|
||
TLS 1.3 will have its own 1-RTT mechanism, so False Start won't be necessary for it. Further, it is likely that initial TLS 1.3 implementations will be less stable/correct/safe than TLS 1.2 implementations in the short term, since they will be newer, and because TLS 1.3 is more complex. Therefore, for a while, TLS 1.3 could be a sort of downgrade from TLS 1.2. To avoid all of that, let's just require TLS 1.2 for False Start. Further, we already require ALPN and/or NPN to be negotiated. There is a strong correlation between servers' ALPN/NPN support and TLS 1.2. So, this shouldn't have much, if any, negative impact on the False Start rate. In fact, I believe that if we make this change, we may be able to remove the ALPN/NPN requirement, so this could eventually result in an improved False Start rate.
Blocks: 940787
Assignee | ||
Comment 5•9 years ago
|
||
Attachment #8534487 -
Flags: review?(dkeeler)
Assignee | ||
Comment 6•9 years ago
|
||
This change should have been made along with bug 1084025. In general, we always need to consider False Start when we tighten TLS handshaking behavior.
See Also: → 1084025
Comment on attachment 8534487 [details] [diff] [review] Require TLS 1.2 for TLS False Start Review of attachment 8534487 [details] [diff] [review]: ----------------------------------------------------------------- ::: security/manager/ssl/src/nsNSSCallbacks.cpp @@ +968,2 @@ > PR_LOG(gPIPNSSLog, PR_LOG_DEBUG, ("CanFalseStartCallback [%p] failed - " > "SSL Version must be >= TLS1 %x\n", fd, s/SSL Version must be >= TLS1/Must use TLS 1.2/ or something similar, I would think
Attachment #8534487 -
Flags: review?(dkeeler) → review+
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 8•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/4624477b475e Thanks for the quick review. I addressed your nit similarly to how you suggested.
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/4624477b475e
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•9 years ago
|
||
Comment on attachment 8534487 [details] [diff] [review] Require TLS 1.2 for TLS False Start Approval Request Comment: See bug 1084025 comment 52. This is part of that issue. The only difference is that *this* bug's patch is very low risk because it only affects whether we do a performance optimization or not. The only risk is the potential for a performance regression in some cases. Note that Google Chrome is planning to make the same change, with the same security-vs-performance tradeoff; see the Chromium bug link above. My intent is to uplift this to -aurora along with bug 1084025, and then to -beta later.
Attachment #8534487 -
Flags: approval-mozilla-aurora?
Updated•9 years ago
|
status-firefox36:
--- → affected
status-firefox37:
--- → fixed
Assignee | ||
Comment 11•9 years ago
|
||
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #10) > Approval Request Comment: See bug 1084025 comment 52. This is part of that > issue. The only difference is that *this* bug's patch is very low risk > because it only affects whether we do a performance optimization or not. The > only risk is the potential for a performance regression in some cases. Note > that Google Chrome is planning to make the same change, with the same > security-vs-performance tradeoff; see the Chromium bug link above. > > My intent is to uplift this to -aurora along with bug 1084025, and then to > -beta later. Updated Approval Request Comment: See bug 1109766 comment 4. Because bug 1109766's patch was uplifted, this is effectively a no-op patch, EXCEPT that it makes the telemetry more accurate. So, there should be NO user impact to this patch, but having accurate telemetry is important. This is now independent of anything regarding bug 1084025.
Updated•9 years ago
|
Attachment #8534487 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in
before you can comment on or make changes to this bug.
Description
•