Updated NSS in Rawhide to the upstream's NSS_3_13_RC0 and with it NSPR to NSPR_4.9_BETA3.
The bug fixes in NSPR 4.9 BETA3 and NSS 3.18 RC0 can be found by these Bugzilla queries: For nspr: https://bugzilla.mozilla.org/buglist.cgi?order=Importance&resolution=FIXED&classification=Components&query_format=advanced&product=NSPR&target_milestone=4.9&list_id=1467991 and for nss: https://bugzilla.mozilla.org/buglist.cgi?order=Importance&resolution=FIXED&classification=Components&query_format=advanced&product=NSS&target_milestone=3.13&list_id=1468013 Of particular importance is the fix for (CVE-2011-3389) Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76) https://bugzilla.mozilla.org/show_bug.cgi?id=665814 To quote from the ssl patch itself: ------ For SSL 3.0 and TLS 1.0, by default we prevent chosen plaintext attacks on SSL CBC mode cipher suites (see RFC 4346 Section F.3) by splitting non-empty application_data records into two records; the first record has only the first byte of plaintext, and the second has the rest. This only prevents the attack in the sending direction; the connection may still be vulnerable to such attacks if the peer does not implement a similar countermeasure. This protection mechanism is on by default; the default can be overridden by setting NSS_SSL_CBC_RANDOM_IV=0 in the environment prior to execution, and/or by the application setting the option SSL_CBC_RANDOM_IV to PR_FALSE. The per-record IV in TLS 1.1 and later adds one block of overhead per record, whereas this hack will add at least two blocks of overhead per record, so TLS 1.1+ will always be more efficient. Other implementations (e.g. some versions of OpenSSL, in some configurations) prevent the same attack by prepending an empty application_data record to every application_data record they send; we do not do that because some implementations cannot handle empty application_data records. Also, we only split application_data records and not other types of records, because some implementations will not accept fragmented records of some other types (e.g. some versions of NSS do not accept fragmented alerts). ------ The NSS team would greatly appreciate any feedback, specially regarding compatiblity issues with various sites. Thank you, Elio Maldonado
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel