Closed Bug 1109766 Opened 5 years ago Closed 5 years ago

Require AES-GCM for TLS False Start


(Core :: Security: PSM, defect)

Not set



Tracking Status
firefox36 --- fixed
firefox37 --- fixed
relnote-firefox --- 37+


(Reporter: briansmith, Assigned: briansmith)




(1 file)

Because of POODLE, and BEAST before it, CBC mode cipher suites shouldn't be accepted for TLS False Start. This is what is recommended in the new False Start I-D at

   Also, various ciphers specified for use with TLS are known to have
   cryptographic weaknesses regardless of key length (none of the
   ciphers specified in [RFC4492] and [RFC5246] can be recommended for
   use with False Start).  The AES_128_GCM_SHA256 or AES_256_GCM_SHA384
   ciphers specified in [RFC5288] and [RFC5289] can be considered
   sufficiently strong for most uses.

Note that the reference to [RFC4492] and [RFC5246] is specifically excluding all RC4 and CBC-mode cipher suites.

One good consequence of this change, besides the improved security, is that it may help us make progress on bug 940787.
Attachment #8534484 - Flags: review?(dkeeler)
Comment on attachment 8534484 [details] [diff] [review]

Review of attachment 8534484 [details] [diff] [review]:

::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +979,5 @@
>    }
> +  // Prevent downgrade attacks on the symmetric cipher. We do not allow CBC
> +  // mode due to BEAST, POODLE, and other attacks on the MAC-then-Encrypt
> +  // design.

Maybe also include a reference to either this bug or the RFCs referenced in comment 0?
Attachment #8534484 - Flags: review?(dkeeler) → review+

I included a reference to this bug in the comment, as you suggested. Thanks for the quick review!
Closed: 5 years ago
Resolution: --- → FIXED
Comment on attachment 8534484 [details] [diff] [review]

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 #8534484 - Flags: approval-mozilla-aurora?
Attachment #8534484 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Should this be part of the release notes?
relnote-firefox: --- → ?
As per comment 5, do you think this change should be relnoted in 36?
Flags: needinfo?(brian)
Yes, the changes to the false start behavior should be documented in the "what's new/changed for  Developers" documentation.
Flags: needinfo?(brian)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #8)
> Yes, the changes to the false start behavior should be documented in the
> "what's new/changed for  Developers" documentation.

Thanks for confirming. Can you suggest the wording for the note?
Flags: needinfo?(brian)
"Firefox will only attempt the TLS False Start optimization if the server chooses a cipher suite that uses the AEAD construction--either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Both of these cipher suites require TLS 1.2."
Flags: needinfo?(brian)
Actually, s/Both of these/These/.
Can I shorten that note as

"TLS False Start optimization now requires a cipher suite using AEAD construction"

Do you have a link to documentation about this that I can reference for the additional details?
Flags: needinfo?(brian)
Sure. And, I don't have a link to a document.
Flags: needinfo?(brian)
Thanks. Release note added to desktop and mobile.
You need to log in before you can comment on or make changes to this bug.