node.js HTTPS要求のすべてのSSLプロトコルを許可する

Question

node.js （クライアント）は、リモートサーバーとの（可能であれば）あらゆる可能なプロトコルをネゴシエートできますか？私はセキュリティ上のリスクを理解していますが、私のプロジェクトではいくつかのウェブサイトはより古い/安全でないSSLプロトコル&暗号でのみ動作します。

例：curlまたは最新のnode.jsでhttps://www.dot.ny.govが機能しません（タイムアウト）。Ubuntu Server 16.04のデフォルト構成。 --tlsv1.0または--sslv3オプションを使用してcurlでのみ動作します。

プロトコルの範囲（最も安全性の高いものから最も安全性の低いもの）を使用してnode.jsのSSL接続を再ネゴシエートさせる方法があります。できるだけ広い設定（node.jsまたは基礎となるOpenSSL経由）すべてのSSLプロトコル&暗号？

Answer 1

HTTP（S）要求を行うための最も一般的なNPMパッケージの1つはrequestです。 その文書によれば、受け入れるSSLプロトコルを指定することができます。

訪問する予定のサイトと使用するプロトコルを事前に知っていれば、リクエストごとに設定できます。そうでなければ、複数のリクエストを作成するオーバーヘッドが煩雑になりますが、いくつかの条件文を書くことができると思います。

Answer 2

これらのプロトコルを許可するだけで、サイトで説明している問題は解決されません。 TLSは設計上、主に後方互換性があります。つまり、SSL 3.0またはTLS 1.0のみを実行できる適切に実装されたサーバは、TLS 1.2をサポートするクライアントからClientHelloに直面した場合にサポートされる最良のプロトコルで返信します。これは、クライアントができる最高のバージョンをアナウンスするだけで、サーバーがクライアントが提供するバージョンと同等またはそれ以下のサポートする最善のバージョンを選択するためです。そのときだけ「許可」が行われます。つまり、クライアントが下位バージョンのサーバーから返信を受け入れるかどうかが判断されます。

これはあなたが表示しているサイトでは問題ありません。この場合、サーバまたはその前のミドルボックスには、予期せぬClientHelloを突っ込んだバグのあるSSL/TLSスタックがあります。これらは予期せぬTLSバージョン、予期しない拡張子、予想外の暗号、大きすぎるか大きすぎるか類似した特質を持つClientHelloかもしれません。

この特定のケースでは、TLSプロトコルのバージョンはまったく問題ではないようですが、クライアントの前にthis bugという古いロードバランサがあるため、ClientHelloのサイズが問題になっているようです。ブラウザーは少数の暗号しか提供しない傾向があるので、ClientHelloはこの問題の影響を受けないのに十分な時間です。たとえば、openssl s_client -connect www.dot.ny.gov:443 -cipher 'AES128-SHA'のように暗号化された暗号を試そうとすると、TLS 1.2 ClientHelloでも成功しますが、大きなもの（-cipher 'AES'など）を試すと応答が返ってくることなくハングするだけです。おそらく、破損したロードバランサが大規模なClientHelloで。また、コマンドラインにTLS 1.0を適用するだけで、新しいTLS 1.2暗号も提供されていないことが確認されました。このTLS 1.2暗号も、ClientHelloのサイズを縮小しました。

「許可」の部分はサーバが応答した後に来る（この場合はそうでない）ため、実際にはさらに問題を引き起こす可能性があるため、このような壊れたサーバに対処する一般的な方法はありません。 （あまりにも多くの暗号を提供するように、ClientHelloのサイズを増やすなど）。代わりに、問題をデバッグし、壊れたサーバが何を好み、何が嫌いであるかを見つけてから、サーバが好きなように特定のTLSハンドシェイク（バージョン、暗号、拡張、サイズなど...）を設計しなければなりません。そして、特定のサーバーが受け入れることを知る良い方法は、analysis by SSLLabsを見ることです。