Last Comment Bug 368130 - Bogus "SSL is disabled" error when SSL3 is disabled
: Bogus "SSL is disabled" error when SSL3 is disabled
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla1.9.2a1
Assigned To: timeless
:
:
Mentors:
https://www.bmo.com/
Depends on:
Blocks: fips 297327
  Show dependency treegraph
 
Reported: 2007-01-24 16:20 PST by Nelson Bolyard (seldom reads bugmail)
Modified: 2009-09-16 17:45 PDT (History)
10 users (show)
samuel.sidler+old: wanted1.9.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.4-fixed


Attachments
think before retrying (841 bytes, patch)
2008-12-27 15:15 PST, timeless
kaie: review+
dveditz: approval1.9.1.4+
Details | Diff | Splinter Review

Description Nelson Bolyard (seldom reads bugmail) 2007-01-24 16:20:10 PST
or: PSM should not attempt TLS-intolerance fallback when SSL3 is disabled

or: PSM should not disable TLS when only TLS is enabled

Users trying to operate in FIPS mode disable SSL 3.0, leaving only TLS 1.0
(a.k.a. SSL 3.1) enabled, and they disable all but the 3DES and AES cipher
suites.

In that configuration, if they visit a server that fails to complete a 
TLS handshake, PSM attempts its fallback recovery for TLS intolerant 
servers.  It disables TLS, and tries again.  

But since TLS was the ONLY version of SSL that had previously been enabled,
when PSM disables TLS, there are NO versions of SSL left enabled.  
Consequently, the attempt to redo the connection/handshake after disabling
TLS results is libSSL reporting 
SSL_ERROR_SSL_DISABLED 	-12268 	"Cannot connect: SSL is disabled."

This is bad because it suggests a configuration error to the user, when
in fact that's not the problem.  In this case, PSM should not disable TLS
and retry, but rather should report the failure with the error code from
the first failed connection/handshake.

This is the cause of ONE of the symptoms reported in bug 297327
Comment 1 timeless 2008-12-27 15:15:00 PST
Created attachment 354572 [details] [diff] [review]
think before retrying
Comment 2 Nelson Bolyard (seldom reads bugmail) 2008-12-28 22:59:41 PST
Comment on attachment 354572 [details] [diff] [review]
think before retrying

This change looks to me like it should work, but I am not a peer of the PSM module, so I must pass the review request to someone who is.
Comment 3 Kai Engert (:kaie) 2009-01-06 06:46:17 PST
Comment on attachment 354572 [details] [diff] [review]
think before retrying

r=kaie

Having Nelson's confirmation on this plan (already done) is sufficient to commit.
Comment 4 Marcin Cieślak (:saper) 2009-01-09 15:40:12 PST
What about using TLSv1 only with STARTTLS extensions of various protocols? 
I think that TLS intolerance is related only to the quite old servers that didn't implement STARTTLS. UW IMAPD for example bails out on STARTTLS attempt with SSL23 client hello message. 

Those days after STARTTLS following things usually happen (SMTP example):

#1:

   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250 STARTTLS
   C: STARTTLS
   S: 220 Go ahead

 <TLSv1 negotiation succeeds>

Should we handle SSLv23 or SSL3 compatibility client hellos here at all? 
I am not sure.

#2:

   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250 STARTTLS
   C: STARTTLS
   S: 454 TLS not available due to temporary reason

This usually means somebody forgot to install keys/certificates 
(this is the sendmail behaviour)

#3
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250 STARTTLS
   C: STARTTLS 

  Connection gets dropped (closed or reset). Usually means the same
  as above, but with buggy MTA, for example I've seen exim behaving this way.


Anyway, some more detailed diagnostic about what happens would be better in any case....
Comment 5 timeless 2009-01-12 02:40:30 PST
i'd like to keep this bug focussed on what turned out to be a fairly easy to implement change.

specifically it's requesting that if a user configures *off* support for SSL2/SSL3, we don't try them after TLS fails. Whether a user should actually configure off SSL2/SSL3 is beyond the scope of this bug.
Comment 6 Nelson Bolyard (seldom reads bugmail) 2009-01-12 13:57:17 PST
(In reply to comment #5)
> it's requesting that if a user configures *off* support for SSL2/SSL3, we 
> don't try them after TLS fails. 

Not exactly.  It requests that, if TLS is the only protocol version enabled,
then we don't disable it and try again when TLS fails.
Comment 7 Phil Ringnalda (:philor) 2009-01-15 20:32:01 PST
http://hg.mozilla.org/mozilla-central/rev/742724972407
Comment 8 Nelson Bolyard (seldom reads bugmail) 2009-06-29 14:10:21 PDT
Did this fix make it into FF 3.5?
Comment 9 Honza Bambas (:mayhemer) 2009-06-29 14:14:13 PDT
(In reply to comment #8)
> Did this fix make it into FF 3.5?

No.
Comment 10 Samuel Sidler (old account; do not CC) 2009-07-09 18:48:14 PDT
Is there a reason this needs to _block_ 1.9.1.1 or can we take it in 1.9.1.2 (a month or two away)? I'm leaning towards 1.9.1.2, but feel free to convince me otherwise...
Comment 11 Daniel Veditz [:dveditz] 2009-07-10 11:26:35 PDT
This isn't going to "block" a release, but if someone wants to champion this please request branch approvals on the patch for the branches you want to land this.
Comment 12 Reed Loden [:reed] (use needinfo?) 2009-07-23 23:18:44 PDT
Comment on attachment 354572 [details] [diff] [review]
think before retrying

This still applies (just offset 111 lines).
Comment 13 Samuel Sidler (old account; do not CC) 2009-07-29 12:10:02 PDT
Comment on attachment 354572 [details] [diff] [review]
think before retrying

Not for 1.9.1.2.
Comment 14 Daniel Veditz [:dveditz] 2009-08-25 16:58:29 PDT
Comment on attachment 354572 [details] [diff] [review]
think before retrying

Approved for 1.9.1.4, a=dveditz for release-drivers

Let's try to get this one landed this time.
Comment 15 Phil Ringnalda (:philor) 2009-08-25 20:07:13 PDT
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d190462f9366
Comment 16 Al Billings [:abillings] 2009-09-14 15:16:04 PDT
Is there a server and a clear verification scenario to test that this issue is fixed within QA?
Comment 17 Kai Engert (:kaie) 2009-09-16 17:45:00 PDT
You need a TLS-intolerant server for testing, I guess the one mentioned in bug's URL field is such a server? https://www.bmo.com/

Use about:config and disable ssl3 for testing

Note You need to log in before you can comment on or make changes to this bug.