Did PCI Just Kill E-Commerce By Saying SSL is Not Sufficient For Payment Info ? (spoiler: TLS!=SSL)

Published: 2015-02-11
Last Updated: 2015-02-11 19:27:04 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

The "Council's Assessor Newsletter", which is distributed by the Payment Card Industry council responsible for the PCI security standard, contained an interesting paragraph that is causing concerns among businesses that have to comply with PCI for online transactions. [1]

The paragraph affects version 3.1 of the standard. Currently, version 3.0 of the standard is in effect, and typically these point releases clarify and update the standard, but don't include completely new requirements. In short, the newsletter states that

 no version of SSL meets PCI SSC's definition of "strong cryptography" 

Wow. Is this the end of e-commerce as we know it? I thought SSL is (was?) THE standard to protect data on the wire. Yes, it had issues, but a well configured SSL capable web server should be able to protect data as valuable as a credit card number adequately. So what does it mean?

Not quite. You can (and should!) do https without SSL. Remember TLS? That's right: SSL is out. TLS is in. Many developers and system administrators use "SSL" and "TLS" interchangeably. SSL is not TLS. TLS is an updated version of SSL, and you should not use ANY version of SSL (SSLv3 being killed by POODLE). So what you should do is to make sure you are using TLS, and this "new" rule wont affect you at all.

Secondly, you could try to take advantage of new JavaScript APIs to encrypt the data on the client before it is ever sent to the server. This is a neat option, that is not yet available in all browsers, but something to consider in particular if you pass payment information to backend systems. In this case, you pass a public key as a JavaScript variable, and then use JavaScript on the client to encrypt the card number. Only backend systems that need to know the raw payment data will have the private key to encrypt this information.

Next: Also make sure your system administrators, and hopefully your QSAs understand that SSL != TLS and assess you correctly.

[1] https://www.darasecurity.com/article.php?id=31

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

8 comment(s)

Comments

The line:

TLS is an updated version of SSL, and you should not use ANY version of SSL (SSLv3 being killed by POODLE).

could read:

TLS is an updated version of SSL, first released in 1999, and you should not use ANY version of SSL (SSLv3 being killed by POODLE).
------------------
TLS 1.0 is not so much an "updated version" as it is an "ancient version" in Internet years. Even the current TLS v1.2 is old enough to be registered for kindergarten.

If you have clients that still require SSL or RC4, the use of encryption is the least of your worries.
SSLv1 was a "quick hack" by Netscape to enable e-commerce. SSLv2 wasn't much better. I would dare to say that while SSLv3 has issues, it is still not "easily" broken, in particular for data like payment card information which by itself is not all that valuable ;-) . TLS 1.2 is more secure then a payment system that depends on a simple numeric secret that I carry easily readable and unencrypted in my wallet and share with hundreds of merchants I may or may not trust.
> "Secondly, you could try to take advantage of new JavaScript APIs to encrypt the data on the client before it is ever sent to the server."

No, please, no.

"If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code"
http://matasano.com/articles/javascript-cryptography/
[quote=comment#33377]> "Secondly, you could try to take advantage of new JavaScript APIs to encrypt the data on the client before it is ever sent to the server."

No, please, no.[/quote]

I'm curious as to why not. If the client is only encrypting using a public key, what could the harm be? If it's the wrong key it can't be decrypted. If it's the correct key, it's encrypted across the network even if it's clear text.
I think the article you are citing does not say what you think it says, though to be fair, there are a number of things I see in that article that are at least naive if not downright incorrect.

In any case, the original poster is correct. This is why;

A certificate in a PKI hierarchy can be used for several things, including:

Authentication
Authorization
Encryption
Code Signing

When you connect to a web server, you get its public key and use it to authenticate the server. You do this by effectively [if you do PKI stuff for a living just roll with it, this is very simplified] using a public key from a certification authority to say "yes, this web server is who it says it is." After that you use that key to communicate with the server in order to agree on a session key to use between the client and server for the duration of the session in question. Stops being PKI, is now "shared secret." This session key you can sniff and compromise and all that stuff.

What the poster is saying is, in *addition* to the session key, *also*, for cases where the cryptographic overhead is worth it, take that same public key and instead of using it for authenticating the web server, instead use it to *encrypt* the data you are sending that is sufficiently important. There is potentially substantial overhead on doing this calculation on both sides (this is why client and server move to a shared secret/session key model in the first place; literally using a PKI model for every byte of data would be exceptionally resource intensive). This is not so easy to break and sniffing is irrelevant (everyone can read the public key, that's what it's for; it's being able to decrypt what is encrypted with that key which is hard to do without having the private key).

There is no 100% guarantee with any of this due to all the fun we're finding out about crypto generally. But just as SSL != TLS, so SSL and TLS != PKI. PKI is a tool to be used in session encryption, but it does far more than that. And the problems with SSL and TLS are generally related to the protocols using the PKI capabilities for their needs, not the underlying encryption algorithms themselves. So yes, using PKI a different way within a session can materially increase the confidentiality of information encrypted within that session over and above the confidentiality of the session itself.
The fundamental concern about javascript based crypto is that it is fundamentally dynamic code downloaded from insecure locations transparently to the user. You have no assurance about what is being done, or that it is being done correctly because it can change between page loads. It is like using silly putty based door locks.

This is the equivalent of saying "just download this application (or library) from my FTP site and run it" on every reload of the webpage. Cryptography, on the other hand, builds trust by being verifiable. When I am dynamically loading code on every run from a potentially hostile location I have to inspect the code at every run.
[quote=comment#33389]The fundamental concern about javascript based crypto is that it is fundamentally dynamic code downloaded from insecure locations transparently to the user. You have no assurance about what is being done, or that it is being done correctly because it can change between page loads.[/quote]

Isn't that true whether or not you use the JavaScript crypto API?
In fact, provided that you use client side, JavaScript based encryption *with* transport level encryption rather than *instead of* then it can offer some good opportunities for hardening your system architecture. For example, it would help support the so-called "Gatekeeper" pattern where requests are handled first by a low-privilege "Gatekeeper" server which would not have the private key before being validated, sanitized and then handed on to a higher-privilege "Keymaster" server which is more locked down and further from the perimeter than the Gatekeeper, which would be able decrypt the data. This kind of approach can provide good defence-in-depth for security critical systems. I agree though, that thinking of JavaScript based encryption as a replacement for TLS is pretty scary.

Diary Archives