2025.12.24

セキュアな通信を実現するTLS概説

中小企業の経営者や情報システム担当者の皆さん、日々のセキュリティ対策、お疲れ様です。

今回は、セキュアな通信を実現する代表的な技術として普及しているTLS（Transport Layer Security）の概要や仕組みについて解説します。

●SSLの概要と常時HTTPS化の進行

TLSについて解説する前に、その前身となったSSL（Secure Sockets Layer）について解説します。

SSLは、かつての米国Netscape Communications社（現在は他社に吸収合併）が開発した認証と暗号化を行うための方式であり、主にWebブラウザとWebサーバ間でデータを安全にやり取りするための業界標準プロトコルとして使用されていました。

その後SSLは、2000年頃から標準化が行われ、TLSに移行されましたが、”SSL”という名称が広く普及しているため、現在でも実際の技術はTLSであっても、”SSL”と呼ばれていることもあり、”SSL/TLS”と併記する場合もあります。

なお、TLSによって確立されるセキュアな通信経路上でHTTP（Hypertext Transfer Protocol）通信を行う仕組みが「HTTP over TLS」であり、URIスキーム「https」で表されます。
多くの場合、ブラウザでWebサイトにアクセスすると、URLの先頭が”https://・・”となっていると思いますが、このとき、「HTTP over TLS」によってセキュアな通信が確立しています。

近年Webサイト全体をHTTPS化すること（常時HTTPS化）が進んでおり、株式会社フィードテイラーの調査によれば、国内上場企業における常時SSL化（HTTPS化）は、2025年10月の時点で95%近くにまでなっているようです。

「常時SSL化調査レポート上場企業サイト対応状況」
(https://www.feedtailor.jp/report_aossl/)

●TLSの概要

TLSは、その名の通り、通信規約（プロトコル）の機能階層のうち、「トランスポート層」という層における暗号化プロトコルを中心とした技術で、SSLのバージョン3.0に基づいて標準化が行われました。

その主な機能としては、デジタル証明書（WebサイトやクライアントPC等の信頼性を証明するための電子的な身分証明書）によるサーバ、クライアント間の相互認証と通信データの暗号化を行います。
なお、一般的なWebサイトではクライアントの認証は省略しており、サーバの認証と通信データの暗号化を主に行っています。

また、TLSはWeb通信で用いるHTTPだけでなく、メール送信に用いるSMTP（Simple Mail Transfer Protocol）、ファイル転送に用いるFTP（File Transfer Protocol）等、多くのプロトコルで使用することが可能です。

●SSL/TLSのセキュリティ問題

近年以下に示すように、SSLとTLSに複数の重大な脆弱性が発見されたため、現在ではSSLの全バージョン及びTLSの初期バージョンについては使用が推奨されていません。そのためSSL/TLSについては、TLSの最新バージョンである1.3を使用することが推奨されます。

＜SSL/TLSで発見された主な脆弱性＞

■SSL3.0及びTLS1.0, TLS1.1の「POODLE」脆弱性

SSL3.0において、攻撃によって暗号化された通信が解読されてしまう脆弱性が存在することが2014年10月に公表されました。この脆弱性はPOODLE（Padding Oracle On Downgraded Legacy Encryption）と名付けられています。
その後、この脆弱性がTLS 1.0 , TLS 1.1においても存在することが報告されました。

■SSL/TLSの「FREAK」脆弱性

SSL/TLSにおいて、米国からの輸出規制により導入された弱い暗号技術をサポートしていたことに起因する脆弱性が存在することが2015年3月に公表されました。

この脆弱性は「FREAK：Factoring attack on RSA-EXPORT Keys」と名付けられており、一般的に利用されているブラウザ等に広く影響があることが判明しました（現在はいずれも脆弱性を修正したバージョンが提供されています）。

FREAKの脆弱性が悪用されると、攻撃によってバージョンの古い脆弱な暗号技術の使用が強制され、暗号化された通信が解読されてしまう可能性があります。
このような攻撃をダウングレード攻撃と呼びます。

●TLS1.3におけるハンドシェイク手順

ここから、TLS1.3におけるセキュアな通信の確立（ハンドシェイク）手順について解説します。
TLS1.3におけるハンドシェイク手順は次の図のようになっています。

TLS1.3におけるハンドシェイク手順

①Client Hello

クライアントが利用可能な暗号スイート（暗号アルゴリズムの組み合わせ）、鍵の合意に必要なクライアント側の情報、TLSバージョン等をサーバに送信し、通信の開始を通知します。

②Server Hello

サーバが、クライアントから送られてきた一覧の中から実際に使用する（合意した）暗号スイート、鍵合意に必要なサーバ側の情報、TLSバージョン等をクライアントに通知します。
TLS1.3では、この時点でクライアントとサーバ間での鍵合意が成立するため、これ以降の通信が暗号化されます。

③Encrypted Extensions

サーバからの補足情報として、アプリケーション層で使用するプロトコルに関する情報（ALPN：Application-Layer Protocol Negotiation）等が送られます。

④Certificate Request（クライアント認証を行う場合のみ）

サーバがクライアントに対し、デジタル証明書の提示を要求します。その際、サーバが信頼している認証機関の情報等も提示します。
前述の通り、一般的なWebサイトではクライアントの認証は省略しているため、この工程はスキップされます。

⑤Certificate

サーバが、自身のデジタル証明書をクライアントに送信します。

⑥Certificate Verify

サーバが、自身のデジタル証明書の秘密鍵を用いて、ここまでの通信内容のダイジェスト（ハッシュ値※）からデジタル署名を生成し、検証情報として送信します。これを受信したクライアントは、⑤で受け取ったサーバのデジタル証明書に含まれる公開鍵を使い、デジタル署名を検証します。

※ハッシュ値

元のデータから固定長の値を出力する関数（ハッシュ関数）を用いて求めたもの。ハッシュ値により、大きなサイズのデータの一致や不一致を容易に照合することができます。

⑦Finished

サーバがハンドシェイクの終了をクライアントに通知します。

⑧Certificate（クライアント認証を行う場合のみ）

クライアントが、自身のデジタル証明書をサーバに送信します。
一般的なWebサイトではこの工程はスキップされます。

⑨Certificate Verify（クライアント認証を行う場合のみ）

クライアントのデジタル証明書の秘密鍵を用いて、ここまでの通信内容のダイジェストからデジタル署名を生成し、検証情報として送信します。これを受信したサーバは、⑧で受け取ったクライアントのデジタル証明書に含まれる公開鍵を使い、デジタル署名を検証します。
一般的なWebサイトではこの工程はスキップされます。

⑩Finished

クライアントがハンドシェイクの終了をサーバに通知します。以降はアプリケーションデータの通信が行われます。