Description of problem: Due to https://bugzilla.redhat.com/show_bug.cgi?id=770682, the 1/n-1 record split which is needed to protect against BEAST on CBC suites was disabled globally on NSS. Firefox (and Thunderbird) should enable the workaround by default. Version-Release number of selected component (if applicable): firefox-23.0.1-4.fc19.x86_64 nss-3.15.1-3.fc19.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Disable all RC4 suites in about:config, or choose a https server which does not force RC4 to be preferred. 2. Connect to the https server. 3. Verify (using Wireshark) that a block cipher was chosen, and that the Application Data records sent by the browser were not split. Actual results: The browser sends a single Application Data record. Expected results: The browser sends a pair of Application Data records, the first one with length 32, the second one with the rest of the data. Additional info: Recompiling nss with patch 29 commented out (nss-ssl-cbc-random-iv-off-by-default.patch) fixes the bug, but probably reintroduces bug 770682. It seems to be possible for firefox to force the workaround to be enabled, even if it is off by default. A comment at https://bugzilla.mozilla.org/show_bug.cgi?id=723109 mentions a SSL_OptionSet function which appears to be able to disable or enable the workaround directly. Another option would be to fudge the environment before calling any function of the NSS library, forcing NSS_SSL_CBC_RANDOM_IV=1 on the environment unless it already has a NSS_SSL_CBC_RANDOM_IV with any value. This bug report is about firefox, since I did not test thunderbird; a similar bug report could be made about it. For thunderbird, see also https://bugzilla.mozilla.org/show_bug.cgi?id=723109.
(In reply to Cesar Eduardo Barros from comment #0) > Recompiling nss with patch 29 commented out > (nss-ssl-cbc-random-iv-off-by-default.patch) fixes the bug, but probably > reintroduces bug 770682. CCing NSS maintainer to see when we're finally dropping that patch. It is still applied in F19, I though it was supposed to be gone by now. > It seems to be possible for firefox to force the workaround to be enabled, > even if it is off by default. A comment at > https://bugzilla.mozilla.org/show_bug.cgi?id=723109 mentions a SSL_OptionSet > function which appears to be able to disable or enable the workaround > directly. Another option would be to fudge the environment before calling > any function of the NSS library, forcing NSS_SSL_CBC_RANDOM_IV=1 on the > environment unless it already has a NSS_SSL_CBC_RANDOM_IV with any value. This is already done in firefox and thunderbird packages in Red Hat Enterprise Linux 5 and 6 using the following in the launcher shell script: # BEAST fix (rhbz#838879) NSS_SSL_CBC_RANDOM_IV=${NSS_SSL_CBC_RANDOM_IV-1} export NSS_SSL_CBC_RANDOM_IV https://bugzilla.redhat.com/show_bug.cgi?id=737506#c36 https://bugzilla.redhat.com/show_bug.cgi?id=838879
Fedora 18 is also affected.
I bit of information from the nss side of things. The nss disabling patch is not applied on Rawhide or f20, onlt applied on stable branches. After we branch Rawhide for the next fedora release and we enter in Alpha, I send emails to the fedora development mailing list telling them that NSS_SSL_CBC_RANDOM_IV=1 will be the default as they use updates-testing and ask for feedback on whether it causes problems. Twice they have said it still causes problems. There are still unpatches servers out there. Once we go beta I have to enable the patch again. f20 is entering Alpha soon so I'll send that email again. I know this bug is for Firefox but I though worth informing you that we monitor this every six months for nss.
Elio, sorry but this is backwards. The default should be secure, and then if some applications tiull have issues they can add setenv("NSS_SSL_CBC_RANDOM_IV", "0", 1); as a patch until things work. We shouldn't make *all* applications vulnerable because a handful have issues.
See https://fedorahosted.org/fesco/ticket/1181 and the fesco meeting log. We'd like this to be applied in F20 and also as an update to F19 to go into updates-testing. I think this probably also could use a release note. Elio, do you have some text for that? On the devel mailing list you note: > Also, the notes in the Bodhi update should be very clear and explain that > user that, for reasons of compatibility, needs to opt out of the more > secure default can do so by setting the environment variable > NSS_SSL_CBC_RANDOM_IV=0. Is there anything more to say?
Please note that this bug is about Firefox. I'll update Firefox/Thunderbird with the BEAST workaround we already have in RHEL: # BEAST fix (rhbz#838879) NSS_SSL_CBC_RANDOM_IV=${NSS_SSL_CBC_RANDOM_IV:-1} export NSS_SSL_CBC_RANDOM_IV For other packages or default NSS setup please file another bug.
Actually, the right one is ${NSS_SSL_CBC_RANDOM_IV-1} because we don't want to perform null test.