368130 - Bogus "SSL is disabled" error when SSL3 is disabled

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

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]

Attachment: think before retrying

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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:]]

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)]

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]

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)]

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

http://hg.mozilla.org/mozilla-central/rev/742724972407

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Did this fix make it into FF 3.5?

Comment 9

[Honza Bambas (:mayhemer)]

(In reply to comment #8)
> Did this fix make it into FF 3.5?

No.

Comment 10

[Samuel Sidler (old account; do not CC)]

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]]

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]]

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)]

Comment on attachment 354572 [details] [diff] [review]
think before retrying

Not for 1.9.1.2.

Comment 14

[Daniel Veditz [:dveditz]]

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)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d190462f9366

Comment 16

[Al Billings [:abillings - ex-MoCo]]

Is there a server and a clear verification scenario to test that this issue is fixed within QA?

Comment 17

[Kai Engert [:KaiE:]]

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