1141604 - aavacations.com fail to load in Firefox Nightly, with "Secure Connection Failed ... Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) "

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit https://www.aavacations.com/
   (This is the site for "American Airlines Vacations")

ACTUAL RESULTS:
Error page with:
> Secure Connection Failed
> An error occurred during a connection to www.aavacations.com.
> Cannot communicate securely with peer: no common encryption
> algorithm(s). (Error code: ssl_error_no_cypher_overlap)
>
> The page you are trying to view cannot be shown because
> the authenticity of the received data could not be verified.
>
> Please contact the website owners to inform them of this problem.

EXPECTED RESULTS: Page loads successfully.


Firefox 36 (release) and 37 (beta) give EXPECTED RESULTS.
Firefox Developer Edition 38.0a2 (2015-03-10) and Nightly 39.0a1 (2015-03-09) give ACTUAL RESULTS.

It's conceivable that this error is intentional (if the site's security settings are really bad and we're becoming stricter) -- if that's the case, we should morph this into a Tech Evang bug and urge American Airlines to fix their site before Firefox 38 hits our beta/release users and they become unable to access it.

Comment 1

[Daniel Holbert [:dholbert]]

[Tracking Requested - why for this release]:
regression (from a user's perspective); unable to access a site, w/ apparently no way to locally work around it.

Comment 2

[Daniel Holbert [:dholbert]]

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5a35ca7c0adc&tochange=c731517a47e8

That's bug 1124039.

Skimming the last comments there, it sounds like we've got a whitelist for known-affected sites -- :emk, should we add this to the whitelist?

Comment 3

[Daniel Holbert [:dholbert]]

(I guess this should block metabug 1138101 instead of code-bug 1124039)
(Feel free to reclassify as Tech Evang if appropriate; I'm not sure how we're managing tech evang vs. whitelisting for this category of issues.)

Comment 4

[Masatoshi Kimura [:emk]]

I'm adding known broken site to the whitelist until the site is fixed.

Comment 5

[:Cykesiopka]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> (Feel free to reclassify as Tech Evang if appropriate; I'm not sure how
> we're managing tech evang vs. whitelisting for this category of issues.)

An RC4 only server is somewhat broken, so TE seems appropriate.

Comment 6

[Daniel Holbert [:dholbert]]

https://www.ssllabs.com/ssltest/analyze.html?d=aavacations.com confirms that this site only supports TLS_RSA_WITH_RC4_128_SHA. Quoting the output there:
> Cipher Suites (sorted by strength; the server has no preference)
> TLS_RSA_WITH_RC4_128_SHA (0x5)   WEAK		128

...and unsurprisingly, all of the simulated handshakes (listed below that) end up using TLS_RSA_WITH_RC4_128_SHA.

Comment 7

[Daniel Holbert [:dholbert]]

This affects the main American Airlines site, https://www.aa.com , as well -- I just didn't notice that at first because aa.com also allows insecure HTTP connections. (whereas aavacations.com forces you to upgrade to [broken] HTTPS)

Comment 8

[Daniel Holbert [:dholbert]]

I reached out to them on Twitter: https://twitter.com/CodingExon/status/575429893523025920

Do we have any documentation on steps that sites need to take here? (From the ssllabs blog-post about this, https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what , I think "Support TLS 1.2 and GCM suites as soon as possible" is the takeaway for sites?)

Also, here's a SSL Labs page for aa.com, for completeness -- it shows TLS_RSA_WITH_RC4_128_SHA being the only supported cipher-suite:
  https://www.ssllabs.com/ssltest/analyze.html?d=aa.com&s=23.203.222.57

Comment 9

[Masatoshi Kimura [:emk]]

(In reply to Daniel Holbert [:dholbert] from comment #8)
> I reached out to them on Twitter:
> https://twitter.com/CodingExon/status/575429893523025920
> 
> Do we have any documentation on steps that sites need to take here? (From
> the ssllabs blog-post about this,
> https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-
> broken-now-what , I think "Support TLS 1.2 and GCM suites as soon as
> possible" is the takeaway for sites?)

Site compatibility docs have some description [1][2]. Bug 1140919 comment #5 & #7 have more concrete information. Ideally they should support AES-GCM, but if it will take the time, almost everything (even 3DES) is much better than RC4.

[1] https://developer.mozilla.org/en-US/Firefox/Releases/36/Site_Compatibility#Security
[2] https://developer.mozilla.org/en-US/Firefox/Releases/38/Site_Compatibility#Security

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

It looks like Daniel has already done some outreach and the whitelisting will mean that by the time this goes to release it won't be something users encounter. 

emk, now that it's been whitelisted, when 38 goes to beta, will users be able to access this site? If so then this sounds like an evangelism issue and release management can't help.

Comment 11

[Masatoshi Kimura [:emk]]

I re-enabled unrestricted RC4 fallback on 38, so no beta users will encounter the problem.

Comment 12

[Daniel Holbert [:dholbert]]

(Is the whitelist-addition tracked somewhere? I'm still seeing this cert error in nightly at https://aavacations.com/ and https://aa.com/ , though maybe that's expected if the whitelist change isn't live yet.)

Comment 13

[Masatoshi Kimura [:emk]]

It is *not* added to the whitelist yet. Filed bug 1142769 to track this.

Comment 14

[Daniel Holbert [:dholbert]]

Hmm, I'm still getting this error when visiting https://aa.com/ in current Nightly.  emk, I thought comment 13 (bug 1142769) should have fixed this -- is the whitelist not working as expected? (Or maybe it's disabled in Nightly?)

(I do see aa.com listed at http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc#14 , so it didn't get removed somehow.)

Comment 15

[Masatoshi Kimura [:emk]]

Bug 1201023 has disabled the whitelist in Nightly/Aurora.
See <https://groups.google.com/d/msg/mozilla.dev.platform/JIEFcrGhqSM/CIjtpwxoLQAJ> about for details.

Comment 16

[Masatoshi Kimura [:emk]]

(In reply to Masatoshi Kimura [:emk] from comment #15)
> Bug 1201023 has disabled the whitelist in Nightly/Aurora.
> See
> <https://groups.google.com/d/msg/mozilla.dev.platform/JIEFcrGhqSM/
> CIjtpwxoLQAJ> for details.

Comment 17

[Martin Thomson [:mt:]]

I just pinged a contact at Akamai regarding this.

Comment 18

[Jesse Ruderman]

I tweeted at AA too, and had slightly better luck than Daniel.

https://twitter.com/AmericanAir/status/658881734583255040

Comment 19

[Marc Bejarano]

i see this in fx 42.0 release at aa.com, so it must be affecting lots of folks, now.

martin: did you hear back from your Akamai contact?

Comment 20

[Masatoshi Kimura [:emk]]

Firefox 42 does not disable RC4 yet. I confirmed Firefox 42 loads aa.com. Did you test with a clean profile?

Comment 21

[Martin Thomson [:mt:]]

It's certainly still busted in Nightly.  Rich told me that it would be fixed.  I'll give him another nudge.

Comment 22

[Marc Bejarano]

apparently my bustage in 42 is due to HTTPS Everywhere.  sorry for the false alarm.

Comment 23

[Jesse Ruderman]

fwiw, @getify got the same response I did:

https://twitter.com/AmericanAir/status/662640121276043265

Comment 24

[Martin Thomson [:mt:]]

Update:

> Now it's not gonna happen until after the holidays.
>
> Customer did not reply in time.

Comment 25

[Masatoshi Kimura [:emk]]

Most servers are fixed, but aavacations.com and www.aavacations.com are still broken.

Comment 26

[Masatoshi Kimura [:emk]]

And smlogin.aa.com.

Comment 27

[Masatoshi Kimura [:emk]]

smlogin.aa.com has been fixed.

Comment 28

[Masatoshi Kimura [:emk]]

Fixed.