OpenSSLは安全ですか？
非同期I/Oの利点のため、Node.JS Webサーバーを配布する予定です。 Node.JS httpsサーバーはOpenSSLライブラリを使用します。
OpenSSLには定期的に脆弱性が解決されています のようです。これは、SSLレイヤーを別のJavaプロセス/バッファオーバーフローやその他の脆弱性のない、より証明されたプロセスに移動する必要があるかどうか疑問に思います。
Oracle Solarisパッケージレポ は 古いリリース のみを公開するため、プロンプトインストールにはソースからのコンパイルが必要です。
もちろん、検出->リリース->コンパイル->実行中のサーバーへの配布の間に遅延があります。ビルドに問題がある場合の追加の管理コスト/遅延。
- プロンプトの更新は攻撃者に対してどの程度効果的ですか？脆弱性が特定されたら、攻撃者はどのような作業が必要ですか？
- Httpsレイヤーをインストールするための代替の、より安全なアプローチをお勧めしますか？
- まだ維持されており、安全であると証明されるまでの時間が長い、古い、より安定したバージョンのOpenSSLはありますか？
この質問を正しくするための助けを含め、どんな入力もいただければ幸いです。
編集：別のライブラリがどのように導入されるかについてのいくつかの説明（もしそれが起こった場合）：個別のライブラリは、別のプロセスでのプロキシhttpsサーバーの実装にすぎません。これはまったく新しい実装なので、切り替えを行わず、代わりにNode.JS httpsサーバーライブラリを「使用しない」だけにします。
彼らがセキュリティを改善するために常に変更を加えているという事実は良いことです。それは彼らがエクスプロイトとそれに対応するパッチに追いついていることを意味します。これは、セキュリティライブラリに表示したいものです。ライブラリが頻繁にパッチされていないからといって、ライブラリに問題がないわけではありません。それは、彼らがそれらを迅速にまたは頻繁に修正していないことを意味するだけかもしれません。
ライブラリ自体はかなり広く使われているようですので、最新版を使っても大丈夫でしょう。異なるライブラリを使用すると、ビルドとアップグレードのプロセスに多くの複雑な問題が発生するように見え（それ自体がセキュリティの問題を引き起こす可能性があります）、おそらく切り替えても多くのセキュリティは得られません。
別のオプションは、SSL計算を Pound のようなリバースプロキシにオフロードすることです。私は過去にPoundを使用したことがあり、非常に使いやすいことがわかりました。私はこれを従来のWebサイトでのみ使用したので、それがあなたのために機能するかどうかはわかりません。
Poundの良い点は、複数のバックエンドを構成することで大まかに負荷を分散できることです。
バッファオーバーフローのないSSL実装を実装することは概念的には実現可能です。バッファオーバーフローを強制的に防止するプログラミング言語を使用することで十分です。たとえば、完全にJavaでのSSL実装。 Java仮想マシンは、配列アクセスを実行する前に配列の境界を体系的にチェックします。したがって、実際にバッファがオーバーフローすることはありません。代わりに、例外がスローされ、問題のスレッドが中断されます。正味の効果は、バッファがオーバーフローするバグの場合、攻撃者はリモートシェルを取得しません（サーバースレッドは引き続きクラッシュします）。
純粋なJava bouncycastle と呼ばれる暗号化ライブラリが存在します。他のStackexchangeの回答は、おそらく便利な TLS接続で1つ を含めて、それを参照しています。
Googleは this も検出しましたが、残念ながら、証明書の処理を外部ライブラリに依存している古い、停止したプロジェクトのようで、これらの外部ライブラリはではありません純粋なJava;そしてOpenSSLのバグはとにかくその部分にある傾向があります。