【入門編】脆弱な暗号スイート(TLS 1.0/1.1, RC4, 3DES)の無効化 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！新米IT担当者やセキュリティの勉強を始めたばかりの開発者の皆さん、日々のインフラ管理やアプリ開発、本当にお疲れ様です。

突然ですが、皆さんは会社のウェブサイトや、自分が作ったサービスにアクセスするとき、アドレスバーにある「鍵マーク」を気にしたことはありますか？あの鍵マークのおかげで、私たちのパスワードやクレジットカード番号が、途中で悪い人に盗み見られないよう安全に守られていますよね。

でも、ちょっと待ってください。その「鍵」の仕組みが、もし「昭和の時代に使われていた、簡単にピッキングできる古い鍵」だったらどうでしょう？どれだけ頑丈なドアをつけていても、鍵自体がボロボロなら泥棒は簡単に侵入できてしまいます。

インターネットの世界でも、これと全く同じことが起きています。今回は、サーバーとユーザーの間をガチガチに守るために絶対に必要な「古い暗号の無効化と、新しい暗号への切り替え」について、身近な例えを交えながら優しく紐解いていきましょう！

—

1. 泥棒は「一番ボロい鍵」を狙う！古い暗号の危険性

私たちが普段使っているHTTPS（暗号化された通信）の裏側では、ブラウザ（お客さん）とサーバー（お店）が「どの暗号方式で会話するか」を最初に相談する手順（ハンドシェイク）があります。

ここで登場するのが、TLS 1.0やTLS 1.1といった古い通信プロトコル（お約束事）や、RC4、3DESといった古い暗号の仕組みです。これらは例えるなら、「昔の木造住宅についている、簡単に壊せる古いシリンダー錠」のようなもの。

セキュリティの技術は日進月歩ですが、それに合わせて悪い奴ら（攻撃者）の技術も進化しています。古い暗号には、次のような致命的な弱点があります。

解読のしやすさ: 計算能力が上がった現代のパソコンを使えば、古い暗号は数時間、あるいは数分で破られてしまいます。
通信の盗聴（中間者攻撃）: Wi-Fiスポットなどで、通信の途中に悪い奴が割り込み、古い暗号の隙を突いてパスワードを丸見えにしてしまうリスクがあります。

「うちは大企業じゃないから狙われないよ」なんて油断は大敵です。攻撃者は自動化されたプログラムを使って、世界中のサーバーから「古い鍵を使っているところ」を常にスキャンして探し回っています。だからこそ、私たちは自ら古い鍵を捨て、最新の強固な鍵に付け替えなければならないのです。

—

2. 目指せ「完全前方秘匿性（PFS）」！新しい鍵の仕組み

古い暗号を捨てるだけではありません。私たちが目指すべきは、「Perfect Forward Secrecy（PFS：完全前方秘匿性）」という、ちょっとカッコいい名前のセキュリティ思想です。

これも身近な例えで考えてみましょう。

従来のダメな仕組み:

あなたが毎日、同じ「合鍵」を使って金庫を開け閉めしています。ある日、その合鍵が泥棒に盗まれてしまいました。すると泥棒は、過去にあなたが金庫にしまった手紙も、未来にしまう手紙も、すべて自由に見られるようになってしまいます。

PFS（完全前方秘匿性）の素晴らしい仕組み:

通信をするたびに、その場限りの「使い捨ての特別な鍵」を自動で作ります。今日の通信に使った鍵は、明日には消滅します。もし万が一、数年後にサーバーがハッキングされて過去のデータが記録されていたとしても、「その場限りの使い捨ての鍵」はもう消えているので、過去の通信内容は絶対に解読できないという仕組みです。

最高にクールですよね！このPFSを確実に効かせるために、サーバーの設定を今すぐ見直していきましょう。

—

3. 実践！ Nginx / Apacheでの設定変更

それでは、実務で使える具体的な設定方法を見ていきましょう。今回は多くの現場で使われているWebサーバー「Nginx」と「Apache」を例に挙げます。

新米エンジニアの皆さんは、先輩に「設定ファイルをいじる時は必ずバックアップを取るんだよ！」と教わったはず。まずは現在の設定をバックアップしてから、以下の設定に書き換えてみてください。

Nginxの場合

設定ファイル（通常は /etc/nginx/nginx.conf またはバーチャルホストの設定ファイル）を開き、ssl_protocols と ssl_ciphers の項目を次のように書き換えます。

server {
    listen 443 ssl;
    server_name example.com;

    # 証明書のパス設定などは省略...

    # 【重要】古くて危険な TLS 1.0 や 1.1 は完全に拒否し、安全な TLS 1.2 と 1.3 だけを許可する
    ssl_protocols TLSv1.2 TLSv1.3;

    # 【重要】PFS（完全前方秘匿性）をサポートする強力な暗号スイートだけを優先順位高く設定する
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';

    # サーバー側で暗号の優先順位を強制する
    ssl_prefer_server_ciphers on;
}

Apacheの場合

Apacheの場合は、モジュール設定やバーチャルホストの設定ファイル（httpd.conf や ssl.conf など）を次のように調整します。

<VirtualHost *:443>
    ServerName example.com

    # 証明書のパス設定などは省略...

    # 【重要】古いプロトコルを無効化し、TLS 1.2と1.3のみを有効にする
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

    # 【重要】安全でPFSに対応した暗号スイートを指定する
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

    # サーバー側の設定（暗号の順番）を優先する
    SSLHonorCipherOrder on
</VirtualHost>

これらの設定を保存したら、設定ファイルに文法エラーがないかテスト（Nginxなら nginx -t、Apacheなら apachectl configtest）し、問題がなければサービスを再起動（systemctl restart nginx または httpd）させます。これで、サーバーの防犯レベルが一気に跳ね上がります！

—

4. 設定したら「必ず」自分の目で確かめよう

「設定を変えたから、たぶん大丈夫！」で終わらせないのが、プロのセキュリティエンジニアへの第一歩です。本当に古い暗号が弾かれているか、自分の手で確認してみましょう。

一番手軽で確実なのは、ウェブ上の無料診断ツールを使う方法です。
有名なところでは、「SSL Labs (Qualys SSL Server Test)」というサイトがあります。自分のサーバーのドメインを入力して診断を実行するだけで、A+ から F までの成績表をつけてくれます。

もし設定が甘く、TLS 1.0が残っていたりすると、成績は「B」や「C」に下がってしまいます。目標は、最高評価の 「A」 または 「A+」 です！診断結果の画面で「RC4」や「3DES」がすべて「No」になっているのを確認できたときの達成感は、エンジニアとして格別ですよ。

—

まとめ：一歩ずつ、安全なインフラを作っていこう

今回は、古い暗号スイート（TLS 1.0/1.1, RC4, 3DES）を無効化し、PFSを適用するための理由と具体的な設定方法を解説しました。

最初は「暗号スイート？プロトコル？なんか難しそう……」と思ったかもしれませんが、要するに「ボロい鍵を捨てて、最新の強固な鍵に付け替えよう！」という、現実世界の防犯と全く同じお話です。

セキュリティの対策に「これで完璧」というゴールはありませんが、こうした地道な設定の積み重ねが、あなたや会社のサービス、そして何より大切なユーザーを守る盾となります。

一歩ずつ、確実に知識とスキルを身につけて、頼れるIT担当者・開発者を目指していきましょう！次回の解説もお楽しみに！