HTTPSとTLSの仕組みを実践ガイドで徹底解説
ブラウザの鍵アイコンを見て、そのサイトは安全だと思ったことはありませんか？しかし、HTTPSのURLにアクセスしたとき実際に何が起きているのでしょうか？なぜ一部の証明書は警告を引き起こすのでしょうか？そして、接続が本当にエンドツーエンドで暗号化されているかどうかをどうやって確認できるのでしょうか？このガイドでは、HTTPSとTLSを実用的な観点から分解し、ハンドシェイクの手順、証明書の検証方法、コマンドラインツールを使った実際の接続の検査方法を紹介します。読み終える頃には、TLSの問題をデバッグし、自身のWebセキュリティについて情報に基づいた判断ができるようになるでしょう。
HTTPSとは実際に何か
HTTPSは、TLS（Transport Layer Security）の上にHTTPを重ねたものです。TLSは次の3つの保証を提供します：
- 機密性：データは暗号化され、盗聴者に読まれることはありません。
- 完全性：データは転送中に検出されずに変更されることはありません。
- 認証：あなたはドメインを所有するサーバーと通信しており、詐称者ではありません。
TLSがない場合、HTTPはパスワード、Cookie、コンテンツなどすべてをネットワーク上に平文で送信します。TLSはそのトラフィックを暗号化されたトンネルで包みます。鍵アイコンは接続が暗号化され、証明書が有効であることを意味しますが、サイトが信頼できるとか、他の点で安全であることを意味するわけではありません（例えば、脆弱性がまだある可能性があります）。
TLSハンドシェイクを平易な言葉で
HTTPデータが交換される前に、クライアントとサーバーはTLSハンドシェイクを実行します。正確な手順はTLS 1.2と1.3で若干異なりますが、基本的な考え方は同じです：アルゴリズムに合意し、サーバーを認証し、共有鍵を確立します。以下はTLS 1.3（現代のデフォルト）の簡略化されたフローです：
- Client Hello：クライアントはサポートする暗号スイートのリスト、ランダム値、鍵共有（鍵交換用）を送信します。
- Server Hello：サーバーは暗号スイートを選択し、自身のランダム値と鍵共有を送信し、証明書チェーンを提供します。
- 証明書の検証：クライアントは証明書の有効性、ドメイン名、信頼チェーンをチェックします。
- 鍵の導出：両側はDiffie-Hellman（多くの場合X25519）を使用して同じ共有秘密を計算します。そこから対称セッション鍵を導出します。
- Finished：両側はハンドシェイクトランスクリプトに対するMACを送信し、何も改ざんされていないことを確認します。
ハンドシェイク後、アプリケーションデータ（HTTPリクエスト/レスポンス）はセッション鍵で暗号化されます。TLS 1.3はハンドシェイクを1ラウンドトリップ（1-RTT）に短縮し、0-RTT再開をサポートするため、TLS 1.2より高速です。
証明書の検証：ブラウザがサイトを信頼する仕組み
サーバーが証明書を送信すると、クライアントはそれを検証する必要があります。ブラウザ（またはHTTPクライアント）はいくつかのチェックを実行します：
- 信頼チェーン：証明書は、クライアントのトラストストアにあるルートCAに連鎖する信頼された認証局（CA）または中間CAによって署名されている必要があります。
- ドメイン名：証明書のSubject Alternative Name（SAN）に、接続先のホスト名が含まれている必要があります。
- 有効期間：証明書は期限切れでなく、まだ有効でない期間もない必要があります。
- 失効：クライアントはOCSPまたはCRLをチェックして証明書が失効していないか確認する場合があります（ただし、これはしばしばベストエフォートです）。
いずれかのチェックが失敗すると、ブラウザは警告を表示します。たとえば、自己署名証明書は信頼されたCAによって署名されていないため、「この接続はプライベートではありません」という警告を引き起こします。
実際のTLS接続を検査する
OpenSSLを使用してハンドシェイクの詳細を自分で確認できます。ターミナルで次のコマンドを実行します（ホスト名を置き換えてください）：
openssl s_client -connect example.com:443 -servername example.com -showcerts出力には証明書チェーン、ネゴシエートされた暗号、TLSバージョンが含まれます。次のような行を探してください：
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bitこれは接続がAES-256-GCMでTLS 1.3を使用していることを示しています。curl -v https://example.comを使用してTLSハンドシェイクの概要を確認することもできます。
一般的なTLSの設定ミスとその発見方法
HTTPSが有効であっても、設定ミスはセキュリティを弱める可能性があります。よくある問題は次のとおりです：
| 問題 | リスク | 確認方法 |
|---|---|---|
| 弱いプロトコル（TLS 1.0/1.1） | 既知の攻撃に対して脆弱 | openssl s_client -tls1_1 -connect host:443が失敗するはず |
| 期限切れの証明書 | ブラウザの警告、信頼の破綻 | openssl s_client | openssl x509 -noout -datesで有効期限を確認 |
| 中間証明書の欠落 | 一部のクライアントが検証に失敗 | -showcertsを使用してチェーンの完全性を確認 |
| HSTSヘッダーがない | ダウングレード攻撃の可能性 | Strict-Transport-Securityヘッダーを確認 |
これらの修正は通常、サーバー設定の更新（例：Nginxではssl_protocols TLSv1.2 TLSv1.3;）と証明書チェーンが完全であることの確認を含みます。
実践的なHTTPS：開発者がすべきこと
- TLS 1.2または1.3のみを使用し、古いバージョンを無効にする。
- 信頼されたCAから証明書を取得する（Let's Encryptは無料で自動化されている）。
- HSTSを有効にしてHTTPSを強制する。
- 定期的に証明書を更新し、有効期限を監視する。
- SSL Labs（qualys.com/ssllabs）や
testssl.shなどのツールで設定をテストする。
サーバーログをデバッグしている場合、Nginx Log Analyzerはアクセスログ内のTLSハンドシェイクの失敗や証明書エラーを特定するのに役立ちます。
FAQ
TLSとSSLの違いは何ですか？
SSLはTLSの前身です。SSL 2.0と3.0は非推奨で安全ではありません。現代のシステムはTLS 1.2または1.3を使用します。人々は口語的に「SSL」と言いますが、実際にはTLSを意味します。
HTTPSはウェブサイトを完全に安全にしますか？
いいえ。HTTPSはトラフィックを暗号化し、サーバーを認証しますが、SQLインジェクション、XSS、権限設定のミスなどの脆弱性から保護するものではありません。それはセキュリティの一層に過ぎません。
サイトがTLS 1.3をサポートしているかどうかを確認するには？
openssl s_client -connect host:443 -tls1_3を使用します。ハンドシェイクが成功すれば、TLS 1.3がサポートされています。あるいは、ブラウザの開発者ツールのセキュリティタブでプロトコルを確認できます。
TLSハンドシェイクと証明書の検証を理解することは、安全なWebサービスを構築し維持するのに役立ちます。TLSエラーやパフォーマンスの問題のためにサーバーログを分析する必要がある場合は、Nginx Log Analyzerを試して、ログエントリを迅速に解析およびフィルタリングしてください。