PCI DSS v3.1 recommends usage of TLS v1.1 or greater: https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf

… it is therefore strongly recommended that POI environments use TLS v1.1 or greater wherever possible. New implementations of POIs should strongly consider support for and use of TLS 1.2 or greater. If SSL/early TLS is not needed in the environment, use of and fallback to these versions should be disabled

Any case I need the clarification: should I use TLS v1.1 for any communication?

It is clear for me that if I have HTTP server that is used for user access I must use TLS v1.1.

What about an internal communication?

We use stunnel for the internal communication between our servers and we use TLS v1.

Should we configure stunnel to use TLS v1.1? Or we can continue to use TLS v1?

What if some component (for example PostgreSQL) can not support TLS v1.1?

What should we do in this case?

  • My answer is below, but in summary: upgrade to TLS v1.1 (or better) wherever you can. Sep 18 '15 at 20:49

Michael, my read of that guidance is that the requirement about moving to TLS 1.1 (preferably 1.2) applies beyond the POI context to your internal systems, including (as far as I can tell from what you provided) the links between the servers you talk about. I say that because, first, of the actual PCI requirements that the guidance points to as being implicated here:

Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure. Requirement 2.3 Encrypt all non-console administrative access using strong cryptography. Requirement 4.1 Use strong cryptography and security protocols to safeguard > sensitive cardholder data during transmission over open, public networks.

Now, merchant-to-you encrypted connections involving POIs are clearly part of this through Req. 4.1. But the reference to Rule 2.3 about encrypting all administrator access stuff and to Rule 2.2.3 with its wider general applicability to many systems that a PCI-covered entity possesses leads me to believe the internal processing connections you're talking about are indeed within the upgrade requirement.

Now, as is usual with PCI stuff one important thing to keep in mind is that there's often quite a lot more flexibility built into the requirements vs. what might seem the case on first blush. For example, the linked-to guidance says that you can meet the "upgrade" mandate if you use encryption in another layer/type that's at least as strong (security-guarantee wise) as TLS 1.1. For example, if you set up a IPsec tunnel between two servers and then run your non-upgradable TLS 1.0 flow through the guidance says that you are & will be in compliance. For more info about flexibilities you might have under the guidance and under the actual Requirements more broadly I'd definitely seek out a PCI consultant or firm that has strong expertise in helping payment gateways & payment processors keep up with new evolutions in PCI rules that are occurring if the wake of the massive thefts of user financial info that have occurred in the last few years. (And, while I'm on the subject of getting direct, reliable advice from an expert, I'll throw in the obligatory disclaimer that I haven't looked extensively into the particulars of your case, may or may not have sufficient expertise--from your standpoint, I'm just a guy on the Internet--to do so, and thus what I have written above is not a substitute for professional counseling.)

In other words, I think your internal networking connections are covered by the upgrade rule, at least to the extent that they convey authentication credential info needed to do administrative things (eg. user names & passwords, of course) and/or carry sensitive card data & other financial info over them. My two cents...

PS: Keep in mind not just the ultimate deadline for upgrading (or making redundant) TLS protections by June of 2016, but the reporting and mitigating measures that the guidance also discusses.

  • Thanks! (Probably other question): Can I use IPSec with a plain connections (without TLS / SSL)?
    – Michael
    Sep 20 '15 at 6:07
  • 1
    My initial reaction: I can't really think of any good reason within the Requirements why not. That IPsec + old SSL/TLS scenario that I mentioned above is in the guidance, which might imply, if you were reading it really literally, that you do need to do both. But personally I've found that trying to read PCI stuff that literally is usually just a recipe for unnecessary pain. What I think the reqs/guidance are really trying to say is that if you do rely solely on SSL/TLS to protect these connections you need to be at at least TLS 1.1 , but... Sep 22 '15 at 6:54
  • 1
    ... if you have another encryption layer that's at least as strong as SSL/TLS protecting these connections then PCI doesn't really care much about what you do with TLS. (That being said, having some sort of SSL/TLS in place in addition to your IPsec tunnel is, arguably, a good defense-in-depth practice to guard against any misconfiguration of your IPsec .) Sep 22 '15 at 7:01

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.