3

With the upcoming deprecation of TLS 1.0 for PCI compliance, I thought I'd confirm something: what categories of externally referenced assets (if any) could cause a compliance failure if their still domain accepted TLS 1.0 connections after June 2018?

  • Scripts?
  • Images?
  • CSS?
  • Fonts?

My guess would be "all" since all of those things have been used as exploit vectors in the past, but I'm curious if there's anything official.

3

There's nothing official so far, but it will almost certainly be down to the judgement of the individual ASV. This is almost always the case on purpose, because it allows assessments to be adaptive in the face of new attack vectors and different contexts.

For example, on an isolated domain where no information is entered and no stateful actions can be performed (e.g. a static link portal inside the PCI environment) none of these cases are particularly critical and I'd err on the side of letting it pass as long as the business can demonstrate a longer term plan to migrate to a more secure configuration.

In contrast, on a system that accepts financial data and performs financial transactions, I'd almost certainly fail it for any of those cases. Scripts and CSS are known to be XSS vectors, so those are the highest risk here. Fonts have, historically, been risky to the client endpoint but are generally more difficult to exploit outside extremely targeted scenarios. Images are the lowest risk here.

  • 1
    Using subresource integrity may also be relevant here as a mitigating factor. I don't audit PCI, but I'd probably let insecure loading of static files containing no personal data pass if SRI is used. – Lie Ryan Jan 25 '18 at 12:32
  • @LieRyan Yes, SRI would be considered a Compensating Control under PCI DSS terminology. – Polynomial Jan 25 '18 at 12:50
  • Interesting. Do you think that a strict CSP could also be used as a mitigating factor for the reviewer? – Richard Szalay Jan 25 '18 at 23:39
  • 1
    @RichardSzalay Not generally, no. If the CSP allows fetching resources (e.g. scripts) from a TLS 1.0 domain then the risk is there regardless of the CSP directive. SRI is the relevant compensating control here. – Polynomial Jan 25 '18 at 23:44
  • 1
    @RichardSzalay I'd argue that it'd be a good idea for PCI council to ban that practice entirely. Including anything from an uncontrolled third party over the internet into your PCI infrastructure is generally a bad idea from a security perspective. Perhaps they wanted to ban 3rd party includes but couldn't for political reasons, and this is a separate directive that improves security in other ways but, by side-effect, also implements that ban implicitly. – Polynomial Jan 26 '18 at 9:47
0

In theory, PCI only requires you drop TLS 1.0 "to safeguard sensitive cardholder data during transmission over open, public networks" and for "all non-console administrative access." So an argument could be made that things like static images aren't subject to the 'early TLS' prohibition.

In reality, however, TLS configuration is a per-server/application issue. If your site is serving both sensitive and non-sensitive content, you can't negotiate early TLS based on request type, because the request only comes after TLS has been negotiated. And with HTTP/1.1, for example, you can have a connection which pipelines multiple requests, all of which are under the same negotiated TLS. You can't really negotiate early TLS and then accept or reject requests based on their sensitivity. And even if you could, if it's a POST request sending you PAN data, the damage has been done by the time you get to see the request.

So you're going to find that ASVs require site-wide removal of early TLS for any site that has sensitive content.

Personally, I think you're going to find that the early TLS prohibition is going to flow out to cover all hosts and services, internal or external, sensitive or not. Because the ASV doesn't want to be reviewing individual cases and saying "Oh, you're right, that's the ILO interface for your coffee machine, it's okay if that's got TLS 1.0, because it's only coffee." When SSL 3 got prohibited a few years ago, my experience was that it got stripped out universally.

  • The issue is when an ecommerce platform loads js/fonts/etc from a third party domain and that domain is still allowing TLS 1.0 connections. – Richard Szalay Jan 26 '18 at 7:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.