まず何を守る技術か
Diffie-Hellman暗号化（鍵交換）は、通信相手と一緒に使う“共有鍵”を、事前にその鍵を安全に受け渡しできない状態でも作り出すための考え方です。ここで重要なのは、Diffie-Hellmanが主に担うのが「暗号文を作る処理」そのものではなく、「暗号化に使う鍵を両者で合意する」ことだという点です。共有鍵が成立すると、その後の通信を暗号化して内容の盗み見を困難にします。
超かんたんな仕組み（理解のためのモデル）
難しい数式を置いて、仕組みをモデル化すると次のようになります。
- 各当事者が、ランダムな値を元に計算した“公開情報”を互いに送ります。
- 相手から受け取った公開情報を使い、それぞれが“共有鍵”を計算します。
- 傍受者が通信を見ても、共有鍵そのものを直接再現できないように計算が設計されています。
つまり、公開してよい情報をやり取りしつつ、最終的に必要な秘密（共有鍵）だけが両者の手元で一致する、という構図です。
何ができて、何ができないか（制限と例外）
Diffie-Hellmanの強みは、「通信を盗み見されても、共有鍵が直ちに漏れないようにする」ことです。ただし安全性はそれだけで決まりません。
- なりすまし（相手の正当性の欠如）：相手が本物だと確認する仕組みが弱いと、共有鍵が成立しても中間者に誘導される恐れがあります。このため、実際の通信では鍵交換に加えて“認証”が別レイヤーで必要になります。
- 鍵の作り方・パラメータの選択：Diffie-Hellmanは、方式やパラメータ、実装の質によって強さが変わり得ます。安易な選択や古い設定は安全性に影響します。
- 鍵交換の後段の暗号方式：共有鍵が作れても、後段で使う暗号方式や運用（例：設定が弱い）が不十分だと、守りが弱くなります。
ここが“万能ではない”点で、オンラインの行動を守るには、鍵交換＋認証＋暗号の組み合わせとして考える必要があります。
関連概念：前方秘匿性と認証
Diffie-Hellmanと一緒に理解されやすい概念に、前方秘匿性（フォワード・シークレシー）があります。これは、仮に後から何らかの理由で過去の通信に関する秘密情報が問題になったとしても、過去の通信内容がその影響で簡単に読めないようにする考え方です。
また、前述の通り、なりすまし対策には“認証”が欠かせません。実運用では、サーバー（または相手）が本物であることを示す仕組み（証明書など）を通じて、「どの公開情報が誰のものか」を結び付けます。つまり、Diffie-Hellmanは合意の中核ですが、「本物かどうか」を保証するのは認証側です。
実践的な確認方法（自分で点検できるポイント）
「Diffie-Hellmanが使われているから安全」と決め打ちせず、次の点を確認すると理解が現実に近づきます。
- 接続先が正しいか（名の一致）：証明書の対象名が、アクセスしているホスト名と一致しているかを確認します。