17

A lot of the basic network protocols that make up the infrastructure of the Internet are built in to most major Operating Systems. For example, TCP, UDP, and DNS are all built into Linux, UNIX and Windows, and are made available to the programmer through low-level system APIs.

But when it comes to SSL or TLS, one has to turn to a third-party library such as OpenSSL or Mozilla NSS.

SSL is a relatively old protocol, and it's basically an industry standard as ubiquitous as TCP/IP, so why isn't it built into most Operating Systems?

Channel72
  • 2,475
  • 5
  • 27
  • 28
  • 6
    What is the practical difference between 'built-in' and 'bundled with'? As far as I know, all OSes somehow come with bundled implementations of SSL/TLS. – zneak Mar 20 '11 at 01:01
  • The difference is that TCP and DNS are implemented in kernel code. But SSL is only available through third-party libraries. While it is usually a trivial matter to install SSL support, and many OS's even come with it out-of-the-box, there are still practical disadvantages: For example, if I write a library that uses a particular SSL implementation, (like OpenSSL, NSS, GnuTLS, etc) my software now has a dependency which users must deal with. This would be a non-issue if SSL was built into the OS. I mean, it's not like I worry if any of my users will need to install support for TCP. – Channel72 Mar 20 '11 at 01:10
  • 3
    I don't think having built-in SSL would solve the problem you mention. Now, instead of depending on specific libraries, you'll be depending on specific operating systems. – zneak Mar 20 '11 at 01:13
  • 2
    Why are there not jpeg libraries? Same effective question. You're looking at the wrong location of the stack. All modern OSs have something bundled to provide SSL support. (MSFT has the .NET SDK, linux/solaris have a bunch, +there are others) – iivel Mar 20 '11 at 01:18
  • 4
    would you really want it in the kernel ? It seems awfully crowded to me, already. – Matthieu M. Mar 20 '11 at 14:26
  • @Channel72 hm, DNS is typically (unless you think of filtering) not done in the kernel but the system libraries. – eckes Aug 13 '14 at 00:07

7 Answers7

10

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.

paztulio
  • 201
  • 1
  • 3
  • The vast majority of the security plumbing can happen without any user interaction. Inconvenience occurs only when people use certificates that cannot be trusted. – zneak Mar 20 '11 at 01:10
  • 1
    This is true. But there are so many self-signed certs out there. IMO, the whole model of centralized authorities does not scale. How to decide which roots to trust? No user will decide on this. They all hope the programmers did choose wisely. – paztulio Mar 20 '11 at 01:17
  • Certificates aren't much about "real" trust, they just complement encryption. What good is an encrypted channel if you speak with a rogue server? The point of certificates is to prove that you are communicating with the right computer, and to that end, just any root certificate you received through secure means is enough to validate the authenticity. For the rest, certificates don't prove anything about the intentions of a person, they just prove it's the real person and not some spoof. – zneak Mar 20 '11 at 04:24
8

There is a legal problem. Some countries put cryptography in the same group as arms. Putting cryptographic code in the kernel then makes exporting any of the kernel code more difficult.

dan_waterworth
  • 7,287
  • 2
  • 34
  • 45
2

There are obvious benefits to building TCP into the operating system. TCP requires precision timing and rapid response to network packets even when no application data is involved. If you tried to implement TCP in user space on top of a generic IP API, it would be much worse. There are no similar advantages to integrating SSL in the kernel.

On the other hand, there are a few disadvantages. For example, SSL requires manipulating key rings and lists of certificates and the like. Doing that through a kernel or OS API would be inelegant. So even if it came with the operating system, it would just be a library (just like it is in Windows). Those libraries are already available anyway, so it's ultimately just a change in packaging.

David Schwartz
  • 4,676
  • 22
  • 26
1

There are a number of reasons, but perhaps the most compelling is that cryptography is very, very hard to actually get right. It is unwise to implement it yourself unless you can devote major resources to verifying that it is correct and strong. Most people who work with cryptographic software don't have the time, expertise, or desire to bog down in this; they trust third-party libraries so that their devs can handle that part of the work, while the application developers can get back to making what they want to make.

OS developers are not so different. Sometimes there is an overriding interest -for example, your business model or lawyers require you to keep the code closed- and so you don't have much of a choice in the matter: if you can't find someone who will let you do what you have to, then you have to roll your own. Others have already mentioned how Microsoft does this. But generally speaking, OS developers that can use third-party libraries prefer to do it that way, for the same reasons that application developers do.

The Spooniest
  • 2,160
  • 12
  • 9
0

There is some Kernel support for Crypto and SSL. This makes sense because the Kernel can more efficiently interface with the hardware and it is also convinient to protect credentials from any application. Good examples are kssl, a Kernel-level reverse-SSL Proxy in Solaris or the various crypto libraries in kernel (used for example for VPNs). A typical hardware accelerated crypto engine also has a kernel module (and is accessible over PKCS#11 or OS specific crypto interfaces).

Some reasons why you dont see it more often is that some application protocols are not properly layered (think STARTLS) or require application decisions while handshake (think client certificate and CRL checking) or are simply in a regular evolution.

eckes
  • 101
  • 4
0

I'm a windows developer so I can't speak for other OSes, but on Windows they had SSL built in for a very long time. They call it SChannel and while it is supported, it is one of the more cryptic APIs that one would ever have to figure out.

DXM
  • 19,932
  • 4
  • 55
  • 85
0

SSL is a layer over the top of a lower level protocol. For example SSL runs over the top of TCP (which is over the top of IP).

Where does the OS stop?

It's very easy to argue that the OS provides basic services such as networking up to a point where a client of the OS "does stuff". And that stuff can be whatever you want.

Its pretty unlikely that SSL in the kernel is going to lead to a massive performance gain, so why bother?

Modern OS kernels run to millions of lines of code, adding more just adds complexity and more debugging time. Leaving things like higher layer protocol stuff out of the OS makes the OS development easier and in the end makes little difference to the function or performance of an end-application. (It might make the developers job for the end application a bit more painful.)

quickly_now
  • 14,822
  • 1
  • 35
  • 48