Using Finnish or Swedish Nordea online banking site is impossible with the Nightly version. Logging in works but as soon as any page inside is clicked, the system logs you out and gives a message about system error (the message is in Finnish and Swedish). The issue can be reproduced at least on two pages: 1: Open https://internetbanken.privat.nordea.se/nsp/engine Click on 'Förenklad inloggning' tab. 2: Open https://solo1.nordea.fi/nsp/engine Click on 'In English' tab at the top. Expected result: A page opens asking for username and password What actually happens: The page reports an error I was reported the bug affects Linux too and it has been reproduced on both x64 and x86 versions of Nightly. And the bug isn't new, I have been suffering from it for weeks.

Reported on Linux and Mac OS X too. Note that Aurora/Beta/Release do not suffer from this problem. When going back, you get a 403 Forbidden error that goes away when you force a refresh.

Looks like a regression between 2011-10-07 and 2011-10-08 build. I think the regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c3a50afc2243&tochange=6c780dcb4b99

Looks like http://hg.mozilla.org/mozilla-central/rev/8f011395145e

(In reply to Olli Pettay [:smaug] from comment #3) > Looks like http://hg.mozilla.org/mozilla-central/rev/8f011395145e I verified this IS the issue using hg bisect.

I should have included the hg bisect output: The first bad revision is: changeset: 78045:8f011395145e user: Brian Smith <bsmith@mozilla.com> date: Fri Oct 07 13:37:26 2011 -0700 summary: Bug 669061: Upgrade to NSS 3.13 RC0, r=wtc

I verified that this is caused by the chosen plaintext attack prevention from bug 665814. Both sites are using a non-spec-compliant TLS (SSL) implementation and needs to upgrade. Other browsers have or will be making the same change around the same time as us and the site will be broken with them too. Steps I used to verify that this is caused by the BEAST workaround: 1. Open a command prompt 2. Set NSS_SSL_CBC_RANDOM_IV=0 3. Run Firefox from the command prompt. The sites will work normally, because NSS_SSL_CBC_RANDOM_IV=0 disables the BEAST workaround.

>Other browsers have or will be making the same change around the same time as us >and the site will be broken with them too. It is not. http://googlechromereleases.blogspot.com/2011/10/chrome-stable-release.html "Although Chrome is not directly affected by the attack, the NSS network library was updated to include a defense against so-called BEAST." I tested Chrome 15 (which is what this report is about) and Canary (Chrome 17, should be their Nightly), and they *work*. Firefox is as of yet the *only* browser that breaks.

I just tested Google Chrome Beta and Google Chrome Canary. Google Chrome Beta still works normally. Google Chrome Canary has the same behavior as Nightly.

>Google Chrome Canary has the same behavior as Nightly. You're right. No idea why it seemed to work on the first attempt.

Chrome 15 was slated to include the 1/n-1 record splitting and launched as such. However, in order to give a couple of prominent sites a chance to upgrade it was moved from 15 to 16. The error on the page seems to be non-deterministic and this is the first time that I've seen such a bug. We're sending the two records in the same TCP packet so it's not obvious to me how that can occur. None the less, the server will have to be fixed.

(In reply to Adam Langley from comment #10) > The error on the page seems to be non-deterministic and this is the first > time that I've seen such a bug. We're sending the two records in the same > TCP packet so it's not obvious to me how that can occur. None the less, the > server will have to be fixed. I have also seen this erratic behavior in Firefox Night. Sometimes I can switch to the login tab but then switching back to the original tab will fail. Other times, it fails to switch to the login tab.

www.nordea.se Internetbanken Företag Om Nordea Privat Hem Systemfel System failure Systemfel Ett systemfel har tyv?rr uppst?tt och ditt Internetbanksbes?k har avbrutits. Data som inte sparats kan ha f?rsvunnit, du b?r d?rf?r kontrollera de inlagda uppdrag m.m. som du gjort under bes?ket s? att de inte f?rsvunnit. Du kan logga in i Internetbanken igen genom att klicka p? l?nken. Logga in

Error 403--Forbidden From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Have we had the opportunity to reach out to Swedish Nordea yet if this is still believed to be a site regression?

I'm not sure what you mean with "site regression", but the site didn't change anything. The cause for the problems is a change in Firefox related to BEAST mitigation, see comment 6. I'm not sure what Nordea's problem is exactly. I was in contact with a system admin of another affected site (with similar but slightly different symptons) that this is a firmware bug in Brocade load balancers that they are using, and that there is no fix available yet, so they cannot do anything. Chrome has added code to handle some of these issues through blacklisting buggy sites/hardware, although last time I tried Nordea broke for them too.

Brocade have released firmware 10.2.01y to fix this issue. All sites using Brocade SSL terminators should update ASAP.

Users are reporting things work fine now, no action on our side needed.

This problem is back. E.g: http://www.nordea.fi/Henkil%C3%B6asiakkaat/Verkkopankkiin/816202.html click first link. Site works fine in Chrome 18 release *and* Chrome 20 canary. a) Why did they regress? Did they undo firmware fixes? Bought more hardware and didn't patch it? b) Why does Chrome work now in all versions while we don't?

gcp: Chrome is negotiating RC4 with that site. We don't have any specific workarounds for them. In fact, it appears that the server selects ciphersuites based on its preferences and that it prefers RC4, so I don't know why you would be seeing a CBC ciphersuite when connecting to them.

FWIW, when re-clicking you sometimes do get a connection. Looking in connection info indeed shows RC4-128 cipher being used. The initial attempt shows a Connection Reset message. Chrome mentions here "The connection had to be retried with SSL 3.0. This typically means the site is using very old software and may have other security issues."

I'm afraid that I don't see SSLv3 fallback happening and, indeed, I can send a TLS 1.2 ClientHello with SNI, status_request etc and it correctly negotiates v1.0. I've tried against 92.43.121.128 and 193.88.186.176

I noticed interesting behaviour: The link mentioned in comment 19 is: https://solo1.nordea.fi/nsp/engine That link will always fail on the first attempt in an Firefox Aurora 14 session. The connection ends up with that connection was reset message. Pressing "Try again" on the error page, or refreshing the browser, or entering the address to a new tab will all then lead to a successful connection. Later connection attempts in the same Firefox session will succeed. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120507 Firefox/14.0a2 ID:20120507042004

Regression window bisected for Comment 19 Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/ab2ff3b5611f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120323 Firefox/14.0a1 ID:20120323031214 Fails: http://hg.mozilla.org/mozilla-central/rev/c20ec27eb0e8 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120323 Firefox/14.0a1 ID:20120323045119 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab2ff3b5611f&tochange=c20ec27eb0e8 Regression window(m-i) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/1d1614bb7b39 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120322 Firefox/14.0a1 ID:20120322173417 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/6018a0d6b33d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120322 Firefox/14.0a1 ID:20120322175719 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1d1614bb7b39&tochange=6018a0d6b33d

(In reply to hannu.nyman from comment #23) > I noticed interesting behaviour: > The link mentioned in comment 19 is: https://solo1.nordea.fi/nsp/engine Using that host (rather than the one mentioned in #19), I can confirm that it's a TLS intolerant server. I'll contact the bank in question about it. It would appear the Firefox isn't doing SSLv3 fallback after the handshake fails. That's arguably not a bad thing, but I'll leave that up to the Mozilla folks to decide the merits of.

> E.g: http://www.nordea.fi/Henkil%C3%B6asiakkaat/Verkkopankkiin/816202.html > click first link. Direct link: https://solo1.nordea.fi/ I suspect there are several IP addresses/servers used by these hostnames, and gcp and agl connected to different servers. I tested with ssl3 disabled in Firefox. If I connect to 62.13.0.79, the browser sends a v3.1 handshake, and the server replies with a v3.0 handshake_failure. Using 92.43.121.128 I get a successful v3.1 handshake. I conclude the software used on server at 62.13.0.79 is the culprit for the fallback to ssl3 that you saw.

Patrick, see comment #24, especially the mozilla-inbound pushlog that implicates you. The TLS intolerance code does a PR_SetError(PR_CONNECT_RESET_ERROR, 0); to force Necko to do a retry; in the retry, we will use SSL 3.0 instead of TLS 1.0. I did not dig into it too deep, but it seems reasonable to think you might have changed the connection reset handling logic.

This is very likely not related to the BEAST mitigation, but a regression in TLS->SSL fallback, so I'll make a new bug and include relevant info from this one in it.

Filed bug 752648 as this appears to be a new problem. Thanks to everyone who helped to narrow this down!