Comment by jeroenhd
I think SSL is a better fit, actually. In theory TLS could be a transport-layer security mechanism that would let arbitrary protocols run on top of it (like IPSec does), but in practice it's pretty much tied up to TCP sockets. The UDP variant (DTLS, and I suppose QUIC) isn't part of the TLS spec for instance. Of course we have kernel TLS on Linux now, and Windows also has infrastructure like that, but it isn't as easy as setting a flag on a socket to turn TLS on.
Plus, who doesn't like to sound like a snake sometimes? Snakes are badass.
Speaking of ipsec, ipsec was supposed to be "the" encrypted interchange on the internet, basically used for random secure connections like we use tls today.
I like to imagine an alternate past where ipsec "won" and how that would affect our expectations of secure connections. One thing different is that the security would handled at the os level instead of the application level, on the one hand this is nice all application get a secure connection whether they want one or not, on the other hand the application has no idea it is using a secure transport and has no way of indicating this to the user.
Anyhow the opportunistic connection employment of ipsec never really got implemented and all we use it for anymore is as a dedicated tunnel. one that is fiendishly difficult to employ.
I think the primary problem with ipsec is that it tried to be too flexible. this made setting up a ipsec link a non-trivial exercise in communication, and the process never got streamlined enough to just be invisible and work.