HTTPS通信の横取りを防ぐ。eMudhra問題から見直す証明書運用
公開日 ・更新日
HTTPSの通信を横取りできるかどうかは、暗号化の有無だけで決まりません。攻撃者が通信経路へ入り、接続先の名前を含む偽の証明書を用意し、利用する端末やプログラムがその証明書の発行経路をまだ信頼している、という条件が重なると危険になります。eMudhraの問題は、認証局の中間鍵が弱く、公開情報から秘密鍵を復元できたことが焦点でした。
CERT-Inは、影響を受けた鍵から不正なTLS証明書を発行し、正規サイトを装って通信を傍受・改変できる可能性を説明しています。一方でGoogleは、影響する6件のTLS中間認証局から発行された証明書が、ブロック前にCertificate Transparencyログへ記録されていなかったとしています。ブラウザ側で検知・遮断が進んでも、すべてのサーバー間通信や組み込み機器が同じ更新を受けるとは限りません。
ブラウザ以外を棚卸しする
最初に、公開サイトだけでなく、管理画面、API、決済、フォーム、Webhook、メール連携、CDNからオリジンへの接続を一覧化します。各接続について、証明書の発行元、SANに含まれる名前、中間証明書、ルート証明書、満了日時、TLSを検証するソフトウェアを記録します。
ブラウザはベンダーが配布するブロック情報やCertificate Transparencyを利用できますが、サーバー、コンテナ、CI、言語ランタイム、ネットワーク機器は、独自のCAバンドルを参照することがあります。CERT-Inも、OSとは別の信頼ストアを持つアプリ、ランタイム、コンテナ、組み込み機器を確認し、ベンダー更新を適用するよう求めています。ブラウザで正常に表示できたことだけでは、決済APIやWebhookまで安全だとは判断できません。
証明書と鍵を交換する
証明書チェーンが、対象の中間認証局やemSign ECC Root CA - G3につながっている場合は、影響を受けていないPKIから新しい証明書を取得します。新しい証明書だけでなく、秘密鍵も新しく生成し、CDN、ロードバランサー、オリジン、管理画面、APIへ反映します。更新後は、複数の端末とネットワークから証明書の名前、発行元、チェーン、満了日時を確認します。
証明書の警告を消すために、検証を無効にしたり、古いCAを手作業で信頼し続けたりしてはいけません。各OSやランタイムのCAバンドルを更新し、コンテナイメージとCI環境を再構築します。更新後も独自の証明書ストアを持つアプリが残っていないかを確認し、プロセスを再起動してから接続テストをやり直します。
監視と冗長化を残す
Certificate Transparencyの監視は、想定外の証明書発行を見つける補助線になります。ただし、CERT-Inが示す通り、CT監視だけで失効情報や信頼ストアの更新を置き換えることはできません。証明書の発行元とチェーンを定期的に取得し、異常があれば担当者へ通知します。
重要なサイトやAPIでは、一つの認証局に依存しない切り替え手順も用意します。新しい証明書を別のPKIで発行して反映できるか、フォームや決済、Webhookが動くかを平時に確認しておけば、今回のような信頼ストアの変更にも対応しやすくなります。HTTPSはブラウザの鍵マークだけでなく、すべての接続先と検証ソフトウェアを含めて運用するものです。
証明書チェーンと非ブラウザ接続の棚卸しを、現在のCDN・サーバー構成に合わせて整理したい方は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹