Defaults.Exposed › 修正 › 最新の暗号化(TLSバージョンと暗号スイート)
最新の暗号化(TLSバージョンと暗号スイート) の直し方
TLSは、訪問者とウェブサイトの間を流れるデータを暗号化する鍵です。その鍵を信頼できるものにするのは2つ。最新バージョンのTLSを使うこと(古く破られたものではなく)、そして強い暗号スイート(実際の暗号化のレシピ)を使うことです。このページは両方を扱い、さらに評点には影響しないが知っておく価値のある関連設定にも触れます。
あなたのビジネスにとっての結論: サイトが時代遅れの暗号化や弱い暗号スイートで動いていると、顧客が入力する個人情報(ログイン、カード番号、連絡先)が共有ネットワーク上で静かに傍受され読まれることがあり、銀行・決済処理業者・大口顧客が取引前に要求するセキュリティチェックに落ちかねません。
これで失いかねないもの
- 顧客がホテルやカフェのWi-Fiで支払うかサインインし、時代遅れの接続や弱い暗号スイートが同じネットワーク上の見知らぬ者にカードとパスワードを読ませ、その不正—そして怒りの電話—がまっすぐあなたのサイトに辿り着きます。
- カード決済を申し込む(または決済事業者が再監査する)と、時代遅れのTLSや禁止された暗号スイートが決済セキュリティの規則を破って却下され、修正されるまでオンライン決済が凍結されます。
- 大口顧客のITチームが契約前に定例のセキュリティスキャンを行い、サイトがまだ破られた暗号化を許していることを見てリスクと判定し、修正に費用がかからない問題で契約が止まります。
- データ保護の苦情や情報漏えいがあなたの机に届き、規制当局が最初に問うのは顧客データを『適切に』守ったかどうかです。何年も公に破られていると知られた暗号化を動かしていたとは、答えにくい問いです。
- サイトに鍵マークが出ているので皆が完全に安全だと思い込み、このギャップが何年も気づかれず、ひとつの傍受されたログインやカード番号が、無料の修正よりはるかに高くつくインシデントに変わるまで続きます。
なぜ重要か。 安全な暗号化は見えませんが、時代遅れや弱い暗号化は、顧客・契約・コンプライアンス合格を失わせる日まで静かに潜む負債です。TLSバージョンと暗号スイートの検査が、実際に評点を動かす2つの部分で、どちらもたいてい無料のひとつの設定です。古く破られた選択肢をオンのままにしておく利点は何もありません。
平易に言うと
誰かがあなたのウェブサイトを訪れるとき、入力するすべて(ログイン、カード番号、氏名、電話番号、メッセージ)は、見知らぬ者が読めないよう転送中に暗号化されます。その暗号化を行う技術がTLSです(古い名前のSSLと呼ばれることもあります)。その暗号化が実際に安全であるためには、2つのことが正しくなければなりません:
- TLSバージョン — 使っている技術の世代。初期バージョン(TLS 1.0と1.1)は何年も公に破られています。安全なものはTLS 1.2とTLS 1.3です。
- 暗号スイート — TLSが暗号化に使う具体的なレシピ。一部の暗号スイート(RC4、DES、3DESなど)は破られて今や禁止され、最新の暗号スイートは依然として強い。
このページは両方を扱います。サイトは片方を正しく、もう片方を誤りうるからです。最新の鍵に、古く破れるレシピをオンのまま残せますし、強いレシピが時代遅れの鍵に守られていることもあります。どちらのギャップも開いたドアです。両方ともたいてい、サーバーやホスティング設定への同じひとつの無料変更で閉じられます。
これが招きうる損失
- 公衆Wi-Fiで顧客が奪われる。 誰かがホテル・カフェ・空港でアカウントにサインインするか支払います。サイトがまだ古いTLSバージョンや弱い暗号スイートを許しているため、同じネットワーク上の見知らぬ者が接続を破れる選択肢へ引き下げ、パスワードとカード番号をリアルタイムで読みます。不正は顧客に降りかかりますが、非難—とサポートの電話—はあなたに降りかかります。
- カード決済が止められる。 決済セキュリティの規則(PCI DSS)はTLS 1.2を最低条件とし、RC4のような弱い暗号スイートを明示的に禁じます。処理業者が再監査するとき、またはカード決済を申し込むとき、時代遅れの設定はチェックに落ち、修正されるまで決済が凍結されます—資金繰りにとって最悪のタイミングで。
- セキュリティ審査で商談が止まる。 大口顧客が契約する前に、そのITチームが定例スキャンを行います。サイトがまだ破られた暗号化を受け入れていると即座に指摘します—注意散漫に見え、他に何が緩いのかと買い手に思わせる類の指摘です。修正に費用のかからない問題で、契約が宙に浮きます。
- 規制当局が厄介な問いを投げる。 苦情や情報漏えいの後、データ保護当局が最初に知りたいのは個人データを『適切に』守ったかどうかです。何年も公に破られたと知られる暗号化を動かしていたのは非常に弁護しにくく、『古いバージョンがまだオンだと気づかなかった』は心地よい答えではありません。
- 何年も鍵マークの陰に隠れる。 サイトがまだ普通の鍵マークを出すため、誰もギャップに気づかず、ひとつの傍受されたログインやカード番号が、5分の修正よりはるかに高くつく公のインシデントになるまで続きます。
これの実体
TLSバージョン
サイトはTLSのひとつのバージョンだけをサポートするのではなく、複数を同時に提供し、各訪問者のブラウザに選ばせられます。最新の訪問者は利用可能な最新バージョンを使い、普通の鍵マークを見ます。危険なのは、古く破られたバージョンが良いものと並んで開いた裏口として残りうることです。攻撃者は訪問者の接続をTLS 1.0や1.1へ『ダウングレード』させ、それらのバージョンの既知の弱点(有名な例はBEASTとPOODLE攻撃)を突いてトラフィックを復号できます。
そこで当社の検査はサイトに接続し、各バージョン(TLS 1.0、1.1、1.2、1.3)を個別にテストして、サーバーがまだどれを受け入れるかを確認します。『良い』状態と採点は以下のとおり:
- TLS 1.3(1.2の有無を問わず)、レガシーなし: 最良の結果—最新でクリーンな設定。満点。
- TLS 1.2のみ、1.3なし: 安全で合格しますが、最新で最速のバージョンを使わずにいます。ほぼ満点。1.3を有効にする価値はあります。
- TLS 1.0や1.1がまだ受け入れられる: 自動不合格、0点で致命的と表示されます。1.2/1.3も動くことは関係ありません。破られたバージョンが開いたドアだからです。これが直すべきものです。
暗号スイート
バージョンが選ばれると、TLSは暗号スイート—実際にデータを暗号化するアルゴリズム—を選びます。ほとんどの最新の暗号スイートは強い。一握りは破られていて決して使ってはいけません。RC4(暗号化に偏りがあり平文を漏らす)、DES(鍵が短すぎて総当たりされる)、3DES(『Sweet32』攻撃に脆弱)、加えてNULL(暗号化なし)、EXPORT級の暗号スイート(意図的に弱められたもの—FREAKとLogjam攻撃)、匿名の暗号スイート(身元確認なしで間に偽者が座れる)です。
当社の暗号スイート検査は2つのことを行います。まず、サーバーが実際に当社と交渉した暗号スイートを見ます。次に—ここが重要—いくつかの既知の破られた暗号スイート(RC4、3DES、EXPORT、NULL、匿名の変種)で実際にハンドシェイクを試みます。サーバーは最新のクライアントには強い暗号スイートを選べても、攻撃者が要求すれば弱いものを受け入れることがあり、それが本物のダウングレードリスクです。サーバーが禁止された暗号スイートを受け入れると検査が指摘し、致命的なもの(RC4やNULLなど)を受け入れると不合格です。(TLS 1.3ではここで心配は無用です。そのバージョンは設計上すべての弱い暗号スイートを除いたので、プローブは省略されます。)
3つの情報提供の追加項目
3つの関連項目は報告されますが評点には影響しません。外部から確実に検証できず、最新のサーバーやCDNではすでに正しく扱われているため、情報提供として表示されます:
- TLS圧縮(CRIME攻撃): オンのまま残すと攻撃者がセッションCookieを引き出せる古い機能。10年以上、すべての最新ウェブサーバーで初期状態で無効化されており、今日では事実上問題ではありません。
- OCSPステープリング: サーバーが証明書が失効していない証拠を先取りし、各訪問者が認証局に自分で問い合わせなくて済む(遅く、閲覧データを漏らす)性能とプライバシーの工夫です。CloudflareのようなCDNは自動で行います。
- セキュアな再ネゴシエーション: 攻撃者がセッションにデータを注入できた古い欠陥(CVE-2009-3555)の修正。TLS 1.3は再ネゴシエーションを完全に除いたのでそこでは問題なく、最新のTLS 1.2サーバーは初期状態で修正を実装しています。
これらを表に出すのはIT担当が全体像を把握できるようにするためですが、大多数のオーナーにとって何もすることはありません。評点は上のバージョンと暗号スイートの検査で決まります。
修正方法(無料・約30分)
IT担当にこれを渡してください。修正は無料です。 この項は、ドメイン・ウェブサイト・ホスティングを管理している人向けです。修正は買い物ではなく設定変更で、当社が料金をいただくのは暗号化が正しく設定された状態を保ち続けているかを監視する場合のみです。下の単一の最新設定でバージョンと暗号スイートの両方の指摘を一度に直せます。
最も確実で簡単な方法は、手書きするのではなく既知の良い設定を生成することです。MozillaのSSL Configuration Generator(https://ssl-config.mozilla.org/)にサーバーの種類を貼り、『Intermediate』プロファイル(広い互換性)または『Modern』(古いものを支える必要がなければTLS 1.3のみ)を選びます。正しいssl_protocolsとssl_ciphersの行を出力してくれます。
プラットフォーム別:
- Cloudflareやマネージドホスト—たいてい1〜2クリック。 Cloudflareでは:SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2。暗号スイートはそこで任せられます(プラットフォームは禁止された暗号スイートを提供しません)。ほとんどのマネージドホストやサイトビルダー(Squarespace、Wix、Shopify、最新のWordPressホスト)はすでに強い暗号スイートでTLS 1.2+を強制しています—『legacy TLS』や『old-browser compatibility』のオプションがまだオンになっていないか確認するだけです。
- Nginx。 最新のみのバージョンと明示的な強い暗号スイートリストを設定し、再読み込み:
(TLS 1.3にはマシン上でOpenSSL 1.1.1+が必要です。)ssl_protocols TLSv1.2 TLSv1.3; 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; - Apache。 古いバージョンを無効にし、強い暗号スイートリストを固定し、再起動:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder on - Windows / IIS。 無料のIIS Cryptoツール(または同等のレジストリ設定)でTLS 1.0と1.1を無効にし、RC4/DES/3DES/NULL/EXPORT暗号スイートを無効にし、TLS 1.2と1.3を強い暗号スイートで有効に残します。ツールの『Best Practices』テンプレートはこれをワンクリックで行います。
- 情報提供の追加項目(任意、無料)。 きれいに仕上げたいなら:NginxではOCSPステープリングに
ssl_stapling on; ssl_stapling_verify on;(resolver行とともに)を追加、ApacheではSSLUseStapling On。TLS圧縮とセキュアな再ネゴシエーションは最新サーバーで初期状態で安全—対応不要です。Cloudflareでは3つすべて自動で扱われます。 - 検証して、ここで再チェックする。 安全なバージョンと暗号スイートだけが残ることを確認—例えば
nmap --script ssl-enum-ciphers -p 443 yourdomain.com、またはhttps://ssl-config.mozilla.org/がリンクするツールでテスト—してから、この検査を再実行します。可能であれば1.2と並べてTLS 1.3を有効にしてください。より速く、より安全です。
よくある間違い
- 『鍵マークがあるから大丈夫』。 鍵マークは安全な接続が存在することを証明するだけ。古いバージョンや禁止された暗号スイートがまだ背後で受け入れられているかは何も言いません—まさにそれがこれらの検査が見つけるギャップです。
- バージョンは直すが暗号スイートはしない(または逆)。 TLS 1.0/1.1を無効にしてもRC4や3DESは自動で消えませんし、強い暗号スイートを固定しても古いバージョンは自動で無効になりません。両方を設定してください—上の生成された設定はそれを行います。
- 『legacy』や『old-browser compatibility』の切り替えをオンのまま残す。 多くのホストやCDNには、破られたバージョンや弱い暗号スイートを『互換性のため』に静かに再有効化するオプションがあります。実際の訪問者にはほぼ役立たず、この指摘を直接引き起こします。
- サーバーの再読み込み・再起動を忘れる。 設定変更はウェブサーバーが再読み込みされるまで反映されません—『直した』サイトがまだ落ちる意外に多い理由です。
- 1台のサーバーは設定したが全部はしない。 ロードバランサー、複数のウェブサーバー、別々のサブドメイン(shop、blog、app)を運用しているなら、各TLSエンドポイントに同じ設定が必要です—最も弱いものが攻撃者の狙いどころです。
覚えておくこと
TLSバージョンと暗号スイートは、実際に評点を動かす暗号化の2つの部分で、どちらも何年も公に破られてきた選択肢をオフにすることに尽きます。修正は無料で、たいていサーバーあたり1行の最新設定で、普通の訪問者には接続が本当に安全になる以外何も変わりません。関連項目(圧縮、OCSPステープリング、セキュアな再ネゴシエーション)は知っておく価値はありますが評点には影響せず、最新の設定ならすでに任せられています。
よくある質問
技術に詳しくありません。自分で対応できますか?
技術的な細部を理解する必要はありません。ほとんどの最新ホスティングではこれは1〜2個の設定で、無料です。下の『修正方法』の項を、ウェブサイトやホスティングを運用している人(またはIT業者)に渡してください。たいてい5〜10分の変更で、より安全な接続になる以外、訪問者に見える違いはありません。
最新の暗号化に切り替えると、古い顧客のブラウザが動かなくなりませんか?
実際にはなりません。およそ過去10年のすべての最新ブラウザとスマホは、すでに初期状態で新しい暗号化と強い暗号スイートを使っており、何年もそうです。古いバージョンや弱い暗号スイートに頼っていたものは、それ自体が時代遅れで安全でなく、まさにそれがすべての主要ブラウザがすでに拒否する理由です。ほぼすべての企業にとって、この変更は顧客には見えません。
サイトは鍵マーク付きで問題なく読み込まれます。なぜまだ指摘されるのですか?
鍵マークは安全な接続が存在することを意味するだけで、背後のTLSがどのバージョンか、どの暗号スイートかは教えてくれません。サイトはまったく普通の鍵マークを出しつつ、良いものと並べて古い破られたバージョンや禁止された暗号スイートを静かに受け入れていることがあり、その開いた裏口こそこれらの検査が捕まえるものです。それを閉じても鍵マークは消えません。安全な選択肢だけが許されるようにするだけです。
TLSバージョンと暗号スイートの違いは?
TLSバージョンは使っている鍵の世代、暗号スイートはデータを暗号化する具体的なレシピと考えてください。最新の鍵(TLS 1.2や1.3)でも、古く破れるレシピ(RC4や3DESなど)をオンのまま残せます—あるいはその逆も。両方が正しくなければならないので別々に検査します。良い知らせは、同じ1行の最新設定でたいてい両方を一度に直せることです。
OCSPステープリングやTLS圧縮は評点に影響しますか?
いいえ。それら(およびセキュアな再ネゴシエーション)は情報提供のみです。性能と多層防御に関わるので報告しますが、評点は動かしません。最新のウェブサーバーやCloudflareのようなCDNでは初期状態で正しく扱われるので、ほとんどのオーナーにとって何もすることはありません。詳細は下のIT担当向けの項にあります。
これの修正は本当に無料ですか?
はい。古いTLSバージョンと弱い暗号スイートを無効にし、これらの保護を有効にするのは、既存のサーバーやホスティングの設定変更で、買うものはありません。当社が料金をいただくのは、暗号化が正しく設定された状態を保ち続けているかを監視する場合のみで、修正ではありません。