Closed
Bug 593080
Opened 15 years ago
Closed 14 years ago
Change the default of the SSL_ENABLE_SSL2 option to PR_FALSE
Categories
(NSS :: Libraries, defect, P1)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
FIXED
3.13
People
(Reporter: wtc, Assigned: wtc)
Details
Attachments
(1 file)
4.19 KB,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
The default value of the SSL_ENABLE_SSL2 option is PR_TRUE:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslsock.c&rev=1.68&mark=165,172#165
I propose we change the default to PR_FALSE. I'd like to
make this change on the NSS trunk (NSS 3.13) first.
Comment 1•15 years ago
|
||
This is a break in backwards compatibility.
It is not the only such change I would make.
I would also enable many SSL3/TLS cipher suites by default.
I wonder if we should declare this to be NSS 4.0 to make these changes.
Assignee | ||
Comment 2•14 years ago
|
||
Bob: the patch is simple, but please evaluate the implications
(shown by the changes to the NSS SSL test programs) carefully.
While writing this patch, I discovered three issues.
1. The default of the closely-related option
SSL_V2_COMPATIBLE_HELLO also needs to be changed to be
consistent.
2. strsclnt relies on the facts that SSL_ENABLE_SSL2
is default on, and that turning off SSL_V2_COMPATIBLE_HELLO
also turns off SSL_ENABLE_SSL2, so it calls SSL_OptionSet
on SSL_V2_COMPATIBLE_HELLO only. In the new world, that
call won't be able to turn on SSL_ENABLE_SSL2.
I changed it to also call SSL_OptionSet on SSL_ENABLE_SSL2.
3. All of the three SSL test programs turn on SSL 2.0 by
default and provide a command-line option to disable SSL 2.0.
I didn't change that because it is confusing to change the
meaning of those command-line options.
Attachment #565316 -
Flags: review?(rrelyea)
Assignee | ||
Updated•14 years ago
|
Priority: P2 → P1
Comment 3•14 years ago
|
||
Comment on attachment 565316 [details] [diff] [review]
Proposed patch
r+
If we have a problem with this, we'll probably add an environment variable to tweek this, but for now I think this patch is fine. Any app that has explicit controls can still turn things on if they want.
bob
Attachment #565316 -
Flags: review?(rrelyea) → review+
Assignee | ||
Comment 4•14 years ago
|
||
Patch checked in on the NSS trunk (NSS 3.13).
Checking in cmd/strsclnt/strsclnt.c;
/cvsroot/mozilla/security/nss/cmd/strsclnt/strsclnt.c,v <-- strsclnt.c
new revision: 1.70; previous revision: 1.69
done
Checking in cmd/tstclnt/tstclnt.c;
/cvsroot/mozilla/security/nss/cmd/tstclnt/tstclnt.c,v <-- tstclnt.c
new revision: 1.64; previous revision: 1.63
done
Checking in lib/ssl/ssl.h;
/cvsroot/mozilla/security/nss/lib/ssl/ssl.h,v <-- ssl.h
new revision: 1.44; previous revision: 1.43
done
Checking in lib/ssl/sslsock.c;
/cvsroot/mozilla/security/nss/lib/ssl/sslsock.c,v <-- sslsock.c
new revision: 1.74; previous revision: 1.73
done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•