Closed
Bug 284450
Opened 20 years ago
Closed 19 years ago
Only use SSL V2 compatible hello, if SSL V2 is enabled
Categories
(Core :: Security: PSM, enhancement)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dftapusk, Assigned: KaiE)
References
Details
(Keywords: fixed1.8.1)
Attachments
(1 file, 1 obsolete file)
1.26 KB,
patch
|
jgmyers
:
review+
nelson
:
review+
KaiE
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
When SSL 2.0 is disabled in Firefox it still sends a V2 compatible Client Hello
message when starting an SSL connection. There are a couple of problems with
this in that the CLIENT_RANDOM is 16 bytes so the server would have to pad the
client random that it generates for the PRF with zeros to the left. Second it
doesn't follow what the RFC indicates that v2 should be phased out. Now IE only
sends a SSLv2 CLIENT_HELLO only when v2 is enabled; otherwise it will send an
SSL 3.0/TLS1.0 CLIENT_HELLO. This should be a simple change;
ssl_defaults.v2CompatibleHello just has to be set to off if v2 is disabled.
Reproducible: Always
Steps to Reproduce:
1. Ensure SSLv2 is disabled
2. Run Ethereal and capture output; connect to https website.
3. View captured log and view v2 client hello.
Actual Results:
Capture log indicates v2 client hello was used.
Expected Results:
Don't use v2 client hello; use v3 client hello instead. This mirrors the
behaviour IE demonstrates and the move in stated in RFC 2246.
Warning: The ability to send Version 2.0 client hello messages will be
phased out with all due haste. Implementors should make every
effort to move forward as quickly as possible. Version 3.0
provides better mechanisms for moving to newer versions.
Updated•20 years ago
|
Assignee: firefox → kaie
Component: General → Client Library
Product: Firefox → PSM
QA Contact: general
Comment 1•20 years ago
|
||
This simple (one liner) patch only honours ->v2CompatibleHello iff ->enableSSL2
is also true. (Or in english, do v3/TLS handshakes if SSLv2 is disabled)
Attachment #182052 -
Flags: review?(kaie)
Assignee | ||
Comment 2•20 years ago
|
||
SSL is product NSS.
Assignee: kaie → wtchang
Component: Security: UI → Libraries
Product: Core → NSS
QA Contact: bishakhabanerjee
Version: Other Branch → unspecified
Assignee | ||
Comment 3•20 years ago
|
||
Comment on attachment 182052 [details] [diff] [review]
Don't use SSLv2 Hello's when SSLv2 is disabled.
Please ask SSL expert nelson@bolyard.com for his thoughts on your patch.
Attachment #182052 -
Flags: review?(kaie)
Comment 4•20 years ago
|
||
Nelson, could you take a look at this?
I verified that the patch does what it
intends to do, but I don't know if we
really want to do that. Using LXR, I verified
that the code the patch modified is the only
place in NSS where we test the v2CompatibleHello
field.
We may also want to review the code in
SSL_OptionSet and SSL_OptionSetDefault
that attempts to keep enableSSL2 and
v2CompatibleHello consistent. Perhaps
that code could be enhanced to keep those
two fields more (fully?) consistent.
For example, right now if you set
enableSSL2 to true, we automatically set
v2CompatibleHello to true. The attached
patch would not be needed if we did the
same when you set enableSSL2 to false.
Finally, I found that our tstclnt test
program keeps its enableSSL2 and v2CompatibleHello
options fully in sync:
http://lxr.mozilla.org/security/source/security/nss/cmd/tstclnt/tstclnt.c#702
Assignee: wtchang → nelson
Comment 5•20 years ago
|
||
Comment on attachment 182052 [details] [diff] [review]
Don't use SSLv2 Hello's when SSLv2 is disabled.
The ability to continue to use SSL2-compatible client hellos,
even when SSL2 is disabled is a correct and necessary feature
of NSS for clients that want the feature. This patch would
disable the ability of SSL3 clients to send ssl2-compatible
hellos for all clients, and therefore is unacceptable.
NSS provides a way for the application to disable SSL2 client
hellos through an SSL socket option, if the application does not
want SSL2 compatible hellos. That feature works, and has worked
for over 6 years.
If some application does not want SSL2-compatible client hellos,
that application must turn them off. No change to NSS/SSL is
needed.
Attachment #182052 -
Flags: review-
Comment 6•20 years ago
|
||
Apparently this is a request for a change to the FireFox application,
asking that it disable the SSL2-compatible behavior of SSL3 (which is
part of the SSL3 and TLS specifications) when SSL2 is disabled.
If FF wants that behavior, FF can enable it. No change to NSS is needed.
I am changing this to be a PSM bug, since PSM is the module by which FF
interfaces to NSS.
Assignee: nelson → kaie
Severity: normal → enhancement
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: bishakhabanerjee
Version: unspecified → Trunk
Comment 7•19 years ago
|
||
Confirming.
Assignee | ||
Comment 8•19 years ago
|
||
This patch proposes the following logic for PSM:
If SSL 2 is disabled, disable SSL 2 compatible client hellos.
Only if SSL 2 is enabled, we enable SSL 2 compatible client hellos.
As Firefox meanwhile has SSL 2 disabled by default, this change will disable SSL 2 compatible client hellos by default, too.
Attachment #182052 -
Attachment is obsolete: true
Attachment #215778 -
Flags: review?(rrelyea)
Updated•19 years ago
|
Attachment #215778 -
Flags: review?(rrelyea) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #215778 -
Flags: approval-branch-1.8.1+
Assignee | ||
Updated•19 years ago
|
Summary: SSL Client Hello always uses V2 compatible hello → Only use SSL V2 compatible hello, if SSL V2 is enabled
Assignee | ||
Comment 9•19 years ago
|
||
As of today, https://mel.np.edu.sg/ is a site that supports SSL v2 only.
Using that site and the patch in this bug, I verified that connecting to SSL v2 sites is still possible, when having SSL v2 (explicitly) enabled.
Updated•19 years ago
|
Attachment #215778 -
Flags: review+
Assignee | ||
Comment 10•19 years ago
|
||
Thanks to Nelson for providing additional background info per email.
Thanks for the reviews.
Checked in to trunk and 1.8 branch.
Assignee | ||
Comment 11•19 years ago
|
||
Please see bug 343230 for an enhancement related to this bug.
Blocks: 343230
You need to log in
before you can comment on or make changes to this bug.
Description
•