Ideally, how should SSL traffic be treated once it has been terminated at an SSL appliance especially if the traffic contains sensitive information like personal financial information before it's being stored in a database?
-
3Please edit and add your security goals and the constraints of your organization.– GdDCommented Sep 10, 2012 at 10:49
-
1Please clarify - when you say "once it has been terminated at an SSL appliance" are you chiefly concerned with decrypted traffic being re-transmitted across an internal network after terminating at the SSL appliance?– gowenfawrCommented Sep 10, 2012 at 14:26
3 Answers
I don't think it really matters how your application handles the data; if an attacker can access your application's memory you're busted anyway, no matter what security measures you take. So after the connection has been terminated it doesn't matter how you handle it, but it matters how you store it.
The answer is that you should store it encrypted, but then the problem is how to keep the encryption key private: Where to store a key for encryption?
Besides this, I don't think there is much to it.
There is nothing special to "SSL traffic". SSL is used to exchange bytes, and there's only one kind of bytes: those which contains 8 bits. Any byte value can be handled by SSL, and SSL does nothing which depends on the meaning of these bytes. Once the data bytes have been received, there is no SSL anymore; SSL is for transfer only, and not an attribute of the data itself (in the same way that water sent through a copper pipe is not copper-pipe-water, it is just "water" and the copper pipe is totally irrelevant once the water has exited it).
The proper term is "sensitive data": if the data was deemed worth using SSL for its transfer, then it is probably data of some value which should be kept away from the prying eyes and inquisitive fingers of third parties (the "attackers"). Therefore, if the data is to be stored somewhere, then it should probably be stored with care. Not because it came over SSL; but because the data intrinsically needs it.
Analogy: imagine that you are transferring one metric ton of pure gold from one point to another. You will probably want to use an armoured truck, and some armed guards. And then, on the receiving point, you'll want a vault, again with armed guards. Will you need the vault and guards because the gold was transferred with an armoured truck ? Of course not; it is the other way round: you used an armoured truck because the gold is worth a lot and is bound to attract thieves. And you need the vault for the same reason. If you had used an armoured truck and guards to transport one metric ton of turnips, you would not use a vault with armed guards for storage, even if it was delivered with an armoured truck (and, of course, the truck might be seen as a tad overkill for turnips).
Secure storage of sensitive data, especially of a financial nature, can be quite challenging. There are regulations for that, and compliance is often an unavoidable requirement. I advise you to lookup PCI DSS.
This is fundamentally an issue of transport vs message based security - endpoints are the demarcation points for transport security, e.g SSL, whereas the software infrastructure has more control/flexibility over message based security - this issue has been addressed earlier here - When should I use Message layer encryption vs transport layer encryption