In my experience SSL/TLS is used because HTTP is a decent protocol because it works almost everywhere, including behind proxies and firewalls. Support out in the real world is vast, so it's hard to find cases where another client-server protocol will work in as many scenarios.

This is exactly the point we're leading to - if you need vast heterogenous support everywhere, you're doomed to use TLS/SSL and you'd better cook it well, cause it has plenty of problems.

But, from our point of view, most non-web-developers (mobile? distributed applications? there are plenty), who now use SSL, but can afford themselves either avoid HTTP at all, or implement decent cryptographic stack on top of it, because they control both client and server, and don't need multitude of platforms to talk in the same way.

That's the point we're leading to in this article.

I guess I was thinking mobile using a home/corporate wifi network, which means you're back to (possibly) dealing with proxies, etc. Even if you control client and server, your protocol has to work over the network you are running on. Today that's HTTP based.

Well, network is TCP/IP based last time I've checked, but yes, most people today tend to organize such communications over HTTP for simplicity (although it's not that good at all), I get your point.

I agree that tls/ssl is really old complicated system with lots of cornercases in implementation. It's okay, but only if it's implemented in a proper way. I, as app developer, tend to skip to ‘what should I do’ section, and it’s good this time!