(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #352282 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=352282 Imported into Bugzilla on 05/16/99 11:33) When you start picking up NSS 2.6, disable the SSL_V2_COMPATIBLE_HELLO flag using SSL_Enable() for outgoing IMAP and SMTP client connections which use SSL.

Since this is security-related, I've marked this bug "only people in 'Netscape Confidential' can see this bug". SSL IMAP and SMTP are currently "out" for 5.0. Reassigning to mscott and resolving Later.

verifying as later then.

Moving all Mail/News Networking bugs to Mail/News Networking-Mail This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will fix those bugs.

REMIND and LATER are going away and are no longer legal resolutions. Reopening for proper resolution per Asa Dotzler. If this bug has been dealt with, please re-resolve it with the correct resolution. If it has not, and you still want it off your current buglist, please set the target milestone to Future.

Not security critical, making public.

--> IMAP.

is this still valid? Is this handled in Necko?

I believe SSL V2 is disabled by default http://mxr.mozilla.org/seamonkey/source/netwerk/base/public/security-prefs.js#3 and nss disables ssl_v2_compatible_hello if that pref is false, so I'm marking this wfm. http://mxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSComponent.cpp#1591 Please re-open if I'm wrong.

Even when SSL2 is disabled, there are still some circumstances in which PSM may use an SSL2 compatible client hello. See http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp&rev=1.160#3138 SSL3 (and TLS) support a backward compatible SSL2-format client hello, so even when SSL2 is disabled, it is possible to send SSL3/TLS client hellos in SSL2 format. PSM configures NSS to do that in just one situation. Some SSL3.0 servers get completely confused when they see a TLS client hello. When that happens, instead of correctly negotiating an SSL 3.0 connection, they fail in any of a number of bizarre ways. We call then "TLS intolerant" servers. PSM implements a "fall back" strategy for trying to succeed with TLS intolerant servers. When PSM attempts to connect with a TLS client hello and the server fails to succesfully complete either an SSL 3.0 handshake or a TLS handshake, PSM falls back to using the client hello format that was used in Mozilla clients browsers before FF2, which is to send an SSL 3.0 client hello in SSL2 compatible format. The only exception to this fallback strategy is when trying to initiate an SSL/TLS handshake during an IMAP, POP3 or SMTP session using the "StartTLS" feature of those protocols. PSM does not fall back to SSL2-compatible client hellos in those cases, because (we believe) all servers that support StartTLS understand SSL3 format client hellos. PSM has been doing that TLS intolerant server fallback strategy since FF2. There is some debate about whether we should now stop using SSL2 compatible client hellos for TLS intolerant fallback. We _could_ just fallback to sending SSL 3.0 client hellos in SSL3's own format. Unfortunately, we don't have any statistics about what percentage of our users are still effectively relying on this fall back logic, so we don't know how much of an undesirable effect there might be to such a change. :( In any event, I think John Myer's original request was effectively satisfied when we shipped FF3, which did not use SSL2-compatible client hellos, except in the TLS intolerant server fallback case.

thx, Nelson - marking verified.