[cesarb]

> Disable use of RC4 except for temporarily whitelisted hosts

This is the one which has the greatest chance of giving people a headache. For instance, one of the biggest banks here still uses only RC4 for its online banking site. Its top-level hostname and a few of its auxiliary hostnames are on the whitelist, but there's no guarantee that all the RC4-only auxiliary hostnames it might use for some of its functionality are on the whitelist.

[Sir_Cmpwn]

Good. Breaking their websites is the only way some people will fix their broken security.

[owly]

YES. Force them to upgrade their weak sites!

[jbrooksuk]

Which unfortunately costs time and money. Whilst yes, they should be up to date and secure, banks are pretty big businesses and require more time.

One day they'll catch up.

[chrismartin]

Banks handle everyone's money and are high-profile targets for compromise over the network. As such, they should be obliged to keep current with best security practices as the technology evolves, not lag far behind these.

[Elidrake24]

But that's the inherent problem; these companies are still setup for a bureaucracy that works fine in a particular area of business, but completely crumbles under the new rules of the technological age. We shouldn't be apologetic for their resisting of change, but rather pushing them to take a long hard look at what needs to be reorganized to fit into the new paradigm.

[cpeterso]

Banks, of all businesses, should be concerned about online security, for real protection and for appearance of caring for their customers' peace of mind. Mozilla telegraphs these browser changes months in advance.

[Flimm]

Malicious crackers aren't going to wait.

[edwintorok]

After the CVE score for BEAST and RC4 got adjusted and the RFC 7465 was introduced I've seen some payment systems update their system quite quickly (in a matter of days), and if they didn't they'd probably fail their next PCI audit: https://news.ycombinator.com/item?id=9198889

Perhaps it helps if you write your payment site operator/bank private emails asking them to allow other ciphers beside RC4, mine looked like this (actual site name removed):

  According to Qualys SSL Labs the site **** [2] only supports the RC4 cipher, 
  and thus is not RFC 7465 compliant [3], and Google Chrome qualifies the site as 
  "Your connection to **** is encrypted with obsolete cryptography."

  The site **** is even worse [4], it uses only 768-bit DH key exchange in some 
  situations (instead of 2048).

  There is an online tool [5] that you can use to generate/compare 
  configuration for popular web-servers, using the intermediate level is 
  recommended [6].

  For your information I sent a similar email last year to **** and they have 
  fixed their problems, and get a nice 'A' grade from SSLLabs now.

  Apparently this use of RC4 all comes down due to a mistake in NIST's 
  classification of the severity of the BEAST vulnerability [7], but both Google 
  Chrome[7] and Mozilla Firefox[8] are trying to avoid the use of RC4 completely, 
  and mitigating the BEAST vulnerability is no excuse for not providing good 
  ciphers (in addition to RC4 if you must) when my browser supports TLS 1.2 with 
  AES-GCM which is NOT vulnerable to the BEAST attack.

  I suggest you to include the Qualys SSL Labs test when testing sites for 
  PCI-DSS compliance, they are usually quite good at reporting the latest TLS 
  vulnerabilities for a server.

  [1] http://www.visaeurope.com/media/images/pci%20dss%20validated%20web%20listing%20march%202015-73-18412.pdf
  [2] https://www.ssllabs.com/ssltest/analyze.html?d=****
 This server accepts the RC4 cipher, which is weak. Grade capped to B.
 Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
  [3] https://tools.ietf.org/html/rfc7465
  [4] https://www.ssllabs.com/ssltest/analyze.html?d=****
 This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F.
 Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
 The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
 This server accepts the RC4 cipher, which is weak. Grade capped to B.
  [5] https://mozilla.github.io/server-side-tls/ssl-config-generator/
  [6] https://wiki.mozilla.org/Security/Server_Side_TLS
  [7] https://code.google.com/p/chromium/issues/detail?id=375342#c30
  [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1088915
  [9] https://www.ssllabs.com/ssltest/analyze.html?d=****

[yuhong]

Sadly the 768-bit DHE is hardcoded into older versions of Java, which is why I suggested to them that they raise the limit to that instead of 1024-bit for now.

[yuhong]

Actually, the security.tls.unrestricted_rc4_fallback is still true by default.