web-dev-qa-db-ja.com

SSL / TLSが最新のオペレーティングシステムに組み込まれていないのはなぜですか?

インターネットのインフラストラクチャを構成する基本的なネットワークプロトコルの多くは、ほとんどの主要なオペレーティングシステムに組み込まれています。たとえば、TCP、UDP、DNSはすべてLinux、UNIX、Windowsに組み込まれており、低レベルのシステムAPIを介してプログラマーが利用できるようになっています。

ただし、SSLまたはTLSに関しては、OpenSSLやMozilla NSSなどのサードパーティライブラリを使用する必要があります。

SSLは比較的古いプロトコルであり、基本的にはTCP/IPと同じくらいユビキタスな業界標準なので、なぜそれがほとんどのオペレーティングシステムに組み込まれていないのですか?

16
Channel72

それは主にあなたが「OS」として見るものに依存すると思います。それがカーネルである場合、私の答えは次のとおりです。なぜそれが必要なのですか?私は間違っているかもしれませんが、DNSは、サードパーティのライブラリであるLinuxシステムのglibcの一部ではありませんか?

カーネルまたはユーザー空間に関するものではない場合、ほぼすべてのOS /プラットフォームにSSL/TLSスタックがあり、一部には複数のスタックがあります。

それは利点としても見ることができます。 OpenSSLがない場合は、Windows、Mac、およびLinux(および...)APIに適応する必要があります。 TLSはOSの一部ではないため、クロスプラットフォームのTLSアプリケーションを作成できます。ターゲットプラットフォームをサポートするTLSライブラリを選択するだけです。

私にとって、TLSの本当の問題は、単に「オンにする」ことができないことです。代わりに、信頼できる証明書、証明書失効リスト、自己署名証明書などのセットを管理する必要があります。これらはすべて、多くのユーザー操作を必要とします。

悲しいことに、セキュリティは決して無料ではありません。これはプログラマにとっての努力であり、ユーザーにとっては不便です。

9
paztulio

法的な問題があります。一部の国では、暗号化を武器と同じグループに入れています。暗号化コードをカーネルに配置すると、カーネルコードのエクスポートがさらに困難になります。

7
dan_waterworth

TCP=オペレーティングシステムに組み込むことには明らかな利点があります。TCPには、アプリケーションデータが含まれていない場合でも、正確なタイミングとネットワークパケットへの迅速な応答が必要です。 TCPを汎用IP APIの上のユーザー空間に実装しようとした場合、それははるかに悪いことになります。SSLをカーネルに統合することと同様の利点はありません。

一方、いくつかの欠点があります。たとえば、SSLでは、キーリングや証明書のリストなどを操作する必要があります。カーネルまたはOS APIを介してそれを行うことは、洗練されていません。したがって、オペレーティングシステムに付属していたとしても、それは単なるライブラリ(Windowsの場合と同様)になります。とにかく、これらのライブラリはすでに利用可能であるため、最終的にはパッケージの変更にすぎません。

2
David Schwartz

理由はいくつかありますが、おそらく最も説得力があるのは、暗号化が実際に取得することが非常に難しいということですright。それが正しく強力であることを確認するために主要なリソースを費やすことができない場合を除いて、自分で実装することは賢明ではありません。暗号化ソフトウェアを扱うほとんどの人は、これに没頭する時間、専門知識、または欲求を持っていません。 their開発者が作業のその部分を処理できるようにサードパーティのライブラリを信頼する一方で、アプリケーション開発者は作成したいものに戻ることができます。

OS開発者はそれほど違いはありません。時には、最も重要な関心事があります。たとえば、ビジネスモデルや弁護士がコードを閉じたままにすることを要求しているため、問題を解決するための選択肢があまりない場合。あなたがしなければならないこと、そしてあなたはあなた自身のものを転がさなければなりません。他の人はすでにマイクロソフトがこれをどのように行うかについて述べました。しかし一般的に言えば、サードパーティのライブラリを使用できるOS開発者は、アプリケーション開発者が行うのと同じ理由で、そのようにすることを好みます。

1
The Spooniest

私はWindows開発者なので他のOSについて話すことはできませんが、Windowsでは非常に長い間SSLが組み込まれていました。彼らはそれを SChannel と呼び、サポートされていますが、これは、人が理解しなければならないであろう、より不可解なAPIの1つです。

0
DXM

暗号とSSLのカーネルサポートがいくつかあります。これは、カーネルがハードウェアとより効率的にやり取りできるため、また、資格情報を任意のアプリケーションから保護するのに便利であるため、理にかなっています。良い例はkssl、SolarisのカーネルレベルのリバースSSLプロキシ、またはカーネル(VPNなどで使用)のさまざまな暗号ライブラリです。典型的なハードウェアアクセラレーション暗号化エンジンには、カーネルモジュールもあります(PKCS#11またはOS固有の暗号化インターフェースを介してアクセスできます)。

頻繁に表示されないいくつかの理由は、一部のアプリケーションプロトコルが適切に階層化されていない(STARTLSと考える)か、ハンドシェイク(クライアント証明書とCRLチェックを考える)中にアプリケーションの決定を必要とするか、単に定期的に進化しているためです。

0
eckes

SSLは、下位レベルのプロトコルの上層です。たとえば、SSLはTCP(IPの上にあります)の上に実行されます)。

OSはどこで停止しますか?

OSは、OSのクライアントが「処理」を行うところまで、ネットワーキングなどの基本的なサービスを提供していると主張するのは非常に簡単です。そして、それはあなたが望むものにすることができます。

カーネルのSSLが大幅なパフォーマンスの向上につながることはほとんどありません。

最新のOSカーネルは数百万行のコードで実行され、さらに追加すると複雑さが増し、デバッグ時間が長くなります。上位層プロトコルのようなものをOSから除外すると、OSの開発が容易になり、最終的にはエンドアプリケーションの機能やパフォーマンスにほとんど違いがなくなります。 (それにより、開発者は最終アプリケーションの仕事をもう少し苦痛にするかもしれません。)

0
quickly_now