SSL and TLS (the newer version of the standard) is one of many transport mechanisms that allows PKI to work over the network (originally, there was X.500). I'll be using TLS for the remainder of the answer. It's outside the scope of this forum to describe PKI in full. The exact handshake is like a ballroom dance. Essentially TLS defines the framework for the server and client to identify themselves and agree on an encryption standard and key. It is this identification process that makes PKI possible through TLS.
I'm assuming you are familiar with public and private keys as well as certificates. Everything past this point assumes familiarity with those terms and concepts. Also note that TLS has several encryption and encoding standards, and not all of them support PKI. Typically, both the client and server will need signed X.509 certificates to identify themselves.
Both the server and the client have identities. In a typical online retail situation, the only entity that is really important is the server. The clients have to have confidence that they are interacting with the server they intended to. Just about all retail servers that use SSL/TLS have a certificate, which is a signed public key that advertises the signature authority.
With PKI, the server also needs to know if the client has permission to access the server. The public client certs are signed by a trust authority that is known to the server (i.e. the server has the public key for the trust authority and validates certificates against that trust cert).
The TLS wikipedia article has the exchange for the three types of handshakes (simple, client-authenticated, and session resume). The handshake that makes PKI possible is the client authenticated handshake. A really simplified version of the handshake is below:
Client -> Hi! Can we talk? I know XYZ and PDQ standards
Server -> Wazzup? Let's use PDQ. Oh, and here's my Creds (credentials)... What's yours?
Client -> Kool, I know you. Here's my creds. You know it's me from now on.
Server -> Sweet, you check out. You know it's me from now on.
Wikipedia has a lot less slang, but this is the basics of how PKI works over TLS. The client needs to be confident that it has the right server, and the server needs to be confident the client is who they say they are.
Important note: The effectiveness of the key exchange depends entirely on how the keys are managed. This means the policies and procedures for identifying that a client's key is in fact tied to that client is not sound, neither will the PKI be robust. Additionally, if the trust authority's private key is known by a number of people, or is unencrypted, then that trust authority cannot be trusted. The same with the client private key. TLS handles the Public Key part, but the Infrastructure is all in how you manage the keys that cooperate in this whole exchange.
I think it mainly depends on what you see as "the OS". If it is the kernel, my answer would be: why should it?
I might be wrong, but is DNS not a part of the glibc on Linux systems, which is a thrid-party library?
If it is not about kernel or user space, nearly every OS / platform has an SSL / TLS stack, some might have more than one.
It can even be seen as an advantage. If there was no OpenSSL, you would have to adapt to the Windows, Mac and Linux ( and ... ) API. TLS not beeing part of the OS allows to write cross platform TLS applications. Just pick a TLS library, that supports your target platforms.
For me, the real problem with TLS is, that you can not simply "turn it on". Instead, you have to manage a set of trusted certificates, certificate revocation lists, self signed certificates and so on. All of these require lots of user interaction.
Sadly, security never comes for free. It is effort for programmers and inconvenience for users.
Best Answer
In the time since this question was asked, a lot has changed. Does your site need HTTPS? YES!
Certificates with domain validation are free from many providers, e.g. Let's Encrypt. These certificates are just as good as those for which you pay money. Thanks to server name identification, it is not necessary to own an IP address.
Browsers are increasingly marking non-HTTPS pages as insecure, rather than neutral. Having your site marked as insecure doesn't look good.
Modern web technologies require encryption. Whether it's Chrome's policy of only enabling new features for HTTPS sites, Google's preferred ranking for HTTPS sites, or encrypted HTTP/2 being faster than plaintext HTTP/1.1, you are leaving opportunities on the table. Yes, encryption does add load to your servers, but this is unnoticeable for most sites – and particularly unnoticeable to users.
Privacy is more important than ever. Whether it's ISPs selling your clickstream or secret services sifting through all your connections, there's no good reason to leave any communication publicly visible. Use HTTPS by default, and only use HTTP if you're sure any transmitted information can safely be public, and may be tampered with.
Note that passwords must not be transmitted over plaintext connections.
Under some regulations such as the EU-GDPR, you are required to implement state of the art security measures, which would generally include HTTPS for websites.
There are a couple of non-solutions:
“Use OAuth instead of passwords” misses the point that there still are password-like tokens involved. At the very least, your users will have a session cookie that must be protected, as it serves as a temporary password.
Self-signed certificates are rejected by browsers. It is possible to add an exception, but most users will not be able to do that. Note that presenting a self-signed cert is indistinguishable to the user from a MITM attack using an invalid cert.
So: Certificates are free and HTTPS can make your site faster. There is no longer any valid excuse. Next steps: read this guide on migrating to HTTPS.