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
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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
