15

I tested their server using https://www.ssllabs.com/ssltest/ and, apart from the disappointing "B" rating (it handles financial transactions, after all), the server only allows the following two RC4 cipher suites, both of which are considered weak:

  • TLS_RSA_WITH_RC4_128_MD5 (0x4) WEAK 128

  • TLS_RSA_WITH_RC4_128_SHA (0x5) WEAK 128

I disabled these cipher suites in my browser (Google Chrome) some time ago, so the transaction fails, but honestly I don't want to re-enable them if they are considered vulnerable. Should I make an exception for this particular case and temporarily re-enable the ciphers or should I insist they offer a stronger cipher suite? What do you think?

Gabriel S.
  • 283
  • 1
  • 7

3 Answers3

16

Of course you should worry. If the credit card payment processor is not able to fix well known and obvious security problems (A few days ago RC4 got explicitly prohibited for use with TLS by the IETF) which are even visible world-wide from outside, how will be the status of their internal security? Note, that it might be not that bad to offer RC4 for compatibility with older clients (see the other answer about PCI requirements), but in this case it offers only RC4 to all clients.

Not only you should think in this way but attackers will also think this way and will check the providers server and infrastructure for less obvious but maybe even more serious security problems. And they will probably find them, it would not be a first. This in effect can put your customers and also business at risk too.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • It sounds even worse than i thought if IETF really want to prohibit RC4... – Gabriel S. Feb 21 '15 at 20:46
  • 7
    The existence of an IETF "proposed standard" is a far cry from "officially prohibited". – gowenfawr Feb 21 '15 at 22:20
  • 2
    Most major protocols like HTTP, SIP, FTP, SMTP, IMAP ... and even TLS itself are "only" an RFC. It does not get much more official. – Steffen Ullrich Feb 21 '15 at 22:23
  • 1
    Allow me to quote RFC 2026 section 4.1.1: 'The entry-level maturity for the standards track is "Proposed Standard"' I'm not disputing that the IETF RFC status is official, I'm pointing out that the document you've cited is a new draft in "PROPOSED STANDARD" state. It's called "Request For Comments" for a reason! – gowenfawr Feb 21 '15 at 22:33
  • Yes, and it updates the existing RFCs for TLS1.2 and lower, which are also only proposed standards and thus on the same "standard" level as the new one. Thus if you consider TLS1.2 official you should consider the prohibition of RC4 official too. – Steffen Ullrich Feb 21 '15 at 22:40
  • I wrote them (the payment processor company) an email inquiring about this and now i'm waiting for a response. I'm really curious what they will reply. – Gabriel S. Feb 21 '15 at 22:41
  • I'm not sure whose point you're bolstering by pointing out that TLS 1.2 never made it through the process :) – gowenfawr Feb 21 '15 at 22:42
  • @gowenfawr: I've made it more clear who prohibited RC4 and pointed to your answer about the PCI requirements which is a valid point. – Steffen Ullrich Feb 22 '15 at 08:30
  • @GabrielS. What part of the company did you email? I don't think the people monitoring the usual customer-facing email addresses will know how to respond to "Hey, your HTTPS server only allows weak SSL cipher suites. You should fix that." ;-) – Ajedi32 Feb 27 '15 at 21:14
  • @Ajedi32 I wrote to their support email account. Even if they have no idea what it means, they should know to forward it to the most appropriate inbox. Anyway, I still haven't received any reply yet, which is disappointing. – Gabriel S. Feb 28 '15 at 09:25
16

A payment processor who accepts RC4 is simply satisfying PCI requirements. (WAS - see update below)

PCI does not disallow RC4. It does, however, consider the presence of BEAST to be a failure. And if they're going to mitigate BEAST and still remain widely compatible, they need RC4 - "The only reliable way to defend against BEAST is to prioritise RC4 cipher suites". The alternatives involve limiting support to TLSv1.1+, which has compatibility problems.

There's a good summary of the issue here: BEAST vs RC4 Ciphers vs PCI

That being said, @steffen-ullrich caught me in the comments to point out your provider is only supporting two RC4 suites. That's clearly not a good idea, and can't be completely explained away by the PCI issue. I'm willing to bet $2 in quarters that this was the result of someone who got told to make sure their site passed their PCI scanner, so they monkeyed around with it to get something that would pass, and didn't realize that they shouldn't go for the minimum passing ciphers.

Since Febuary 2015 when this answer was written, the PCI Security Standards Council has since prohibited RC4. See, for example, this document.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 8
    Providing *only* RC4 cipher suites and nothing better is far from providing *also* RC4 for clients which are not able to do TLS1.1+. RC4 is considered broken while BEAST is usually mitigated in implementations. – Steffen Ullrich Feb 21 '15 at 22:30
  • I concur with you that **only** providing those two suites is pretty strange - I missed that, thanks for catching me. – gowenfawr Feb 21 '15 at 22:36
  • Steffen Ullrich drives the point home here: ok, go ahead and allow older ciphers for ignorant or insufficiently secured clients, but at least allow the more security-aware clients to make use of stronger ciphers. What harm could they do anyway? – Gabriel S. Feb 21 '15 at 22:38
  • I now know why Paypal, Alipay (Chinese equivalent to Paypal) and my banks all default to RC4. Still it is odd when every tech sites default to AES while financial services default to much weaker cipher RC4. – Siyuan Ren Feb 23 '15 at 13:03
1

Weak ciphers are potentially susceptible to man-in-the-middle (MITM) attacks. On certain networks such as open Wifis in a coffee shop, a malicious attacker may break the encryption and decrypt the HTTPS traffic.

However attacks against RC4 are impractical according to this article from Qualys

Gabor
  • 179
  • 5