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
Created attachment 354572 [details] [diff] [review] think before retrying
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 on attachment 354572 [details] [diff] [review] think before retrying r=kaie Having Nelson's confirmation on this plan (already done) is sufficient to commit.
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....
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.
Did this fix make it into FF 3.5?
(In reply to comment #8) > Did this fix make it into FF 3.5? No.
Is there a reason this needs to _block_ 184.108.40.206 or can we take it in 220.127.116.11 (a month or two away)? I'm leaning towards 18.104.22.168, but feel free to convince me otherwise...
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 on attachment 354572 [details] [diff] [review] think before retrying This still applies (just offset 111 lines).
Comment on attachment 354572 [details] [diff] [review] think before retrying Not for 22.214.171.124.
Comment on attachment 354572 [details] [diff] [review] think before retrying Approved for 126.96.36.199, a=dveditz for release-drivers Let's try to get this one landed this time.
Is there a server and a clear verification scenario to test that this issue is fixed within QA?
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