Payment processor website uses RC4 for https encryption
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• bzimport
	Nov 20 2014, 10:27 AM

Description

Author: axel+wikimedia

Description:
Hi,
When trying to make a donation, after entering the amount I wanted to donate I was redirected to a server, ott9.wpstn.com.
From what I can tell, it's a WorldPay.ca (payment processor) server.

Having configured Firefox to refuse all connections using the RC4 cipher for SSL/TLS (as RC4 is deprecated and considered insecure), I was not able to establish a connection to the server (Firefox shows the “no cipher overlap” error).

An SSL test for the domain shows that it indeed offers RC4 (and nothing else):
https://www.ssllabs.com/ssltest/analyze.html?d=ott9.wpstn.com

This is bad. RC4-encrypted traffic has been likened by some infosec researchers to “no encryption” and the NSA can allegedly break it in real-time.

Here is the (very poor) list of ciphers offered by the server:
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 571 bits (eq. 15360 bits RSA) FS 128

Furthermore, the server is still offering SSLv3. That should also be disabled, following the POODLE vulnerability published about a month ago.

The server should be offering modern encryption (forward secrecy, no SSL, strong non-deprecated ciphers).
Here is a good guide on how to do it on Apache2:
https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html

I hope this can be resolved quickly as the Wikipedia fundraising campaign is ongoing and I don't feel comfortable giving in such conditions nor recommending others do so, even if I believe it is really important they do support Wikipedia, when the payment processor's security is in such a sad state.

Version: wmf-deployment
Severity: major

Details

Reference: bz73644

Event Timeline

• bzimport raised the priority of this task from to High.Nov 22 2014, 3:56 AM

• bzimport added a project: Wikimedia-Fundraising.

• bzimport set Reference to bz73644.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Nov 20 2014, 10:27 AM

Thank you for raising this issue.

While RC4 does have several well-documented vulnerabilities, the best rely on finding short tokens across high volumes of repeated requests, such as session identifiers, which our users don't have with the Worldpay endpoint. Additionally, our Worldpay workflow relies on two endpoints: The public one that you identified, and a private secure endpoint which is used at the beginning of the workflow to issue a one-time token. While RC4 is less than ideal, it presents very little risk in this context.

Additionally, we have recently reached out to Worldpay and learned that they are currently in the process of scheduling a maintenance window in the near future, during which time they will be removing RC4 ciphers, adding TLS ciphers to the public endpoint, and disabling SSL 3.0.

While you may say "it presents very little risk in this context", the real issue here is that the existence of RC4-only servers prevents the clients from disabling RC4 ciphers entirely. Browsers have to support RC4 to make these websites, such as Worldpay, "just work". According to SSL Pulse, 1.4% of sites require RC4, and 27.3% of sites use RC4 with modern browsers. If there were no such 1.4% sites, browsers could have disabled RC4 ciphers by now so that users are immune to RC4 attacks no matter which websites they visit. However, now these 1.4% of websites, including Worldpay, make 27.3% of websites in the world vulnerable to RC4 attacks. You may argue that the 27.3% websites are also wrong in that they support and prioritize RC4 ciphers. That's right. But practically it's easier for RC4-only websites to add more cipher suites, because I see no servers use RC4 only as their default cipher suite list.

Anyway, writing this post, I just want to point out that this is a big issue, regardless of whether "it presents very little risk in this context" or not. I hope Worldpay can fix this issue as soon as possible.

Thanks for filing this issue. We don't usually close a bug just because a fix is planned; "Open, stalled" would be a more standard status (I just checked and the issue wasn't resolved yet).

Fair enough. Marking as stalled, as we are still waiting for the third party to resolve this issue.

Krenair subscribed.Dec 9 2014, 6:27 PM

It seems they have fixed the issue. They have enabled some cipher suites besides RC4. SSL 3.0 has been disabled.

https://www.ssllabs.com/ssltest/analyze.html?d=ott9.wpstn.com

Chmarkine closed this task as Resolved.Dec 13 2014, 5:13 AM

Chmarkine set Security to None.

• Phabricator_maintenance added a project: HTTPS.Aug 5 2016, 11:40 AM

• Phabricator_maintenance removed a subscriber: • wikibugs-l-list.

Restricted Application added a project: Traffic. · View Herald TranscriptAug 5 2016, 11:40 AM

• Phabricator_maintenance removed a parent task: T29946: [DO NOT USE] SSL related (tracking) [superseded by #HTTPS].Aug 5 2016, 11:41 AM

Payment processor website uses RC4 for https encryptionClosed, ResolvedPublicActions

Description

Details

Event Timeline

Payment processor website uses RC4 for https encryption
Closed, ResolvedPublic
Actions