I would not bother with a technical explanation of any of this stuff. He doesn't care, and bluntly it's not particularly easy to point to major compromises in which the lack of SSL played a key role. Most of the time, data is siphoned out of "PCI-compliant" shops that do use SSL, and they get it through database compromises and/or compromised POS terminals. MITM doesn't seem to be worth the effort, if only because the other stuff is so easy and yields so much data.
Nor would I bother talking about PCI. Most of their requirements are silly and do little or nothing to prevent exposure of PII or fraud. What matters to him is the agreement with his processor, not some 4000-page document that wants to tell you how to take a piss.
Eyes on the money. No processor, no business, no money. Keep it simple. If that doesn't do it, you've done your part and should walk away. It's not your problem.
For Credit Card information it has to all be transmitted and stored in an securely in accordance to the credit card merchant agreement he has agreed too.
The HTTP protocol is not secure, when your family member is hacked or audited they may be liable for many civil and criminal charges.
Have them read all the information for PCI DSS compliance - https://www.pcisecuritystandards.org/merchants/
You have done your part by advising him about the risks, privacy concerns and how bad it really is. Either way it is ultimately a risk he is accepting for himself and the business which he will have to deal with the consequences when something bad occurs in the future.
If he needs proof of how bad the decisions he has made can be, point him to many of the recent credit card and government organization breaches.
Scaring them with the bad stuff might not be effective, people don't react well to being told they're doing everything wrong. Perhaps showing them an easier solution that reduces their admin hassles & could potentially increase their sales is a better way to approach this.
With that said, I do know that many states have strict laws regarding the collection/use of SSN numbers via websites and/or for the sale of goods.
As for the credit card info, I believe most processors have in their terms that SSL is required for live transactions. I was also going to point to PCI compliance, but I am not sure how aggressive they are at going after the "little guy". Although with credit card theft in the US being a hot topic right now, I am sure anyone that is non-compliant will be a target for violations.
EDIT: To add link, starting at Page 12 talks about various state laws regarding SSN collection: http://www.gao.gov/new.items/d051016t.pdf
You can't do it solely based on one single number, but in this case a data breach would include name, address, credit card number, SSN, and probably security questions. You can turn around and use that information to play the part of a person to another organization, and then go from there. Combine that data with social engineering, and you can get a lot of information about someone and then use it in further attacks.
That's not to say the US's system isn't broken; lots of companies ask for (and require!) the SSN even though they shouldn't. The problem is that it's not just one identifier that holds the key to your life, but that the SSN is an extremely strong identifier which is assumed to be secret.
It should never be possible to do what you're suggesting, not unless the USA is failing to collect that info in the first place.
SSN numbers were originally only supposed to be used as a government identifier for social security, however, they have evolved into a unique identifier for all US citizens. They are used in every facet of the banking/credit industry here and are relied upon in determining financial decisions. For example, it is completely possible to simply know someone's SSN and date of birth to obtain a credit card. Although many banks/credit card companies are asking for increasing amounts of information to confirm it is really the person applying.
We have our national ID number uniquely identifying us, our VAT record number as well, but neither is secret (companies will ask them for verification, or to issue an invoice for purchases for the latter). There's no identity theft I know of, as you have to show your ID to do anything sensitive anywhere.
Regardless, between the greed and the complete lack of interest in security in this area leads customers extremely vulnerable as the only things that are required to open a credit card in another person's name are usually a name, address, date of birth, and social security number, all of which are essentially public to anyone who is even the least bit dedicated to committing fraud. This current situation benefits banks so much, the few costs they do actually have to pay for insurance and after the fact pale in comparison.
The second thing, the fact it's http and not https suggests he's collecting and storing this information, which is almost certainly a violation of his credit card agreement with his bank. Credit card information is not supposed to be stored, he passes that off through a secure connection with his processing service, who will only do that through a secure connection, and he gets a transaction ID and authorization and that's all he references from that point on.
So this is less about SSL/TLS as it is, he's doing it all wrong. And it's depressing that he's in business, only made possible by the ignorance of his customers who actually agree to give him all of this information, and on an insecure connection no less.
Online shoppers I've observed in usability sessions often scour sites looking for evidence of security measures (e.g., green EV certs in the browser, various icons in the footer). This is especially true when you're asking for something like SSN info...
If appealing to the desire for security of user info doesn't work (unfortunately), appeal to his desire for more customers...
Read section 4 specifically.
"You are losing sales. People look for the lock icon on the address bar."
Also, he can get SSL on his site for FREE in < 5 minutes using Cloudflare.
Also, for a totally non-technical person, it will take – and be billed as – more than 5 minutes of someone else's time to get even that free half-measure into effect.
That raises an interesting question: how could a person determine if the connection between an edge (say, Cloudflare) and the destination server is actually encrypted? I can't think of a way to do this unless you know the address of the true IP of the destination and poke it on the SSL port. That still doesn't guarantee SSL is being used, though.
In my opinion best practice would be to obscure what the "true IP" of the backend server is, and only accept connections from Cloudflare. (I don't know if Cloudflare offers any options for this stronger than trusting their IP ranges, such as a client certificate on their outbound-SSL.) So if you could "poke [the true origin] on the SSL port", that could itself be evidence of suboptimal security.
This is what I was planning to do when I launch the app I'm working on now. Thanks for the reply.
At least it isn't some guys backyard CMS.
Please do not do that. That doesn't solve the problem at all if the origin server is still serving the content over HTTP. You're just lying to visitors by making them think it's secure when it's really not.
Magento is like any other PHP app.. there's Apache (or some other webserver) in front of it.. so just setup Apache properly.