これは、ブラウザ(私が調べて理解したもの)とクライアントの間でSSL通信がどのように行われるかではなく、他の側面であることに注意してください。
使用 DigicertのSSLメカニズムの説明 ブラウザとサーバーの間でデータがどのように暗号化されるかを理解しました。以下は私の理解です。
質問:
上記の私の理解に基づいて:
上記の回答に基づいて、私は最も重要な質問をします-私が私のサーバーのSSLトラフィックを監視できるように誰かに私のサーバーの秘密キーを提供し、それから私が必要とする他のすべてのものに彼の秘密キーを提供することを除いて気を付けて。また、サーバーで使用しているアルゴリズムまたは暗号を彼に伝える必要がありますか?
- ブラウザはセッションキーを生成し、サーバーの公開キーを使用してそれを暗号化します。しかし、ブラウザで使用される暗号化アルゴリズム(または一般に暗号アルゴリズムと呼ばれる)はどれですか?
- 暗号の選択はどのように決定されますか?ブラウザとサーバーの両方が暗号化と復号化に同じ暗号/キーサイズを使用しますか?
ブラウザは、サポートするサーバーに暗号スイートのリストを送信します。 この回答で説明します 暗号スイートの詳細は何ですか。ただし、基本的に暗号スイートは、安全な通信に使用するアルゴリズムのリストです。暗号スイートには以下が含まれます:
例えば: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ブラウザはサポートされている暗号スイートのリストをサーバーに送信し、サーバーはサポートする最も安全な暗号スイートを選択します。リストのどれもサポートしていない場合、接続は失敗します。対称暗号化アルゴリズムは、セッションキーの使用目的です。 SSL/TLSでは、キーは プレマスターシークレット から生成されます。
- SSLハンドシェイクが完了すると、すべての通信は対称セッションキーを使用して暗号化されますが、ブラウザではどの暗号化アルゴリズムが使用されますか?
この場合も、暗号スイートの対称アルゴリズムが暗号化通信に使用されます。上記の例では、GCMモードの128ビットAESになります。
- ブラウザーで使用される暗号化アルゴリズムは、サーバーから受信した証明書に依存していますか?
- または、ブラウザで実行されるすべての暗号化は同じ暗号アルゴリズムで実行されますか?
証明書にはまったく依存しません。すべての暗号化は、サーバーが選択した暗号スイートの対称暗号化アルゴリズムによって実行されます。
- 間違っている場合は修正してください。アルゴリズムまたは暗号情報も証明書に含まれていますか?その情報はどのように証明書に保存されますか?
- 証明書を生成するときに、どのアルゴリズム、何ビットの暗号化、パディングなどを記述する必要がありますか?
安全な通信のアルゴリズムと暗号は証明書には含まれていませんが、前述のとおり、サーバーによって選択された暗号スイート内にあります。証明書には、証明書自体に関する情報のみが含まれます。これには、有効性情報、署名アルゴリズム、発行者情報などが含まれますが、これらに限定されません。
上記の回答に基づいて、私は最も重要な質問をします-私が私のサーバーのSSLトラフィックを監視できるように誰かに私のサーバーの秘密キーを提供し、それから私が必要とする他のすべてのものに秘密キーを提供することを除いて、気を付けて。また、サーバーで使用しているアルゴリズムまたは暗号を彼に伝える必要がありますか?
(この質問の範囲外の理由で)SSLトラフィックの監視用にサーバーの秘密鍵を提供することはしないことを強くお勧めします。ただし、秘密鍵を共有することにした場合、相手は他の情報を必要としません。アルゴリズムと暗号は証明書に含まれていないため。
非常に短い回答:サーバーとクライアントは、サポートするアルゴリズムとその後使用するアルゴリズムについて交渉します。ハンドシェイク中に通信されます。
回答ではありませんが(@razはそれを理解しました)、コメント「IMO」に対して大きすぎる「理解」のエラーがいくつかあります。
ブラウザはリソースを取得するリクエストをサーバーに送信します。サーバーは、要求のプロトコルがHTTPSであるかどうかをチェックし、HTTPSである場合は、証明書を送信します(この証明書は、CA(Digicertのような認証局)によってすでに署名されています)。
SSL/TLSハンドシェイクは、ブラウザがリクエストを送信する前に発生するため、リクエスト(URLを含む)は暗号化されます。 SSLがURLを暗号化する場合、httpsメッセージはどのようにルーティングされるのですか? および SSL/TLS(https)はアクセスされているURLを非表示にします を参照してください
ブラウザは最初にスキームをチェックし、(通常)httpの80ではなく、httpsのポート443に接続します。 1つのIPアドレスで複数の「仮想ホスト」をサポートする最新のサーバーの場合、ブラウザーはサーバー名表示(SNI)と呼ばれる拡張機能でURLのHost partを送信でき、通常は送信します。これにより、サーバーは目的のホストの正しい証明書。
ブラウザーは、有効なCAプールで署名機関の検索を検証することにより、証明書が有効かどうかを確認します。
Digicertのページに正しく記載されているように、ブラウザーは証明書がローカルストアのCAによって署名されており、期限が切れておらず、取り消されておらず、[正しいホストの場合]。 1つの面でページが古くなっています。現在、DigicertなどのパブリックCAからの事実上すべての証明書は、SubjectフィールドのCommonName要素ではなく、より柔軟なSubjectAlternativeName拡張(多くの場合はSANと呼ばれます)を使用してホスト名を指定しています。効果は基本的に同じです。
[ブラウザーに問題がない場合]は、セッションキーを生成し、証明書に存在する公開キーを使用して暗号化します。
ブラウザはこの暗号化されたセッションキーをサーバーに送信し、サーバーはセッションキーを復号化します。 [...]
これは単純化しすぎて時代遅れになっています。元の「RSA」鍵交換方式はRSA暗号化を使用しますが、クライアントによって選択および暗号化される値は「the」セッション鍵ではなく、multipleセッション鍵に寄与するプリマスターシークレットです。 https://crypto.stackexchange.com/questions/1139/what-is-the-purpose-of-four-different-secrets-shared-by-client-and-server-in-ssl 。
また、今日では、(-のいくつかの変形) Diffie-Hellman を使用することがより一般的になり、@ Neilによってコメントされた前方機密を提供できます。 SSL/TLSの仕組みは? を参照してください。 @raz回答の暗号スイートTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256の例では、RSAによって認証された一時楕円曲線ディフィーヘルマン(ECDHE)鍵交換を使用しています。これは、RSAを使用してプリマスターを暗号化および復号化しません。代わりに、クライアントとサーバーが楕円曲線のサブグループでランダムな要素の次数を個別に選択し、それらを数学的に組み合わせてプリマスターを作成します。