【入門編】 HTTPS(TLS)ハンドシェイクとTCP接続の順序 – ネットワーク基礎とWebセキュリティ実践ガイド

HTTPSの裏側を覗く：TCPの「握手」からTLSの「合鍵交換」まで、パケットの旅路を追う

こんにちは！ネットワークの世界へようこそ。

ブラウザのURL欄にある鍵マーク。普段何気なく見ていますが、実はあの小さなマークが表示されるまでの数ミリ秒の間、サーバーとクライアントの間では、まるでスパイ映画のような緻密で高度な「会話」が繰り広げられているんです。

今日は、ネットワークの基礎にして最重要項目である「HTTPS接続の裏側」を、郵便配達や秘密の合言葉に例えて紐解いていきましょう。難しい用語は一旦置いておいて、まずは全体像から掴んでいきますよ！

—

通信を始める前には、まず「荷物を届けるための道」を確保しなければなりません。これが TCP の役割です。

例えるなら、電話をかける時の動作そのものですね。
1. クライアント（あなた）：「もしもし？（SYN）」
2. サーバー（相手）：「はい、聞こえますよ。そちらも聞こえますか？（SYN-ACK）」
3. クライアント（あなた）：「ええ、聞こえています！（ACK）」

この3つのやり取りを TCP 3-way Handshake と呼びます。これが終わって初めて、「よし、今から安全に荷物を送れるね！」という状態になります。

—

TCPの道が開通しただけでは、まだ中身は丸見えのままです。そこで登場するのが TLS（HTTPSの心臓部）です。ここで、お互いが納得する「暗号化のルール」を決めます。

ブラウザ（クライアント）が「私はこんな暗号方式が使えます！今の流行りはどれですか？」とリストを提示します。

サーバーが「それなら、この方式でいきましょう」とルールを決定します。さらに、サーバーはここで「身分証明書（デジタル証明書）」を提示して、「私は間違いなく本物のサイトですよ」と証明します。

ここが面白いところです。物理的に鍵を渡すのではなく、数学のパズルを使って、「お互いにしか解けない秘密の共有鍵」をその場で作り出します。

このやり取りが終わると、いよいよ本番の通信が暗号化されてスタートします。

—

ここまで読んでお気づきの方もいるかもしれません。実は、データを送る前に「TCPで3往復」「TLSで数往復」という準備運動が必要です。

これを「レイテンシ（遅延）」と呼びます。距離が遠いサーバーと通信する場合、この往復回数分だけ待ち時間が増えるため、Webページを開くのが遅くなってしまうのです。

この遅延を減らすために、最近の通信規格である TLS 1.3 では、握手の回数が半分に減らされています。また、TCP Fast Open という技術を使えば、最初の「もしもし」の段階でデータを一緒に送ってしまうという荒技も可能です。

エンジニアとして設定を確認する際は、以下のように OpenSSL コマンドでサーバーの対応状況をチェックするのが定石です。

# サーバーがどのTLSバージョンをサポートしているか確認するコマンド
# -connect で対象サーバーを指定します
openssl s_client -connect example.com:443 -tls1_3

—

実務では、ブラウザでサイトが開かない時、どこで止まっているのかを切り分ける能力が重要になります。

例えば、NginxなどでSSL設定を行う際、古い暗号方式を無効化するのはセキュリティの鉄則です。

# Nginxの設定例：安全なプロトコルのみを許可する
ssl_protocols TLSv1.2 TLSv1.3;  # 古い TLSv1.0/1.1 は無効化します
ssl_prefer_server_ciphers on;    # サーバー側の暗号優先順位を尊重する

—

今回お伝えしたかったのは、「HTTPS通信は、いきなりデータが飛ぶのではなく、丁寧な挨拶と鍵の交換の儀式がある」ということです。

1. TCP Handshake：まずは電話回線を確保する。
2. TLS Handshake：合言葉と鍵を決め、身分を証明する。
3. HTTP通信：鍵がかかった箱の中で、安全にデータを届ける。

ネットワークの世界は広大ですが、このように「郵便や電話」に例えて考えると、グッと身近に感じられるはずです。トラブルシューティングに直面した時も、「今、パケットはどの段階で足踏みしているのかな？」と想像力を働かせてみてください。

次回は、この「鍵」がどうやって作られているのか、もう少しだけ深い「暗号化の仕組み」についてお話しできればと思います。

それでは、また次の記事でお会いしましょう！Happy Hacking!