Still feels very relevant, since I don't think much has been systematically changed.
Structurally, SSL verification is in the same category as stuff like SELinux: most people that interact with it understand why it exists, why it's needed... but the actual process of using anything related to SSL is an exercise in frustration. So the default response is to degrade it or turn it off entirely because shit isn't working for them. (The second search suggestion for SELinux is to change it to permissive, which effectively turns it off without having your distro tools yell at you for disabling it.)
Even today, OpenSSLs interfaces are horrendously designed (if you've ever chose to mess with a proper self-signed cert setup with a custom CA and everything, you'd be aware of how bad their CLI tools are). I wouldn't be surprised if this is a case of it propagating upwards from them; OpenSSLs bad interfaces lead to bad CURL flags, which in turn leads to bad checks by more high level implementations... which goes all the way until you get the HTTP library that just does away with all the fanfare and has a function that accepts all you need for a URL and under the hood handles all those other implementations. (ie. requests for urllib3.)
It also really doesn't help that SSL errors tend to be... unhelpful at the best of times in most cases. You're usually fishing out random error codes that don't seem to have any clear relationship to what you're doing; it creates an aversion to having to engage with the process at all.
And that's for the programming side of things; the dev UX may be bad, but on the user side it tends to be way worse. This isn't about browsers, but it makes no sense that a regular HTTP connection just works, but the moment an SSL certificate is expired for a single second, you have to click through big red scare screens. It'd make more sense if both the certificate and HTTP connection threw up scare screens, but they don't. Instead you just get the strike-through lock of disappointment in your address bar. Makes zero sense.
Still feels very relevant, since I don't think much has been systematically changed.
Structurally, SSL verification is in the same category as stuff like SELinux: most people that interact with it understand why it exists, why it's needed... but the actual process of using anything related to SSL is an exercise in frustration. So the default response is to degrade it or turn it off entirely because shit isn't working for them. (The second search suggestion for SELinux is to change it to permissive, which effectively turns it off without having your distro tools yell at you for disabling it.)
Even today, OpenSSLs interfaces are horrendously designed (if you've ever chose to mess with a proper self-signed cert setup with a custom CA and everything, you'd be aware of how bad their CLI tools are). I wouldn't be surprised if this is a case of it propagating upwards from them; OpenSSLs bad interfaces lead to bad CURL flags, which in turn leads to bad checks by more high level implementations... which goes all the way until you get the HTTP library that just does away with all the fanfare and has a function that accepts all you need for a URL and under the hood handles all those other implementations. (ie. requests for urllib3.)
It also really doesn't help that SSL errors tend to be... unhelpful at the best of times in most cases. You're usually fishing out random error codes that don't seem to have any clear relationship to what you're doing; it creates an aversion to having to engage with the process at all.
And that's for the programming side of things; the dev UX may be bad, but on the user side it tends to be way worse. This isn't about browsers, but it makes no sense that a regular HTTP connection just works, but the moment an SSL certificate is expired for a single second, you have to click through big red scare screens. It'd make more sense if both the certificate and HTTP connection threw up scare screens, but they don't. Instead you just get the strike-through lock of disappointment in your address bar. Makes zero sense.
A good reason to actually test that you reject man in the middle certs if you rely on TLS in your application
[2012]
The situation has improved somewhat, although some of the underlying libraries have changed little so it's still easy to write insecure TLS.
cURL's API was improved in 7.66.0 for example: https://github.com/curl/curl/pull/4241
But the Java APIs are likely little changed.
And, the worst part is that because it is an "application" issue, it is possible that it is going to a "gift that keeps on giving" for a long time.
And the worst part is that most (indian) banks have been using only android/ios for "security" for some time now.