I think that many instances are disabling checks in order to troubleshoot something and then never enabling it again. And we see this on all levels - development, devops and also sysops of course. Just quickly disabling something without leaving a TODO, disabling a MSDeploy certificate check because a proper PKI has never been set-up, just ignoring any certificate errors in LAN management tools because installing a certificate is so hard.

Somewhat related is a recently discovered bug in the qBittorrent client where SSL checks had been disabled for a long time before someone noticed:

https://news.ycombinator.com/item?id=42004219

Kind of related, but a little off-topic: I think tying name checking to encrypting traffic was a mistake. They are two different use cases, and shouldn't have been so tightly coupled.

Sometimes I care only about my traffic being encrypted, and resent having to jump through hoops to ignore the name mismatch. Sometimes I care only about assurances that the name is correct, and don't care about having the traffic encrypted.

I just today reviewed a PR with a default insecure option. But here we’re working on local networks where there’s no way to get a certificate because there’s not a domain name that points to the local IP address.

At least with HTTPS over the local network, it can frustrate attempts to break into it. That said we are sure to call it “https-insecure”.

Except in airgap environments where there is no CA available to check against.