84218 - Edit Cipher button and SSL CipherSuite window not lockable

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P2)

Description

[Rodney Velasco]

In the General Preference window under the Privacy and Security Category -> SSL,
the Edit Cipher button and Edit Cipher Window Elements are not lockable. 
According to eclient spec, all preferences in general pref area should be
lockable.  There is no way to lock down SSL2 and SSL3 Ciphersuites on the
browser.  This is a requirement for eclient.  eddyk already aware of this issue.

Comment 1

[Rodney Velasco]

my component, I'll QA this...adding sarah to Cc.

Comment 2

[Rodney Velasco]

Info regarding pref locking can be found on this newsgroup posting
news://news.mozilla.org/3AC8F5D2.6CA02623%40netscape.com

Comment 3

[Bob Lord]

SSL prefs are handled by PSM.  Changing product to PSM.

Comment 4

[Bob Lord]

-> 2.0, P3

We're over the limit for bugs for PSM 2.0, so this might slip past PSM 2.0 into
PSM 2.1.

Comment 5

[Rodney Velasco]

can I reassign this bug to you (bob lord) or someone in your group?  eddy's
pretty bogged down with a bunch of pref locking bugs.

Comment 6

[Bob Lord]

-> ssaux to re-assign

Comment 7

[Stephane Saux]

-> ddrinan
-> p3 to not add to RTM list.

Comment 8

[Rodney Velasco]

adding nsenterprise keyword

Comment 9

[Stephane Saux]

Mass reassigning target to 2.1

Comment 10

[Bob Lord]

I'd like to bump up the priority of this bug since the enterprise client will
need this.

p3 -> p2

Comment 11

[Stephen Walker]

Attachment: patch

Comment 12

[Stephane Saux]

adding patch and review keywords.
Rodney, can you review as well.

Comment 13

[eddyk]

Comment on the checkbox changes in pref-ciphers.xul:

The addition of the preftype and prefattribute are not necessary since
pref-ciphers.xul does its own handling of the elements (functions onLoad() and
doOK()).

Those are necessary when nsPrefWindow (in
xpfe/components/prefwindow/resources/content/nsPrefWindow.js) is being used to
handle the window, but this dialog box does not.

It doesn't hurt to have these additional attributes; it's just not necessary.


The change in pref-ssl.xul is necessary, and looks correct.

Comment 14

[eddyk]

Note that this bug should probably be closed due to the checking for bug 91978 

Comment 15

[Rodney Velasco]

marking as resolved fix per eddyk's last comment.

Comment 16

[Stephane Saux]

I don't think that disabling the ability to open the pref-ciphers.xul  window is
equivalent to locking the preferences for individual ciphers.  It could be that
somebody may want to let the user choose to turn ssl2 on and off but not TLS

To do that, the fix to bug 91978 doesn't help, and we need this fix.

Reopening.

Comment 17

[eddyk]

Sorry, there was probably too much clutter in one bug (91978)

There is indeed code to disable individual checkboxes in the pref-cipher.xul
dialog box.

From the diff:
Index: pref-ciphers.xul
===================================================================
RCS file: /cvsroot/mozilla/security/manager/pki/resources/content/pref-ciphers.xul,v
retrieving revision 1.2
diff -u -r1.2 pref-ciphers.xul
--- pref-ciphers.xul	2001/07/09 19:03:17	1.2
+++ pref-ciphers.xul	2001/07/24 05:21:49
@@ -55,6 +55,10 @@
         } catch(e) { /* Put debug output here */ }
 
         element.setAttribute("checked", prefValue);
+        // disable xul element if the pref is locked.
+        if (prefs.PrefIsLocked(prefString)) {
+          element.disabled=true;
+        }
       }
     }



So as long as the prefstring attribute in pref-ciphers.xul is correct, and the
pref backend lets us know via PrefIsLocked, we'll disable that element.

If I misunderstood the issue, or am wrong on this, please reopen.  Thanks

Comment 18

[Stephane Saux]

My mistake indeed. Thanks for the clarification.

Comment 19

[Hong Kwon]

Huh?  Last I checked Stephane you were engineering, not QA ;-)

Reopening and marking RESOLVED so QA can verify.

Comment 20

[Hong Kwon]

marking resolved again

Comment 21

[Rodney Velasco]

button for preference 
lockPref("security.disable_button.editSSLCiphers", true) 
is now lockable with current trunk builds.

Tested on 
2001080804 Win2K
2001081308 Linux
2001081308 Mac

SSL Edit Ciphersuites are now lockable as well using the follwing lockPref
functions...

lockPref("security.ssl2.rc4_128", true); 
lockPref("security.ssl2.des_64", true); 
lockPref("security.ssl2.des_ede3_192", true); 
lockPref("security.ssl2.rc2_128", true); 
lockPref("security.ssl2.rc2_40", true); 
lockPref("security.ssl2.rc4_40", true); 
lockPref("security.ssl3.rsa_rc4_128_md5", true); 
lockPref("security.ssl3.rsa_fips_des_ede3_sha", true);
lockPref("security.ssl3.rsa_des_ede3_sha", true);
lockPref("security.ssl3.rsa_fips_des_sha", true); 
lockPref("security.ssl3.rsa_des_sha", true);
lockPref("security.ssl3.rsa_1024_rc4_56_sha", true);
lockPref("security.ssl3.rsa_1024_des_cbc_sha", true);
lockPref("security.ssl3.rsa_rc4_40_md5", true);
lockPref("security.ssl3.rsa_rc2_40_md5", true); 
lockPref("security.ssl3.rsa_null_md5", false); 

Marking Verified

Comment 22

[Rodney Velasco]

Attachment: CFG to lock down SSL2 and SSL3 cipher suite