I can't answer that right now, I don't have a tinfoil hat handy. Sorry.

Good answer. To be fair to the parent post, the certificate authorities *do* have some work to do in cleaning their own houses. Stolen or compromised certificates do exist, and while we can revoke the ones we know about, there's the ones we don't know about, and there's the clients that don't handle revocation properly. It's not clear that the CA houses are doing their jobs well enough.

Next time say, "I'm sorry, I'm a professional software developer, and I have to follow certain principles, same as a doctor or lawyer must follow their respective professional codes. Please contact me when your server side is properly configured and I will be able to complete the work."

Probably no shock that it's a PHP developer:

$opts[CURLOPT_SSL_VERIFYPEER] = false;
$opts[CURLOPT_SSL_VERIFYHOST] = 2;

That's not wrong, but it still doesn't explain to me why I, as a user, should trust both application A and site B that have agreed to trust each other with a self-signed certificate. The reason was have the CA model is to introduce a trusted third-party* that can verify for us that everything is on the up-and-up. The user should not be in the position of having to trust unknown parties.

*Yes I know the CA companies have problems. Maybe the model is so broken by nature that it doesn't matter, but it's still true that the self-signed model bypasses it.

Defrauding unsuspecting third parties and exposing them to identity theft is still a crime, or at least a civil liability, even if you have a family. Participating in that kind of thing is unethical at best.

Well said. If the company doesn't start out with enough money to purchase the things necessary, it's not doing it right. To attempt a real-world analogy, would you put your money in a bank that delayed purchasing a vault until it had enough of the customer's money to afford one?

Do they actually check or are you saying they could or should?

They might be, but then who in their right mind would trust that kind of party with their money and PII? In choosing how to spend their limited cash, they forgo proper security precautions, and they want users to trust them not to misuse or misplace sensitive information?

Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".

If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?

Translation: I just wanted to take the money and run. Making money, that was the important thing. Yeah, money. Did I mention I needed the money?

Let me tell you the story about the guy who wanted to use oauth2 bearer tokens over an unsecured connection.

à_à
This is why we can't have nice things.

I would not use $RANDOM_SHOPPING_BANKING_APP, but I would visit a bank website using chrome, firefox, or the built-in android browsers. Those three programs, while undoubtedly not flawless, at least have enough respectability and history for me to trust them as well as anything on the internet. Admittedly, that's not much trust, but it's something.

Presumably you can write them for iOS, and I have no doubt that there are plenty of apps on the AppStore that are playing fast and loose with SSL trust managers.

True fact: I have written Java code to allow for self-signed or any old cert over SSL, or even none. It's not hard to find plenty of sample code. In the course of my employment the code was used for testing only and either not part of a production build or disabled by default in production, but I cannot say what other developers or teams may have done in with my code in their systems.

Why the authors focused on Android and why they felt the need to blame the OS rather than alerting people to cruddy apps, one can only speculate.