NSS updated on Rawhide to NSS_3_13_RC0 (CVE-2011-3389)

[Elio Maldonado]

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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20111010/39edba74/attachment.html