ブラウザーはどのようにSSL / TLS接続パラメーターをネゴシエートしますか？
この質問では、SSL/TLS接続に4つのパラメータがあると仮定します。
protocol、symmetric encryption method、asymmetric encryption method、MAC。
SSLパラメータのネゴシエーション中に、ブラウザは 最良のパラメータ を達成しようとします。だから、私の質問は：
- 前のリストの正しい順序は何ですか？私はそれらすべてが重要であることを知っています（必要です）。しかし、私はコードでそれらのうちの1つが最初のものとして選択されていると仮定し、次に2番目、3番目、4番目があります。 DESでTLSv1.2を選択することは、AES256でSSLv3を使用するよりも安全であると思います。したがって、問題は、ブラウザにどのように実装されるかです。
- ブラウザはこの情報をどこに保存し、ユーザーが変更できるかどうかを示します。
おそらくブラウザに依存する回答がいくつかあることは知っていますが、SSL/TLSプロトコルによって適用されるいくつかの一般的なルールがあるかもしれません。
@ ThomasPorninの回答 は最初の質問に対応します。次に、2番目の質問は、「ブラウザでプロトコルと暗号スイートをどのように構成するか」です。
Firefox
プロトコルは about：config変数security.tls.version.minおよびsecurity.tls.version.max を変更することによって構成されます。最小値と最大値を次のように設定できます。
- 0：SSL 3.0は、最低限必要な/サポートされている最大の暗号化プロトコルです。
- 1：TLS 1.0は、最小必須/最大サポートの暗号化プロトコルです。
- 2：TLS 1.1は、必要な最小/サポートされる最大の暗号化プロトコルです。
- 3：TLS 1.2は、必要な最小/サポートされる最大の暗号化プロトコルです。
Firefoxが提供する暗号スイートのリストは、about：config変数security.ssl3。（cipher suite）によって制御されます。このインターフェースで順序を制御することはできませんが、私はそれについて心配しません。クライアントでの順序は " preference "のみであり、暗号の選択を支配するのはサーバーの順序です。名前に「ssl3」を使用しても、ssl3にのみ影響するという意味ではありません。これは、すべてのSSL3またはTLS *バージョンで提供できる暗号スイートに影響します。
単純に暗号名のあるキーを追加することはできません。暗号はソフトウェアでサポートされている必要があり、Firefoxの新しいバージョンは、古くて安全でないスイートが廃止され、新しいスイートが追加されるにつれて、暗号スイートの改善されたライブラリをサポートします。
新しいカスタム暗号スイートを追加するために必要なライブラリをコンパイルするのはpossibleであると読みましたが、現在その参照を見つけることができず、一般的なルールとしてはお勧めしません。
Chrome
プロトコル は--ssl-version-minコマンドラインスイッチを使用して設定されます。たとえば、SSLv3を無効にするには：
--ssl-version-min=tls1
-cipher-suite-blacklistコマンドラインスイッチ を使用して、暗号スイートのリストをデフォルトから減らすことができます IANA TLS Cipher Suite Registry の値を参照します。
--cipher-suite-blacklist=0x0005,0x0004
優れた議論 here は、さまざまなブラウザーがどのように暗号スイートにアクセスできるようにするか、より具体的には、それらを簡単にまたは可能にするために邪魔にならないようにする方法に触れています。
SSLでは、鍵交換、対称暗号化、およびMACアルゴリズムはすべて、暗号スイートと呼ばれる単一の集約概念にグループ化されます。
最初のハンドシェイクでは、クライアントは次のものを送信します。
- サポートする最高のプロトコルバージョン。
- サポートする暗号スイートのリスト（優先順）。
- ここでは関係のない他のこと。
次に、サーバーはプロトコルバージョンと使用する暗号スイートを選択します。理論は、礼儀正しいサーバーがクライアントとサーバーの両方がサポートする最も高いプロトコルバージョンを選択し、サーバーもサポートするクライアントリストの最初の暗号スイートを選択することでクライアントの設定を尊重するというものです。既存のサーバーはすべて礼儀正しくはありません。
プロトコルバージョンは暗号スイートから完全に独立しているわけではないことに注意してください。一部の暗号スイートは一部のプロトコルバージョンでのみ機能します（たとえば、AES/GCMを暗号化+ MACとして使用した暗号スイートはTLS 1.2でのみ機能します）。
いずれの場合も、鍵交換、対称暗号化、およびMACの独立した選択はありません。プロトコルは、その点で直交ではありません。すべての組み合わせが意味をなすわけではありません。そして、意味のあるすべての組み合わせが実際に定義されているわけではありません。つまり、 割り当てられた暗号スイート識別子 があります。
このプロセスの詳細については、まず この答え を読んでください。
ブラウザは、サポートする暗号スイートとそれらを送信する順序に関して、多かれ少なかれ構成可能です。通常、暗号スイートをアクティブまたは非アクティブにすることができます（例： this を参照）。ただし、順序はブラウザのロジック（バージョンによって異なる場合があります）の制御下にあります。いずれの場合も、クライアントではなくserverが最終的に選択します（もちろん、クライアントは常に、その単一の暗号スイートに制限されたリストを送信することにより、特定の暗号スイートの使用を強制できます。 ）。
「優先順位」の概念はほとんど意味がないと主張できます。実際には、クライアントは使用する暗号スイートのリストを送信します。したがって、それらのいずれも使用できます。暗号スイートが「弱い」場合、クライアントは、サーバーがその暗号スイートを選択しないように、それをプリファレンスのリストに十分に入れるべきではありません。代わりに、クライアントはそれをまったく含めるべきではありません。弱点が弱い。