1642098 - Firefox Nightly has added support for raw RSA key exchange with no way to disable.

Status: RESOLVED DUPLICATE of bug 1641356

(Core :: Security: PSM, defect)

Description

[George [:fozzie]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Visit https://www.howsmyssl.com/, scroll down to see:

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

Actual results:

On a recent version of Firefox Nightly there has been support added for:

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

Even if I disable security.ssl3.rsa_aes_128_sha & security.ssl3.rsa_aes_256_sha it does not disable these ciphers.

There are no additional ssl3 cipher suite options added to disable these ciphers.

Here is my about:config configuration https://cdn.fozzie.space/pWUL9ukpZZRv5Q4Q/qZ9ATHDUh8ws7SPP.png and the test results https://cdn.fozzie.space/JZL9T24B8LXKrsNY/LsYaf9mPsuFUNUjh.png

Expected results:

The following ciphers should have been disabled:
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

This is not reproducible in the latest stable version of Firefox.

Comment 1

[:Gijs (back August 25; he/him)]

Keeping this confidential but not sec-sensitive; it's unclear to me why this bug would need to be sec-sensitive.

As a non-expert, doing some initial triage, the list at https://hg.mozilla.org/mozilla-central/file/tip/security/nss/lib/ssl/ssl3con.c#l150,152 doesn't appear to have changed since 2018 (you can select the range of lines and ask hg for logs for just that range, the first entry was pushed 2018-11-15 09:54 +0000 .

Are you sure this is about ssl3? And when do you think this regressed on nightly? Mozregression should be able to find a regression range.

Comment 2

[George [:fozzie]]

I visited the website last on 23/05/2020 so 7 days ago, I don't know when exactly this has been added but it's between 23/05/2020 and today.

If I use the exact same about:config test on the latest stable build of Firefox these are the results:
https://cdn.fozzie.space/jtrBeBSTeSdd9icN/keKscWXYkiwj6Y56.png

I added the security tag as the user has knowingly disabled these weaker ciphers and they have been reenabled with no way to disable them.

Comment 3

[Thyla van der Merwe]

Please see Bug 1638369 and Bug 1641356.

Comment 5

[Nathan Froyd [:froydnj]]

Attachment: Bug 1642098 - move linux base toolchain builds to their own file; r=#build

The explanatory comment at the top of the new file provides some context.
The larger motivating context here is wanting to use job-defaults to clean
up the toolchain fetches for the Linux build jobs. But if we did that, we
run into the problem that such fetches are merged with whatever the
individual job(s) specify for their toolchain fetches, not replaced. So
we'd wind up with multiple clang toolchains being downloaded, or similar,
and things would go downhill from there, as workers attempt to unpack those
things to the same location (which is bad) or perhaps error out (which is
also bad).

This change therefore paves the way for providing job-defaults in linux.yml.

Comment 6

[Phabricator Automation]

Comment on attachment 9162883 [details]
Bug 1642098 - move linux base toolchain builds to their own file; r=#build

Revision D83158 was moved to bug 1652098. Setting attachment 9162883 [details] to obsolete.