Bogus "SSL is disabled" error when SSL3 is disabled

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Core
Security: PSM
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: timeless)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.9.2a1
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(status1.9.1 .4-fixed)

Details

(URL)

Attachments

(1 attachment)

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
(Reporter)

Updated

11 years ago
Summary: Bogus "SSL is disabled" error while in FIPS mode → Bogus "SSL is disabled" error when SSL3 is disabled
QA Contact: psm

Updated

9 years ago
Blocks: 157795
(Assignee)

Updated

9 years ago
Version: 1.8 Branch → Trunk
(Assignee)

Comment 1

9 years ago
Created attachment 354572 [details] [diff] [review]
think before retrying
Assignee: kaie → timeless
Status: NEW → ASSIGNED
Attachment #354572 - Flags: review?(nelson)
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.
Attachment #354572 - Flags: review?(nelson) → review?(kaie)

Comment 3

9 years ago
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.
Attachment #354572 - Flags: review?(kaie) → review+
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....
(Assignee)

Comment 5

9 years ago
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.
(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.
http://hg.mozilla.org/mozilla-central/rev/742724972407
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Did this fix make it into FF 3.5?
(Reporter)

Updated

8 years ago
Flags: wanted1.9.1.x?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1.1?
(In reply to comment #8)
> Did this fix make it into FF 3.5?

No.
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...
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x+
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.13?
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.
Flags: blocking1.9.1.1?
Flags: blocking1.9.0.13?
Comment on attachment 354572 [details] [diff] [review]
think before retrying

This still applies (just offset 111 lines).
Attachment #354572 - Flags: approval1.9.1.2?
status1.9.1: --- → wanted
Flags: wanted1.9.1.x+
Comment on attachment 354572 [details] [diff] [review]
think before retrying

Not for 1.9.1.2.
Attachment #354572 - Flags: approval1.9.1.2? → approval1.9.1.3?
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.
Attachment #354572 - Flags: approval1.9.1.3? → approval1.9.1.4+
Keywords: checkin-needed
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d190462f9366
status1.9.1: wanted → .4-fixed
Keywords: checkin-needed
Is there a server and a clear verification scenario to test that this issue is fixed within QA?

Comment 17

8 years ago
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
You need to log in before you can comment on or make changes to this bug.