Did PCI Just Kill E-Commerce By Saying SSL is Not Sufficient For Payment Info ? (spoiler: TLS!=SSL)
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
| Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
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.
Anonymous
Feb 11th 2015
9 years ago
Anonymous
Feb 11th 2015
9 years ago
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/
Anonymous
Feb 11th 2015
9 years ago
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.
Anonymous
Feb 12th 2015
9 years ago
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.
Anonymous
Feb 12th 2015
9 years ago
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.
Anonymous
Feb 12th 2015
9 years ago
Isn't that true whether or not you use the JavaScript crypto API?
Anonymous
Feb 18th 2015
9 years ago
Anonymous
Mar 2nd 2015
9 years ago