Encryption of transmitted cardholder data in requirement 4 was actually one of
those ones that there was not really much to worry about.
I mean, you turned stuff on and it encrypted data,
and then we have the SSL to TLS thing.
So I guess that's what we need to talk about most.
Is that what your clients are having most problems with?
That is the biggest trouble, right,
is using SSL or using TLS correctly and stopping using SSL and
earlier versions of TLS and some of the other kind of practical
implementation questions for TLS communications.
Okay, but from a timing perspective, we are in September 2018?
Yes.
And the deadline for moving from SSL to TLS has past?
It has.
I mean, it's passed about three times now,
but it's now all dead as opposed to just mostly dead.
Yeah.
Right, and amusingly, in July, in August,
I had some clients ask me, well, what if we need some time to transition this?
We have clients that we need to work with that are
going to take some time to do this, and I was sort of puzzled by that,
and then you know, only momentarily before that I was entirely not surprised,
because of course,
there's been this long transition period where the PCI standard
has talked about the need to get rid of this,
the need to have a transition plan, a risk mitigation.
That has gone on now for several years, right,
with what was not even implicit,
but what was explicit that you need to figure out what your business
requirements are for getting off of these problematic protocols.
And so then to have somebody say, but wait,
we can't just do this all at once, really shouldn't surprise anybody.
I think it's been three years in the coming, in happening?
It has.
Okay,
so let's take it where we're in a position now where what should we be using?
We shouldn't be, well, tell me what we should be using,
not what we shouldn't be using.
Do both, do both.
Sure, we'll start with the good stuff, right?
We should be using TLS 1.2, right?
You can use TLS 1.1.
From a protocol standpoint, it is not broken the way SSL v3 or TLS 1.0 are,
right?
It's maybe on the bubble a little bit, and there are,
there are potentially some troubles because TLS 1.1 supports a lot of
crummy ciphers and relatively few kind of good ones.
The standard has got this great big euphemism in it, hasn't it?
Right.
The euphemism is early TLS.
Early TLS.
Yes, it doesn't say TLS 1.0, it doesn’t say TLS 1.1.
Right.
Believe me, it means TLS 1.0 and TLS 1.1, right?
That was certainly the intent between the drafters of that clause.
That was the intent, right, and you know,
is 1.1 vulnerable to the same kind of weaknesses as 1.0 or SSL 3?
Not exactly, right?
But it's not a great idea, right?
And you should be moving towards TLS 1.2,
and conceivably, right,
when TLS 1.3 stops being something that exists entirely on cocktail napkins
and maybe start happening in actual browsers or web servers,
that would be the new ideal.
And we're close to that now.
We are.
We're really close to that.
We are close to that.
Okay, so the first thing is getting the right protocol, CLS 1.2.
The second thing is the right suite.
The right ciphers, right.
And you know,
here I will actually just endorse something from Qualys called SSL Labs.
Go to www.ssllabs .com and you can point any sort of
internet-facing site to the test available from SSL Labs,
and it will give you a load of information about how your website is configured.
Yeah, go to the Test Your Server.
So let me do that, let me go Test Your Server,
and should we test the PCI Council?
That would be?
That would be fun.
Is that okay?
Yeah.
Do you not show these results just in case?
They're bound to be an A+ anyway.
Well, let's find out.
And it is actually pretty quick.
You see the little spinner going round and round, but it moves along.
So now it's just pulling out all the different certs that were in use.
Right.
I think this is a brilliant tool.
I use it a lot.
It's really useful; it's really useful as long as
that site is internet accessible.
If you've got an internal site that isn't exposed to the internet,
obviously you can't get SSL Labs to find it,
you can conceivably replicate that with some of like
the open SSL command line utilities, but that's more work.
Now one of the things that I always used to stumble with
clients was about sending and receiving data.
So some clients would say, well, you know,
requirement 4, it's something about me sending data,
it's not about my web server accepting data.
Well, of course it is.
I know of course it is, but I just wanted to make it,
you know, it's really clearly in the standard.
If you're sending data, you need to send it over strong cryptography,
and if you're receiving data,
you need to configure your system to receive it over strong.
There's no cop-out to say well, that browser over there is really poor.
It's like, but no, your server will accept that, that's not accept that.
The other fun cop-out that we should probably sort of quash
while we're at it is the idea that oh, I establish a VPN connection,
you know, to my payment processor, to my business partner,
right?
That's not a public network.
Well, it's a VPN connection riding over the public internet,
and the cryptographic properties of that VPN matter so yeah,
it is and your assessor should look at it.
Okay, so it looks like our results have finished.
Yeah, and it's got an A, and so funny enough,
I feel like you need to pull the sort of Spaceballs bit
where what does the letter grade mean and you show Rick
Moranis in the outfit saying, absolutely nothing,
because that's really appropriate.
The letter grade isn't all that interesting,
because you can get an A with some potentially problematic things,
particularly if you have PCI DSS obligations.
Okay, so if you scroll down to the results like you're doing now,
you can see some of the certificates, you can see the protocols supported,
and then here's where it gets interesting.
If you go look at that Cipher Suites list.
But the first thing is that it's showing me that like it's just using TLS 1.2.
It is.
So am I using deprecated protocols?
No.
No, well done.
Alright, but I am using some weak ciphers.
Yes.
Right,
and so you can of course still get an A and have kind of a load of weak ciphers.
Is that a DSS fail?
I would contend, I would contend that weak ciphers,
right, are not strong cryptography, right?
And generally this is just about bad configuration, isn't it?
Someone not thinking what cipher suites to use?
Right, or more precisely, not actively disabling the problematic ones.
Right?
When you see this set of cipher suites,
this is the set of cipher suites that that server will allow
in the negotiation between the client, the browser usually,
and the web server.
Typically an up-to-date browser will recommend you know,
one of the stronger cipher suites.
They'll pick the top one off the stack is typically what'll happen,
and so it's only if you've got an older browser or if you've got a man in
the middle forcing a downgrade to do something spurious,
then you get the weaker cipher suites.
I have a terrible confession to make.
Okay.
But last week I did some of this cleaning up for
somewhere and I broke a whole lot of stuff,
because somewhere out there on the internet were browsers that I
think were about a year and a half out of date.
Right.
So no one had updated, and they stopped working, and I got into trouble.
Well, I will say, you know, for this, as well as really anything else,
maybe test it before you sort of deploy.
You know, that theoretically had happened,
you know, but you know,
the practice was the telephone rang and somebody rang
and it was we can't make transactions, that's quite poor,
can you fix it?
Right, right, and well,
you know you've got a fair point where there is some concern,
right, if you've got an older browser,
if you are supporting folks that are still running Windows XP and its
attendant version of IE or very old Android devices.
Android devices are what my marketing department always say,
look, we get 1% of our sales through these old Android devices.
Right, well,
and then you get into the realm of what's a viable compensating control,
right, and what is the valid business constraint?
If your marketing department can actually show you,
no, we really do get real money this way,
you know, okay, now we're talking about a valid constraint.
There's a QSA, that's a valid business reason; that's what you're looking for?
That valid means it's not someone making it up.
Right, someone can substantiate that.
If your marketing people are saying, oh well,
we might possibly get some sales from crummy old Android devices,
that doesn't seem like a valid business constraint,
but if your marketing department can say,
here is data that shows that we do in fact actually get real money,
now we're talking.
Okay, so if we look at the requirements the way we've been looking at them,
for requirement 4, I guess your main fails have been on TLS?
Typically.
Not having the transition program in place?
Right.
Anything else in 4.1 or 4.2 that are real gotchas for
merchants or service providers?
Well, so you could argue that the ciphers are not about the transition, right?
They're just about the protocol,
and so you get a lot of people complaining like oh,
I fixed this,
I fixed this; why do I still have vulnerabilities show up in my scan?
Why is my assessor still crowding at me about TLS?
Well, you fix the protocol, you then fix the ciphers,
right, or you've got bum certificates.