1112178 - www.boostmobilesales.com is RC4 only

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[u123541]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141216030203

Steps to reproduce:

Opening new bug as requested in bug 1096395 comment 4:

> Could you provide the public portions of the certificate in question?
Instructions for doing this?  Looked in about:, .mozilla/* and googled...

Prefs->Advanced->Certificates:
  Your Certificates: empty
  People: empty
  Servers: nothing related to boostmobile.com
  Authorities: nothing obvious 
  Others: HP AiO printer stuff only

> Does this work in beta? ( https://beta.mozilla.org/ )
No. Beta is what I always run as my main browser, with FF34/Wine as alternate.


Actual results:

Tried to login to MyAccount on http://boostmobile.com -- last time I logged in was probably 6-10 weeks ago.  Login works when using FF34.0.5/Wine.



Expected results:

Successful login was expected.  Reported issue to BoostMobile as early warning since it works with production FF.

Comment 1

[u123541]

The failure dialog has a Learn More... link which is not helpful for debugging. 
Its "Report" button doesn't seem to do anything when clicked.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Pierre, what is the url that's failing? (i.e. copy/paste the contents of the location bar on the page you see the 'secure connection failed' error on)

Also, if you're curious, one way to get a copy of the certificate that's failing is to use wireshark to capture packets from the failed connection. Let me know if you want more details on that.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Thanks, Pierre. This appears to be a fallback/TLS intolerance issue. If I set security.tls.version.fallback-limit to 1 (instead of the default 3), the page loads.
:emk, any ideas?

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Hiding potentially personally-identifiable/sensitive information (I don't think anything sensitive was available, but just in case).

Comment 6

[Masatoshi Kimura [:emk]]

Firefox 34 fails to connect if I set security.tls.version.fallback-limit to 3. So the RC4 fallback is ruled out.
Interestingly, ssllabs' handshake simulation indicates Firefox 31.3.0 ESR / Win 7 and Firefox 34 / OS X will fail to connect (the handshake simulation doesn't implement the fallback).
https://www.ssllabs.com/ssltest/analyze.html?d=myaccount.boostmobile.com
Maybe the site dislikes something in our ClientHello?

Comment 7

[Masatoshi Kimura [:emk]]

I can connect if I set security.tls.version.fallback-limit to 3 *and* security.tls.version.min to 0.
That is, this site will negotiate with TLS 1.0 if the ClientHello version is TLS 1.0 while it will negotiate with SSL 3.0 if the ClientHello version is TLS 1.2.
Bug 1085138 comment #4 and onwards mentioned some other instance of those sites.

Comment 8

[Masatoshi Kimura [:emk]]

Looks like myaccount.boostmobile.com has been fixed. But the redirect target, www.boostmobilesales.com, is still broken (RC4 only).

Comment 9

[Hallvord R. M. Steen [:hallvors]]

If we're going to contact them, here are some possible contact points:
Twitter: https://twitter.com/boostmobile
Google+: https://plus.google.com/+boostmobile
Facebook: https://m.facebook.com/boostmobile
Contactlink: http://www.boostmobile.com/support/contact-customer-service/

BTW a direct link for analysing the boostmobilesales.com domain is
https://www.ssllabs.com/ssltest/analyze.html?d=boostmobilesales.com

I'll send them a tweet.

Comment 10

[Hallvord R. M. Steen [:hallvors]]

A response from customer service at least: https://twitter.com/BoostCare/status/652102371724652544

Comment 11

[:Cykesiopka]

Looks like this is fixed now.