Web通信のセキュリティ強化！
HTTPSの仕組み Part1 ～基礎解説編～
2025年3月3日
はじめに ※今回Flowmonの解説は出てきません！
HTTPはWeb上でデータを通信するために利用されているプロトコルであり、インターネットの閲覧には不可欠となっています。しかしながらHTTPは通信が暗号化されないことや認証機能を備えていないことから、安全性の高いプロトコルとは言えません。このセキュリティ面の課題を解決するために生み出されたのがHTTPSです。HTTPSは厳密にはプロトコルではなく、SSL/TLSという暗号化プロトコルを組み込むことで安全性を確保した、”セキュアなHTTP通信”のことを指します。近年では重要なデータをやり取りするログインページ等のほかにも、Webサイト内のすべてのページをSSL化する常時SSL化の動きが広まっています。HTTPSの使用率は日本では95%（2025/2/8時点、※1）にも上り、セキュアな通信が当たり前の時代になっているといえます。
通信の高い安全性が求められる一方で、ネットワーク管理者の立場からは「インターネットへ向けたLAN内の通信を可視化したい」というような相反するニーズも存在します。そこで本コラムでは今月と来月の二回にわたり、HTTPSの秘匿された通信がトラフィック可視化ツールFlowmon上でどのように視えるのかを解説いたします。まずパート1となる今月はHTTPSの基礎解説編として、どのような仕組みで暗号化通信が行われているのかの解説を行います。（ですので今回Flowmonの解説は出てきません！）Flowmonを用いたHTTPS通信可視化については、来月公開予定のパート2実機検証編にて詳しくご紹介いたします。
HTTPS通信の流れ
次の図は、HTTPとHTTPSそれぞれの通信シーケンスの概略図です。
基本的な流れとしては、クライアント-Webサーバ間のTCP接続が確立した後、HTTP通信でクライアントからのリクエストとサーバからのレスポンスがやり取りされます。HTTPSの場合では間にSSL/TLSハンドシェイクと呼ばれるネゴシエーションが入り、ここで暗号化に必要な情報が交換されます。バージョンによって暗号化される範囲が異なり、TLS 1.2以前ではHTTPS通信部分のみ、TLS 1.3以降ではSSL/TLSハンドシェイクの途中からが暗号文を用いた通信となります。SSL/TLSハンドシェイクでは認証/暗号化アルゴリズムの合意に加え、暗号化を行うカギの交換や接続先の認証も行われます。これらについて、以降の章で詳しくご説明していきます。
共通鍵と公開鍵/秘密鍵
暗号化に用いるカギによって共通鍵暗号方式と公開鍵暗号方式という2種類の暗号方式が存在し、HTTPSではこれらを組み合わせたハイブリット方式が用いられています。
共通鍵方式は暗号化と復号を共通のカギで行うもので、公開鍵方式と比べて処理速度が速いというメリットがあります。しかし、送信者（暗号化する側）と受信者（復号する側）以外の第三者にカギが渡ってはいけないため、通信相手が増えるほど必要なカギの種類も増え、管理が複雑になります。加えて、カギの受け渡しの際も漏洩を防ぐよう十分に注意する必要があります。
それに対して公開鍵暗号では2つのカギのペアを使い、暗号化/復号をそれぞれ別のカギで行います。一方のカギで暗号化されたものはもう一方でしか復号できず、その逆も同様です。公開鍵方式では、このペアのうち片方をだれでも取得できる公開鍵とし、もう片方は秘密鍵として生成者のみが保有します。こうすることで、暗号化は公開鍵を利用して誰でも行えますが、復号は秘密鍵の所有者（受信者）にしかできない仕組みになっています。この方式の特徴として、公開鍵では復号ができないため盗聴されても問題なく、共通鍵方式のデメリットであった暗号鍵受け渡し時のリスクが解消されます。さらに、複数の送信者で暗号鍵の共用が可能となり、通信相手が増えても複数のカギを用意する必要がなくなります。しかし、暗号化と復号を別々のカギで行うことで処理速度が低下するというデメリットもあります。
HTTPSでは公開鍵方式と共通鍵方式を組み合わせて暗号化通信を行います。次の図ではTLS 1.2以前のカギ交換の概略を説明します。
- まずクライアントからの接続要求があると
- Webサーバは応答として公開鍵を送付します。
- 次にクライアントは暗号化通信に利用する共通鍵を生成し、
- 受け取った公開鍵を用いてこれを暗号化します。
- その後、暗号化した共通鍵をクライアントからサーバに送付します。
- サーバは受け取った共通鍵を自らが保有する秘密鍵で復号することで暗号鍵の受け渡しが完了し、
- 暗号化通信（HTTPS通信）が開始されます。
暗号化通信には共通鍵暗号方式を利用することで処理速度を向上し、共通鍵の受け渡しに公開鍵暗号を使うことで機密性が確保される仕組みとなっています。ちなみに、公開鍵暗号にはいくつか種類があり、ここで共通鍵の受け渡しに利用されているのはRSA暗号を用いたものとなっています。TLS 1.3以降ではDH（Diffie-Hellman）鍵交換という公開鍵方式の技術を用いることで、共通鍵を送付するのではなく、サーバとクライアントの双方が個別に同一の共通鍵を生成することが可能となっています。ただし、DHには認証機能がないためサーバの認証を行うためにRSAも利用されています。
ここで認証機能という単語が出てきましたが、公開鍵暗号ではデジタル署名という技術で通信相手の認証を行うことができます。前述のように公開鍵と秘密鍵は暗号化/復号の役割を入れ替えることができるため、秘密鍵で暗号化した物を公開鍵で復号することができます。公開鍵は誰でも入手できるため機密性の観点からはあまり意味のない行為ですが、通信相手から提供された公開鍵で復号できるということは、その暗号化を行った秘密鍵と自らが入手した公開鍵が対になっていることの証明になります。したがって、暗号化を行った人物と公開鍵を送付した人物が同一であることが保証できます。このように秘密鍵で暗号化を行うことをデジタル署名と呼びます。
TLS 1.3以降で行われているDH鍵交換では、サーバとクライアントがお互いにDH公開鍵/秘密鍵のペアを用意し、それぞれのDH公開鍵を送付しあいます。これらのDH鍵交換を用いた共通鍵の生成に関しては今回割愛させていただきますが、この時のDH公開鍵の交換においてサーバ側はDH公開鍵をRSA秘密鍵で暗号化（署名）して送付します。これを受信したクライアントは、先に受け取っているRSA公開鍵でDH公開鍵（SV）が復号できるかどうかでサーバのなりすましがないかを確認できます。
サーバ証明書
SSL/TLSにおいて、WebサーバのRSA公開鍵はサーバ証明書というものに含まれた状態で送付されます。この証明書はWebサーバが正当な接続先であることの証明（実在証明）に用いられ、RSA公開鍵を安全に送付する手段にもなっています。デジタル署名を用いたDH鍵交換では、DH公開鍵を暗号化した人物とRSA公開鍵を送付した人物が同一であるかを確認できましたが、そもそもRSA公開鍵が改ざんされていた場合はなりすましに気づくことができません。サーバ証明書を用いることでRSA公開鍵が正当なWebサーバのものであることが保証されます。サーバ証明書は認証局（CA、Certificate Authorities）という「無条件で信頼される第三者」により発行され、これらの機関によってサーバの実在証明やRSA公開鍵の正当性の保証が行われます。
証明書を受け取ったクライアントは以下を確認することで正当性をチェックします。
- 自分が所有するルート証明書とサーバ証明書に含まれる発行局の情報の比較（証明書の発行者が信頼できるか）
- デジタル署名の確認（証明書の発行者がなりすまされていないか）
- ハッシュ値の検証（証明書自体が改ざんされていないか）
ルート証明書とはWebブラウザにあらかじめインストールされている「信頼できる認証局の情報」のことで、サーバ証明書に記載されている発行局の信頼性を確認します。
デジタル署名はWebサーバのなりすましだけでなく、認証局のなりすまし検知にも利用されます。前述のルート証明書には認証局が生成する公開鍵が含まれており、これを使ってサーバ証明書に含まれる認証局のデジタル署名が検証されます。
また、ハッシュ値とはデータの改ざん検知に使われる情報で、RSA公開鍵を含むサーバ証明書が改ざんされていないことを確認します。ハッシュ値を計算する関数をハッシュ関数といいますが、これは入力値をもとに「入力値を代表する値（ハッシュ値）」を出力します。より具体的な例では、入力値「FLOWMON」に対して「一文字おきに文字を取り出す」という操作を行うと出力値（ハッシュ値）は「FOMN」となります。改ざんの検知においては、やり取りするデータに対して送信側と受信側で互いにハッシュ値の計算を行う、即ち送信前と受信後のデータからハッシュ値をそれぞれ計算し、これらを比較します。ここで、データが通信途中で「FLOW”N”ON」と改ざんされていたとすると、受信側で出力されたハッシュ値は「FONN」となり改ざんされていることに気づくことができます。もちろんここで示した「一文字おきに文字を取り出す」という関数は実用的ではなく、「FLOWM”A”N」という改ざんに対しては同じハッシュ値「FOMN」が出力されてしまう（衝突）などの問題があります。実際に用いられるハッシュ関数ではより工夫が必要になります。
それでは、サーバ証明書が実際にどのように利用されているか、通信全体の流れをご説明いたします。
まずサーバ証明書の発行を行うフェーズでは、①Webサーバの運用者がサーバの情報とともにRSA公開鍵を認証局に提出して申請します。②認証局により承認されるとWebサーバのRSA公開鍵が入れられたサーバ証明書が発行されます。③証明書を受け取ったWebサーバ運用者はサーバ上に証明書を設置します。続いてクライアントとの通信を行うフェーズでは、⓪前提としてクライアントは認証局からルート証明書を入手しています。①クライアントの接続要求に対して、②サーバは証明書を送付します。これを受け取ったクライアントは③ルート証明書との照会と、ルート証明書から取り出した公開鍵（CA）を使って④デジタル署名の検証、及び⑤ハッシュ値の検証を行います。ここで証明書の正当性が確認できれば、証明書に含まれる公開鍵（SV）が正当なものであることがわかるため、図4や図5のカギ交換に移ることができます。
Flowmonにおける暗号化（HTTPS）通信の視え方
フロー生成機Flowmon Probeを利用することで、HTTPホスト名といったHTTP通信の情報を可視化することができますが、HTTPSの暗号化通信の場合はどうでしょうか。Flowmonでは、SSL/TLSハンドシェイクの拡張機能であるSNI（Server Name Indication）という情報からHTTPホスト名を取得しています。このSNIというのは、SSL/TLSハンドシェイクにおいてクライアント側が接続したいWebサイトを指定するための情報です。一般に、一つのWebサーバでは複数のWebサイトをホストしています。このような場合、同じIPアドレスに対して複数のサイトが、更にそれらのサーバ証明書もそれぞれ存在することになります。したがって、正しいサーバ証明書を送付するためにはHTTPホスト名をSSL/TLSハンドシェイクの時点で指定する必要があります。この役割を担うのがSNIとなります。クライアントからの接続要求を受け取ったサーバは、SNIを読むことでどのサイトの証明書を送付すべきなのかが分かります。このやり取りはSSL/TLSによる暗号化の前に行われるため、HTTPSの通信においてもFlowmonによってHTTPホスト名を取得することができます。
しかし、近年ではSNIのやり取りから暗号化を行うESNI（Encrypted SNI）と呼ばれるものも登場し、Flowmonでは現状これを可視化することはできません。このようなFlowmonを用いて可視化できる通信とできない通信について、来月公開予定のパート2で詳しく検証できればと思います。
おわりに
本コラムでは、HTTPS通信で用いられている共通鍵暗号、公開鍵暗号やサーバ証明書などの仕組みをご紹介しました。パート2のFlowmonにおけるHTTPS暗号化通信の可視化検証編の前知識にもなるかと思いますので、ご参考になれば幸いです。
◆Flowmonについて、より詳しく知りたい方は、下記の資料をぜひご覧ください。
細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。
- お見積依頼、お問い合わせはこちらからどうぞ
- 03-6205-6082
- 平日AM9:00～17:30（土日、祝祭日、年末年始、および弊社が定める定休日を除く）