We currently have a custom, cloud based application that can analyse then route HTTP and HTTPS traffic through to a domain. So if a client wants to use our service, they re-point their DNS to our application's IP address and our application will analyse the traffic and then route as appropriate.

In order to satisfy our clients' PCI DSS compliance, we do not decrypt or analyse HTTPS traffic, only HTTP. HTTPS traffic is simply routed through to the target system. This means we do not have to comply with PCI ourselves to maintain our clients' compliance.

However, in order to maintain our clients' compliance for PCI v3 that comes into play at the end of 2014, we have been advised that this would not be acceptable. The fact that the HTTP data is passing through our system will make the clients' systems non compliant as a flaw in our system might allow for a MITM to change the redirect for the payment details to a different site instead of the encrypted HTTPS channel for the card holder details (sort of like sslstrip). Our other solution, which was requiring our clients to host HTTPS content on a separate domain that is pointed directly to the customer's system was also not likely to be acceptable for PCI v3 because the unencrypted HTTP data would be subject to the same attack (i.e. they could be directed elsewhere).

Which specific changes in PCI v3 would likely affect our clients' PCI DSS compliance for this issue?


1 Answer 1


Part of both answers:

Disclaimer: I am not a QSA. And I'm straying farther into opinion here than I prefer to, so apply salt in grain form.

New answer following edit of question:

There are two changes with DSS 3 that bear on what you seem to be flirting with

  1. the addition of the new SAQ A-EP category.
  2. the back alley tussle that has been iframes versus javascript which keeps threatening to break out into some form of official guidance.

Both of these items are concerned with the provenance of credit card transaction flow. If I go to website X, and click "Check Out" from their shopping cart, I go somewhere to enter my credit card details. Where is that somewhere? How do I know it's where I'm meant to be? How do I know it's not routing my traffic through Bulgaria first?

Your business appears to be a traffic middleman. Voila, you're exactly what PCI is moving towards avoiding, or at least securing. You want your clients to seamlessly send traffic your way and you'll provide value X. But PCI doesn't want traffic seamlessly redirected unless there's sufficient security - to make sure, for example, no one can edit the process to use a different (malicious) checkout page.

You route traffic based on analysis. Great! That means an attacker can use you to reroute traffic. In PCI terms, that means you're either in scope or not permitted. And as a service provider who has stayed out of scope in the past, that means something's likely to change.

Now, the provenance issues are not laid out clearly. I can't point to DSS 3 section 13.7 which says what you're doing is addressed. But I can tell you that QSAs are going to start asking questions like "And this company does what? They middle all your HTTP traffic, including the traffic that sends people to shopping cart and checkout?" Then they'll want to see your service provider certification, because as per the definition of Service Provider:

This also includes companies that provide services that control or could impact the security of cardholder data.

So, yeah, you could end up with problems as the shift to DSS 3 progresses. I still don't feel confident I understand your business, so I can't say anything for sure, but it you're middling traffic, you're on the list and may lose customers if you're not a certified service provider. (Prolexic isn't. Akamai is. Who can say?)

Original answer below:

I recently performed a line-by-line comparison of PCI DSS v2 versus v3, and I don't recall anything within the DSS itself that would impact the traversal of HTTPS traffic across a provider. Section 4 deals with the encryption of "cardholder data across open, public networks" and would be the obvious place to look, and that's barely changed.

That being said, two caveats:

1) The DSS is not the only thing to pay attention to. The wording on the SAQs, if they apply to the businesses in question, and various other guidance papers that elaborate on the meaning for QSAs are also important.

2) It's not completely clear to me that your service is simply a conduit of encrypted traffic. You state that your clients "re-point their DNS to our application's IP address and our application will analyse the traffic and then route as appropriate." The phrase "analyse the traffic" will lure any QSA in for a deeper look. You shouldn't have much to work with for analysis, in the case of HTTPS; you would have to allow the SSL negotiation through to the true backend to nail up HTTPS before the channel was secure from you, and if that's all you're doing, your service isn't doing much. In short, I don't feel we have enough details about your service to give you solid advice.

  • Thanks. Yes your assumption is correct. We are simply channeling the SSL traffic as it only happens to hit our server due to using the same domain as the unencrypted traffic that we are analysing. Sep 9, 2014 at 13:40
  • Sorry - my fault. I've found out more info on the actual issue and this is to do with us handling the HTTP data before any redirect to HTTPS. Question has been updated. Sep 9, 2014 at 19:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .