ECDHE_RSAおよびgmail
Ubuntu LinuxでChromeを使用してGmailに接続しています。接続情報によれば、ECDHE_RSAはhttps対称鍵交換に使用されます。
[〜＃〜] tls [〜＃〜] とGmailに関する私の理解に基づいて、クライアントは対称鍵を作成し、証明書にリストされているGoogleの公開鍵で暗号化してから、Googleに送信します。私のブラウザーはGoogleの証明書を認識するので、私の接続は安全であり、中間の攻撃者によって危険にさらされることはないと想定しても安全ですか？メッセージを復号化するためのGoogleの秘密鍵がないので、真ん中の男が対称鍵をどのように見ることができるでしょうか？
ブラウザーに証明書をインポートしていません。 Wiresharkを使用してTLSネゴシエーションをスヌープしました。私の「client hello」パケットには、クライアントがサポートする暗号スイートに関する情報、乱数、楕円曲線情報が含まれています。 Gmailサーバーが「server hello」と「certificate、server key exchange、server hello done」で応答した後、クライアントは「クライアントキー交換、暗号仕様の変更、暗号化されたハンドシェイクメッセージ」を送信します。 Googleの公開鍵で暗号化された対称鍵が「暗号化ハンドシェイクメッセージ」（TLSv1.1レコードレイヤー：ハンドシェイクプロトコル：暗号化ハンドシェイクメッセージ）の下のこのパケットにあると想定することは正しいですか？.
クライアントが上記で生成した対称キーを介して別のネットワーク上の将来のTCP接続でクライアントがフィンガープリント（つまり、一意に識別）できる方法はありますか？
ECDHE_RSAを使用すると、実際の鍵交換では Elliptic Curve Diffie-Hellman ;が使用されます。サーバーのECDH公開鍵は証明書には含まれていませんが、ServerKeyExchangeメッセージに含まれています。このメッセージには、サーバーが秘密鍵を使用して署名し、ブラウザがサーバー証明書に含まれている公開鍵に対する相対的な署名）。 ECDHの結果である対称鍵は、クライアントだけでは「選択」されませんが、クライアントとサーバーで共有される鍵であり、それ以外のものはありません。それはあなたの説明より直接的ではありませんが、あなたの考えは正しいです。実際、実装が正しく、ブラウザがサーバー証明書を適切に検証している限り、交換されたデータは盗聴者、なりすまし、悪意のある変更から安全です。
クライアントが同じサーバーに再接続しようとする場合（これはWebコンテキストでは正常です。サーバーが15秒間非アクティブになると接続をドロップする傾向があるためです）、非対称全体を回避するために、ECDHから対称キーを再利用しようとします。暗号化ビジネス、さらに重要なことに、1つのネットワークラウンドトリップを回避します。これは SSL/TLS の省略ハンドシェイクです。クライアントとサーバーの両方が以前の接続（「SSLセッション」と呼ばれる）をまだ記憶している場合、これは機能します。 これらの条件の下では、サーバーはクライアントを「以前と同じ」として認識する可能性があります。
ただし、SSLセッションパラメータ（ネゴシエートされた対称キー）は永続的なストレージ領域に保存されず、忘れがちです。ブラウザを閉じると、そのようなセッションはすべて忘れられます。 Apacheサーバーは、デフォルトで 5分 のSSLセッションパラメータを記憶します。多くの接続を処理する場合は、それより少ない可能性があります（そのようなパラメータのストレージスペースは構成可能ですが、サイズが有限であるため）。
SSLプロトコルの詳細なウォークスルーについては、 この回答 を参照してください。