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)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla37
Tracking Status
firefox36 --- fixed
firefox37 --- fixed

People

(Reporter: mcmanus, Assigned: briansmith)

References

()

Details

Attachments

(1 file)

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.
>
Blocks: 733647
No longer depends on: 733647
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.
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.
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
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
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+
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
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?
(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.
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.