22

PCI DSS states:

"[You must...] verify that only trusted SSL/TLS keys/certificates are accepted."

Long story short, our payment service provider just asked us to please stop verifying their certificate after we had some SSL handshake issues. Is this wrong?

Eric R.
  • 321
  • 1
  • 5
  • 15
    Short answer; yes. Certificates should always be verified. If they're asking otherwise then they should fix their stuff properly. – RoraΖ Oct 01 '14 at 18:25
  • 11
    "*Is this wrong?*" Wrong, stupid, and dangerous. Don't do it. If they can't or won't fix their stuff as @raz suggests, find a new merchant provider. – Xander Oct 01 '14 at 18:29
  • Just to clarify, by “merchant provider” do you mean a payment service provider, that you-as-the-merchant are connecting to to initiate a payment session? Are you-the-merchant sending cardholder data (including PAN) down that interface? If so yes, you must absolutely identify that the party you are connecting to is the payment service provider using valid certificates. If the setup is something different PCI may or may not be concerned. – bobince Oct 02 '14 at 16:44
  • @bobince yes, I meant payment service provider. I updated the post to clarify. – Eric R. Oct 02 '14 at 16:54
  • Ouch. That does seem pretty bad then. There are some scenarios with insensitive data and client-cert callbacks where cert-level validation might not be essential, but if they're asking you to send a card number down an connection you haven't verified, they're definitely asking you to break PCI (and common sense). – bobince Oct 02 '14 at 17:00
  • Can you clarify what you mean by stop verifying? Which aspect of verification? All? Some? – Steve Oct 02 '14 at 17:40

2 Answers2

33

Yes, this is wrong, and here is why. As you mentioned, PCI-DSS requires that communication containing sensitive data be handled over a secure channel. As a part of this process, certificate validation ensures that the certificate in question is in good order and belongs to the party that you intend to talk to. If you do not validate the certificate, the traffic may as well be unencrypted because you have no idea of who is on the other end. It could be your merchant provider, or it could be a man-in-the-middle who's reading and storing all of the card data you send before forwarding it on to the provider. Without validation the cert, you can't know who's seeing the data, so your trust level that the transport channel is secure must necessarily be 0%.

So, as I said in the comments, do not accept this condition. If your merchant provider can't, or won't fix the issues so that you can confidently validate their certificates, find another merchant provider. In fact, that may not be a bad idea in any case because if they're willing to play fast and loose with PCI and security here, you can't know where else in their system they've taken similar liberties putting you and your customers at risk.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • 4
    Big +1 for this being a hint of deeper seated troubles. – ceejayoz Oct 01 '14 at 20:40
  • 9
    It's probably also worth [getting in touch](https://www.pcisecuritystandards.org/organization_info/contact.php) with the PCI Council and mentioning this. You might be one of the first to object to this request, and others may have just gone ahead with it. – Polynomial Oct 02 '14 at 09:29
-4

Payment Card Industry Data Security Standard -> Yes, it is wrong!

You can maybe check what is wrong with the handshake on the Qually SSL Labs server test:

https://www.ssllabs.com/ssltest/

If it was any service, they could offer it without SSL and tell you to use it, but here it is just crazy to even suggest it.

+what Xander said.

user56835
  • 1
  • 2
    This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient [reputation](http://security.stackexchange.com/help/whats-reputation) you will be able to [comment on any post](http://security.stackexchange.com/help/privileges/comment). – Deer Hunter Oct 02 '14 at 11:58
  • 2
    @DeerHunter I'm pretty sure this actually *does* attempt to answer the question (though it's not very detailed, nor is it worded very well). – Ajedi32 Oct 02 '14 at 13:44