変化する暗号化の世界：2020年のTLS導入状況

David Warburton脅威リサーチ担当ディレクター | F5

オンラインプライバシーは、もはや単に人目を避けるだけの問題ではありません。Web上の暗号化は、プライバシーの確保に重要な役割を果たしており、絶えず変化しています。

かつてはログインページや決済ページに限って使用されていたTransport Layer Security（TLS）などの暗号化プロトコルは、近年その重要性が高まっており、エンドポイントの認証と機密性を保った通信を可能にしています。過去2年間で、TLS標準も更新されました。ブラウザーはまもなく、TLS 1.0や1.1など、古く脆弱なプロトコル実装をブロックするようになります。また、現在も広く使用されている安全でないプロトコルを保護するため、新たなプロトコルも導入されつつあります。

企業がこうした変化への対応に苦慮する可能性があることは容易に想像できます。たとえば昨年初め、セキュリティ研究者は、新たに登場したドメインネームシステム（DNS）暗号化プロトコルであるDNS-over-HTTPS（DoH）を利用する、史上初のマルウェアサンプルを発見しました。

TLSを取り巻く状況は以前とは異なります。組織は、Webサイトを安全に導入し、そのライフサイクル全体にわたって維持するために、最新の動向を常に把握しておく必要があります。

変化に対応し続ける

概して、企業はTLSの新たなアップデートがもたらすメリットを理解しており、変化を受け入れる姿勢を示しています。たとえば、F5 Labsの最新TLSテレメトリレポートによると、Alexaの上位100万サイトのうち、約3分の1がTLS 1.3接続を受け入れていました。多くの点で、これはビジネス上合理的な判断です。主要なWebブラウザのほとんどはすでにこの新規格に対応しており、セキュリティとパフォーマンスの両面でさまざまなメリットが得られます。

しかし、現時点では、誰もが最新のTLSを導入できるわけではありません。

この場合、企業はRSA鍵交換を提供する暗号スイートを削除し、RSA鍵交換を完全に無効化することを検討すべきです。F5の調査では、セキュリティ研究者が依然としてRSAへの攻撃手法を発見しているにもかかわらず、世界で最も人気のあるWebサイトの3分の1以上が、今なおRSAを優先暗号アルゴリズムとして提供していることが明らかになりました。これには、TLSサーバーの秘密鍵を使用してRSAの復号および署名処理を実行できる、発見から19年が経過したROBOT脆弱性も含まれます。F5 Labsの調査によると、世界の上位サイトの2%強が、今なおこの脆弱性を悪用した攻撃を受ける可能性があります。

他のソフトウェアと同様に、TLSライブラリでもセキュリティ研究者によって脆弱性が発見されることが少なくありません。そのため組織は、Webサーバー、ロードバランサー、またはアプリケーションデリバリーコントローラーのTLSスタックに更新がある場合、確実に通知を受けられるようにする必要があります。迅速にパッチを適用するためのポリシーも不可欠です。

また、どの認証局（CA）でも、Web上のあらゆるドメインに対して証明書を発行できる点にも注意が必要です。そのため、証明書の発行を許可する認証局を、広く知られ信頼されている2～3のCAに限定することが賢明です。これは、DNSのCertification Authority Authorization（CAA）レコードを作成することで実現できます。さらに、WebアプリにHTTP Strict Transport Security（HSTS）ヘッダーを適用すると、ブラウザーは常にHTTPS経由でのみサイトを安全に読み込もうとするため、セキュリティをさらに強化できます。これは、安全でないページを強制的に読み込ませ、攻撃者によるネットワークトラフィックの盗聴、改ざん、リダイレクトを可能にするネットワーク攻撃の防止に役立つ重要な対策です。

DNS CAAレコードは、有効なドメインに対する証明書の誤発行を防ぐために作成されましたが、詐欺行為者がmybank.comのような既存ドメインの証明書を取得しようとすることはほとんどありません。代わりに、mybank.attacker.comのように、ブランド名「mybank」をサブドメインとして使用した、自らが所有するドメインの証明書を作成します。

幸い、いずれかのCAによって証明書が発行されるたびに、その情報は世界中に分散されたデータベース（Certificate Transparencyログ）に記録されます。CTログを監視することで、脅威アクターによるドメインやブランドのなりすましを把握できます。

HTTPSが広く普及した現在、管理すべき暗号方式、鍵、証明書も増えています。DevOps手法の導入拡大も相まって、変更とデプロイのスピードは加速し続けています。

セキュリティツールとテストを自動化ツールチェーンに統合するのと同様に、HTTPSの設定も統合する必要があります。そのためには、デジタル証明書の作成をオーケストレーションするとともに、最小鍵長や暗号スイートなどの基準を定める社内ポリシーを策定する必要があります。このような自動化は、有効期限が近い証明書にも対応し、サービスが中断する前に自動更新するうえで役立ちます。

TLSセキュリティギャップへの対応

残念ながら、TLSを正しく導入しても、プライバシーとセキュリティには依然として多くのギャップが残ります。DNS-over-HTTPS（DoH）など、こうしたギャップの解消に役立つプロトコルが登場しています。これらはWebユーザーのプライバシーを向上させる一方で、企業のセキュリティチームによる悪意のあるトラフィックの特定とブロックを困難にする可能性もあります。場合によっては、企業ネットワークでDoHを無効にするか、ユーザー向けに社内DoHサービスを導入する必要があります。これらのサービスはWebプロキシと連携し、不要なトラフィックの除外に役立ちます。

結局のところ、どれほど優れたTLS導入環境であっても、クライアント側のマルウェアによる悪意のあるコードの挿入や、サードパーティ製スクリプトに起因する侵害を防ぐことはできません。そのため、HTTPSの限界と、どのようなギャップが存在するかを把握することを常に推奨します。

確かなことが1つあります。それは、暗号化が常に進化しているということです。鍵長は長くなり、証明書の自動化が進み、政府による規制が課され、新たなプロトコルが登場しています。この絶え間ない変化が、多くの組織とその顧客に新たなレベルのリスクをもたらします。不適切なTLS導入は、ハッカー、規制当局、サイバーセキュリティ保険会社に見過ごされることはなく、組織の他のインフラストラクチャについても重大な疑念を招く可能性があります。

著者について

David Warburton脅威リサーチ担当ディレクター | F5

David Warburtonのその他のブログ記事