Warum ist SSL / TLS nicht in moderne Betriebssysteme integriert?

15

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?

Channel72
quelle
5
Was ist der praktische Unterschied zwischen "eingebaut" und "gebündelt mit"? Soweit ich weiß, werden alle Betriebssysteme mit gebündelten Implementierungen von SSL / TLS ausgeliefert.
Zneak
Der Unterschied besteht darin, dass TCP und DNS im Kernel-Code implementiert sind. SSL ist jedoch nur über Bibliotheken von Drittanbietern verfügbar. Die Installation der SSL-Unterstützung ist in der Regel eine einfache Angelegenheit, und viele Betriebssysteme sind bereits im Lieferumfang enthalten. Es gibt jedoch praktische Nachteile: Wenn ich beispielsweise eine Bibliothek schreibe, die eine bestimmte SSL-Implementierung verwendet (z. B. OpenSSL, NSS, GnuTLS usw.) Meine Software hat jetzt eine Abhängigkeit, mit der sich Benutzer befassen müssen. Dies ist kein Problem, wenn SSL in das Betriebssystem integriert ist. Ich meine, es ist nicht so, als würde ich mir Sorgen machen, wenn einer meiner Benutzer Unterstützung für TCP installieren muss.
Channel72
3
Ich glaube nicht, dass integriertes SSL das von Ihnen erwähnte Problem lösen würde. Anstatt von bestimmten Bibliotheken abhängig zu sein, sind Sie jetzt von bestimmten Betriebssystemen abhängig.
Zneak
1
Warum gibt es keine JPEG-Bibliotheken? Gleiche effektive Frage. Sie sehen die falsche Position des Stapels. Alle modernen Betriebssysteme verfügen über ein Paket für die SSL-Unterstützung. (MSFT hat das .NET SDK, Linux / Solaris haben eine Reihe, + es gibt andere)
Iivel
3
Möchten Sie es wirklich im Kernel haben? Mir kommt es schon furchtbar voll vor.
Matthieu M.

Antworten:

8

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.

paztulio
quelle
Die überwiegende Mehrheit der Sicherheitsinstallationen kann ohne Benutzereingriff erfolgen. Unannehmlichkeiten treten nur auf, wenn Benutzer Zertifikate verwenden, denen nicht vertraut werden kann.
Zneak
1
Das ist wahr. Aber es gibt so viele selbstsignierte Zertifikate. IMO, das gesamte Modell der zentralen Behörden ist nicht skalierbar. Wie kann man entscheiden, welchen Wurzeln man vertrauen soll? Kein Benutzer wird sich dafür entscheiden. Sie alle hoffen, dass die Programmierer mit Bedacht gewählt haben.
Paztulio
Zertifikate haben nicht viel mit "echtem" Vertrauen zu tun, sondern ergänzen nur die Verschlüsselung. Was nützt ein verschlüsselter Kanal, wenn Sie mit einem Schurken-Server sprechen? Der Zweck von Zertifikaten besteht darin, zu beweisen, dass Sie mit dem richtigen Computer kommunizieren, und zu diesem Zweck ist nur jedes Stammzertifikat, das Sie auf sichere Weise erhalten haben, ausreichend, um die Authentizität zu überprüfen. Im Übrigen beweisen Zertifikate nichts über die Absichten einer Person, sondern nur, dass es sich um die reale Person handelt und nicht um eine Fälschung.
Zneak
6

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.

dan_waterworth
quelle
2

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.

David Schwartz
quelle
1

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.

Der Löffeligste
quelle
0

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.

DXM
quelle
0

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.)

schnell_nun
quelle
0

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.

eckes
quelle