Warum ist SSL / TLS nicht in moderne Betriebssysteme integriert?

Viele der grundlegenden Netzwerkprotokolle, aus denen sich die Infrastruktur des Internets zusammensetzt, sind in den meisten wichtigen Betriebssystemen integriert. Beispielsweise sind TCP, UDP und DNS in Linux, UNIX und Windows integriert und werden dem Programmierer über System-APIs auf niedriger Ebene zur Verfügung gestellt.

Wenn es jedoch um SSL oder TLS geht, muss man sich an eine Drittanbieter-Bibliothek wie OpenSSL oder Mozilla NSS wenden.

SSL ist ein relativ altes Protokoll und im Grunde genommen ein Industriestandard, der so allgegenwärtig ist wie TCP / IP. Warum ist es also nicht in den meisten Betriebssystemen integriert?

Ich denke, es hängt hauptsächlich davon ab, was Sie als "das Betriebssystem" sehen. Wenn es der Kernel ist, wäre meine Antwort: Warum sollte es? Ich könnte mich irren, aber ist DNS nicht Teil der glibc auf Linux-Systemen, die eine Drittanbieter-Bibliothek sind?

Wenn es nicht um Kernel oder User Space geht, hat fast jedes Betriebssystem / jede Plattform einen SSL / TLS-Stack, einige haben möglicherweise mehr als einen.

Es kann sogar als Vorteil angesehen werden. Wenn es kein OpenSSL gäbe, müssten Sie sich an die Windows-, Mac- und Linux-API (und ...) anpassen. TLS, das nicht Teil des Betriebssystems ist, ermöglicht das Schreiben von plattformübergreifenden TLS-Anwendungen. Wählen Sie einfach eine TLS-Bibliothek aus, die Ihre Zielplattformen unterstützt.

Für mich ist das eigentliche Problem bei TLS, dass man es nicht einfach "einschalten" kann. Stattdessen müssen Sie eine Reihe vertrauenswürdiger Zertifikate, Sperrlisten für Zertifikate, selbstsignierte Zertifikate usw. verwalten. All dies erfordert viel Benutzerinteraktion.

Leider ist die Sicherheit nie kostenlos. Es ist Aufwand für Programmierer und Unannehmlichkeiten für Benutzer.

Es liegt ein rechtliches Problem vor. Einige Länder ordnen Kryptografie in dieselbe Gruppe wie Waffen ein. Das Einfügen von kryptografischem Code in den Kernel erschwert dann das Exportieren des Kernel-Codes.

Die Integration von TCP in das Betriebssystem bietet offensichtliche Vorteile. TCP erfordert präzises Timing und schnelle Reaktion auf Netzwerkpakete, auch wenn keine Anwendungsdaten betroffen sind. Wenn Sie versuchen, TCP im Benutzerbereich über eine generische IP-API zu implementieren, ist dies viel schlimmer. Die Integration von SSL in den Kernel bietet keine ähnlichen Vorteile.

Andererseits gibt es einige Nachteile. Zum Beispiel erfordert SSL das Manipulieren von Schlüsselringen und Listen von Zertifikaten und dergleichen. Dies über einen Kernel oder eine OS-API zu tun, wäre unelegant. Selbst wenn es mit dem Betriebssystem geliefert würde, wäre es nur eine Bibliothek (genau wie in Windows). Diese Bibliotheken sind ohnehin schon verfügbar, es handelt sich also letztendlich nur um eine Änderung der Verpackung.

Es gibt eine Reihe von Gründen, aber die vielleicht überzeugendste ist, dass es sehr, sehr schwierig ist, Kryptografie tatsächlich richtig zu machen . Es ist nicht ratsam, es selbst zu implementieren, es sei denn, Sie können umfangreiche Ressourcen einsetzen, um zu überprüfen, ob es korrekt und stark ist. Die meisten Leute, die mit kryptografischer Software arbeiten, haben nicht die Zeit, das Fachwissen oder den Wunsch, sich damit zu beschäftigen. Sie vertrauen Bibliotheken von Drittanbietern, damit ihre Entwickler diesen Teil der Arbeit erledigen können, während die Anwendungsentwickler wieder das machen können, was sie machen möchten.

Betriebssystementwickler sind nicht so unterschiedlich. Manchmal gibt es ein ausschlaggebendes Interesse, zum Beispiel, wenn Sie von Ihrem Geschäftsmodell oder Anwälten dazu aufgefordert werden, den Kodex geschlossen zu halten, und Sie haben in dieser Angelegenheit keine große Wahl: Wenn Sie niemanden finden, der Sie dazu ermächtigt was du musst, dann musst du deine eigenen rollen. Andere haben bereits erwähnt, wie Microsoft dies tut. Im Allgemeinen bevorzugen es OS-Entwickler, die Bibliotheken von Drittanbietern verwenden können, aus denselben Gründen wie Anwendungsentwickler, dies zu tun.

Ich bin ein Windows-Entwickler, daher kann ich nicht für andere Betriebssysteme sprechen, aber unter Windows war SSL sehr lange eingebaut. Sie nennen es SChannel und obwohl es unterstützt wird, ist es eine der kryptischeren APIs, die man jemals herausfinden müsste.

SSL ist eine Schicht über dem Protokoll einer niedrigeren Ebene. Zum Beispiel läuft SSL über TCP (also über IP).

Wo hört das Betriebssystem auf?

Es ist sehr einfach zu argumentieren, dass das Betriebssystem grundlegende Dienste wie das Vernetzen bis zu einem Punkt bereitstellt, an dem ein Client des Betriebssystems "Sachen macht". Und das Zeug kann alles sein, was du willst.

Es ist ziemlich unwahrscheinlich, dass SSL im Kernel zu einem massiven Leistungsgewinn führt. Warum also die Mühe machen?

Moderne Betriebssystem-Kernel werden in Millionen von Codezeilen ausgeführt, was die Komplexität und die Debugging-Zeit erhöht. Wenn Sie Dinge wie Protokolle höherer Ebenen aus dem Betriebssystem herauslassen, wird die Betriebssystementwicklung einfacher, und letztendlich hat dies nur einen geringen Einfluss auf die Funktion oder Leistung einer Endanwendung. (Dies könnte die Arbeit der Entwickler für die Endanwendung etwas schmerzhafter machen.)

Es gibt einige Kernel-Unterstützung für Crypto und SSL. Dies ist sinnvoll, da der Kernel effizienter mit der Hardware kommunizieren kann und es auch praktisch ist, Anmeldeinformationen vor jeder Anwendung zu schützen. Gute Beispiele sind kssl, ein Reverse-SSL-Proxy auf Kernel-Ebene in Solaris oder die verschiedenen Kryptobibliotheken im Kernel (zum Beispiel für VPNs). Eine typische hardwarebeschleunigte Krypto-Engine verfügt auch über ein Kernelmodul (und ist über PKCS # 11 oder betriebssystemspezifische Krypto-Schnittstellen zugänglich).

Einige Gründe, warum Sie es nicht öfter sehen, sind, dass einige Anwendungsprotokolle nicht richtig geschichtet sind (denken Sie an STARTLS) oder Anwendungsentscheidungen beim Handshake erfordern (denken Sie an die Überprüfung von Clientzertifikaten und CRLs) oder sich einfach in einer regelmäßigen Entwicklung befinden.