こんにちは！Web開発やインフラの管理、本当にお疲れ様です。
「セキュリティ対策をしっかりしなきゃ」と思いつつも、専門用語が並ぶマニュアルを読むと、どうしても頭が痛くなってしまいますよね。
今回は、Webサイトの裏側でこっそり使われている古い通信の約束事――古い暗号スイート（TLS 1.0やTLS 1.1）が、なぜ今危ないと言われているのか、そしてどうやってそれを追い出せばいいのかを、身近な「お家の鍵」にたとえて一緒に優しく紐解いていきたいと思います。
一歩ずつ、安心して読み進めてくださいね！
—
1. そもそも「暗号化のバージョン（TLS）」ってなに？
私たちが普段使っているインターネットのWebサイト（https:// で始まるアドレス）は、ブラウザとお手元のパソコン・スマホの間で、データを盗み見られないようにカギをかけてやり取りしています。この「カギの掛け方のルール」の名前を TLS（Transport Layer Security） と呼びます。
このルールは時代とともに進化していて、古い順に以下のような歴史があります。
- SSL 3.0 / TLS 1.0 / TLS 1.1（古いルール：もう引退すべき世代）
- TLS 1.2（今のスタンダード：安全で広く使われている世代）
- TLS 1.3（最新のルール：さらに速くて安全な最先端）
新人の開発者さんやIT担当者さんが最初につまづきやすいのが、「動いてるんだから古い仕組みも残しておいたほうが、古いスマホのユーザーも使えて親切なのでは？」という優しさです。
でも、セキュリティの世界では、この「古い優しさ」が大きな落とし穴になってしまうんです。
—
2. 家の鍵で例える「古い暗号が危ない理由」
では、古い暗号（TLS 1.0やTLS 1.1）をそのまま残しておくと、何が危ないのかを「お家の鍵」に例えて考えてみましょう。
昔の合鍵は、ピッキングにめちゃくちゃ弱かった
あなたが昔住んでいた実家の玄関の鍵を想像してみてください。その鍵は、当時としては最先端だったかもしれませんが、何十年も経つうちに「ピッキングの裏技」が世の中にバレてしまい、専用の針金一本あれば、泥棒が数秒で開けられてしまう状態になっていたとしたらどうでしょう？
「古い暗号スイート」であるTLS 1.0やTLS 1.1は、まさにこの「昔のピッキングされやすい鍵」と同じ状態になっています。
POODLE（プードル）や BEAST（ビースト）といった有名な攻撃手法は、まさにこの古い鍵の「ちょっとしたほころび」を泥棒（ハッカー）が突いて、通信の中身をこっそり覗き見してしまう手口なんです。
「うちのサイトは機密情報を扱っていないから大丈夫」と思っていても、利用客のログインパスワードや、入力された個人情報がもし盗聴されたら大変ですよね。だからこそ、古い鍵はさっさと取り替えて、誰も開けられない頑丈な新しい鍵（TLS 1.2 / TLS 1.3）だけに絞る必要があるのです。
—
3. 実践！古い暗号を無効化して、新しい安全な設定に変えよう
それでは、実際にWebサーバーの設定を変更して、古い危険な鍵を使えないようにする手順を見ていきましょう。
今回は、世界中で最もよく使われているWebサーバーのひとつである Nginx（エンジンクス） の設定ファイルを例に解説しますね。
Nginxでの設定例
サーバーの設定ファイル（通常は /etc/nginx/nginx.conf など）を開き、ssl_protocols という項目を探してみてください。
server {
listen 443 ssl;
server_name example.com;
# 証明書のパス設定などは省略...
# 【重要】安全なTLSのバージョンだけを許可し、古いものは完全にシャットアウトする
# 古い TLS 1.0 と TLS 1.1 は記述せず、1.2 と 1.3 のみを指定します
ssl_protocols TLSv1.2 TLSv1.3;
# 泥棒に破られやすい古い暗号スイート（RC4やDESなど）を排除し、強固なものだけを厳選する
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
# サーバー側の暗号スイートの優先順位を強制する（古い弱い暗号化を勝手に選ばせないため）
ssl_prefer_server_ciphers on;
}この設定のポイントは、ssl_protocols の部分で TLSv1.0 と TLSv1.1 をスパッと消去し、TLSv1.2 TLSv1.3 だけを残しているところです。これだけで、古い脆弱な通信の入り口を完全に塞ぐことができます。
設定ファイルを保存したら、必ず文法エラーがないかテストしてから、サーバーを再起動（リロード）してくださいね。
# 設定ファイルの記述に間違いがないかテストするコマンド
sudo nginx -t
# 問題がなければNginxを優しく再起動して設定を反映させる
sudo systemctl reload nginx—
4. もう一つのキーワード：Perfect Forward Secrecy（PFS）ってなに？
セキュリティのニュースを見ていると、「Perfect Forward Secrecy（PFS：完全前方秘匿性）」という、またまた難しそうな言葉によく出会います。
これも家の鍵で例えてみましょう。
もし、あなたが毎日同じ「合鍵」を使って家に出入りしていて、ある日その合鍵が泥棒に盗まれてしまったとします。その鍵が「過去に使っていた全ての部屋の合鍵」だったら、泥棒は過去にあなたがその部屋に置いてきた秘密の日記や宝物を、あとから全部こっそり盗み見できてしまいますよね。
これが、PFSに対応していない古い通信の怖さです。
一方、Perfect Forward Secrecy（PFS）を有効にしていると、通信するたびに「その場限りの使い捨ての鍵（セッションキー）」が自動で新しく作られます。
たとえ、万が一、未来のどこかでサーバーのメインの鍵が破られたとしても、過去の「使い捨ての鍵」のデータはすでに消えているため、過去の通信をさかのぼって覗き見ることが絶対にできない仕組みになっています。
先ほど紹介したNginxの設定にある ECDHE-... という暗号スイートの文字（ECDHEの部分）は、まさにこの「使い捨ての鍵」を作ってくれる優秀な仕組み（一時的楕円曲線 Diffie-Hellman 鍵共有）を意味しています。安全な暗号スイートを選ぶことで、自動的にこの強力な防犯システムも手に入れることができるのです。
—
5. まとめ：一歩ずつ安全な環境を作っていこう
今回は、古い暗号スイート（TLS 1.0 / 1.1）の危険性と、それを現代の安全な規格へアップデートする方法についてお話ししました。
- 古い暗号は、いわば「ピッキングされやすい昔の鍵」。思い切って無効化しよう！
- 設定ファイルでは
ssl_protocols TLSv1.2 TLSv1.3;と書いて、古いバージョンを締め出そう。 - 使い捨ての鍵の仕組み（PFS）を取り入れて、過去の通信データまでしっかり守ろう。
セキュリティ対策は、一度覚えてしまえば次からの構築がぐっと楽になります。「難しそう」と身構えず、ご自身の管理するサーバーやWebサイトの設定を、ぜひこの機会に優しく見直してみてくださいね。あなたの第一歩を、心から応援しています！
コメント