インターネットにおけるセキュリティの進歩

** 本記事は、The state of World Wide Web security in 2021 の翻訳です。最新の情報は英語記事をご覧ください。**

編集部注:
本記事は、2021 年 のインターネットユーザーの安全性を検証する 3 部作の 1 つです。このシリーズの他の記事は「ネットワークセキュリティの強化に役立つパスワードマネージャー」、「Wi-Fi を恐れることなかれ」の 2 つです。

最近の議論の中で、平均的なインターネットユーザーが 10 年前と比べると、どれだけ安全か、あるいはどれだけリスクが高いかという話題が出ました。

さまざまなニュースの見出しを見ると、現状は悪い方向に向かっているように感じるかもしれませんが、個人的にはかつてないほど安全になってきていると感じています。セキュリティの問題が「解決」されていないことは明らかですが、多くのリスクを排除できたように感じます。

そこで確認の意味も込めて、これまでの進歩を検証し、どのような変化がもたらされてきたかを振り返ることにしました。

初期のセキュリティ

今日の World Wide Web は、1990 年に Tim Berners-Lee が発案したものとは全く異なります。
初期の Web は自由でオープンなものでしたが、少々オープンすぎました。世界をつなぐ多数のサーバーやルーターの間を移動する情報を保護するためのプライバシーや暗号化もありませんでした。

Netscape は、SSL (Secure Sockets Layer) による暗号化を導入することで、この問題を解決しました。その後、TLS (Transport Layer Security) という正式な仕様に更新されました。当時の TLS は、ショッピングカートやクレジットカードの情報、時にはログイン ID やパスワードの安全性を確保するためのものでした。

セキュリティの標準化

2013 年、NSA (米国国家安全保障局) の契約職員であった Edward Snowden が、アメリカがいかに多くオンライン情報を世界中から集めているか、そして世界中のほぼすべての人のオンライン情報を収集可能であったことを公表しました。

それにもかかわらず、Snowden 氏の公表から数か月後の 2013 年 10 月の時点で、Mozilla Firefox で読み込まれる Web ページのうち、何らかの暗号化が使われていたのは 27.5% に過ぎませんでした。

これを受けて、セキュリティ業界の人々は関心を持ち、世界中のインターネットユーザーのセキュリティとプライバシーを向上させるための活動を始めました。

この問題を解決する唯一の方法は、すべてを暗号化することであり、それを後付けではなく必須条件とすることである、と考えたのです。これにより、新しい技術や規格の導入が促進され、安全であることがデフォルトで保証され、安全ではない古い方法を使用する目的でのダウングレードを防ぐことができました。

しかし、新しい技術や規格が登場しても、リスクがなくなるわけではありません。もし誰かがあなたのネットワーク接続に干渉することができれば、偽サイトにリダイレクトするだけで、あなたの個人情報を盗むことができます。これは MitM 攻撃 (machine-in-the-middle attack: 中間者攻撃) と呼ばれるもので、偽のDNS (Domain Name System) 応答を返したり、なりすまし Wi-Fi のアクセスポイントを操作したりすることで可能となります。あるいは ISP (インターネットサービスプロバイダー) や政府、法執行機関などが直接行うことも可能です。企業は、保護されたトラフィックを検査するために設計されたミドルボックスを使用して、TLS トラフィックを傍受することもできます。

問題の解決

たとえアクセス先のサイトが HTTPS を使用していても、Web ブラウザは通常デフォルトでHTTP (HyperText Transfer Protocol) を最初に試すため、安全でない HTTP 接続をリスンしてからユーザーを安全なサイトにリダイレクトする必要があります。

最初の接続を HTTPS で行うようにブラウザに指示するために、2012 年に Google は新しい HTTP ヘッダーを提案しました。それが HSTS (HTTP Strict Transport Security) です。この HTTP ヘッダーにより、Web サイト管理者は、自社の Web サイトが HTTPS でしか読み込まれないようにし、ブラウザが 80 番ポート の HTTP での接続を試みないようにすることができます。

もちろん、この場合でも、ブラウザが HSTS ヘッダーを確認する前に初めてサイトにアクセスしたときには、HTTP にダウングレードされる危険性があります。これは、SSL ストリッピングと呼ばれる MitM 攻撃の一種で、HSTS はそもそもこの攻撃への対策として設計されました。

この問題を解決するために、HSTS には「プリロード」オプションが追加されました。HSTS ヘッダーに追加された後、サイトを https://hstspreload.org に送信すると、Chrome、Firefox、Opera、Safari、Internet Explorer、および Edge 向けに、常に安全なサイトとして組み込まれます。

2013 年末、Google は、すべてのサイトに TLS 暗号化を導入するよう促すため、Chrome ブラウザが安全でない Web ページにアクセスした際に警告を表示し、暗号化されていないサイトを検索結果で下位に表示することを発表しました。

Google の方針とセキュリティコミュニティ全体の働きかけにより、わずか 3 年間で安全な接続をサポートするサイトの数は倍増しました。Google の統計によると、現在ほとんどの国で、Chrome ユーザーがアクセスするサイトは 95％ 以上の確率で暗号化されています。

暗号化された世界の実現を目指すブラウザベンダーの最新の動きは、2020 年 11 月に Mozilla がFirefox に HTTPS-Only モードを導入したことから始まりました。この機能を有効にすると、すべての接続を HTTPS で安全に行おうとし、HTTPS が利用できない場合には警告を表示するようになります。続いて Chrome も同様のオプションを追加し、2021 年 4 月には標準化しました。

これは素晴らしい成果ですが、暗号化率の高さはさておき、人々は HSTS のような技術を導入し、また、HSTS は信頼できないネットワーク上のユーザーを保護するのに十分なほど広く使用されているのでしょうか。

暗号化と HSTS の導入状況に関する調査

この調査を行うために、ソフォス製品の顧客がアクセスしたドメインのうち、SophosLabs にテレメトリを報告している上位 15,000 ドメインを調査することにしました。重複しているドメインや、127.0.01 や localhost などの無効なリンクは除外しました。その結果、合計で 13,390 個の有効な URI を評価することができました(生データはソフォスの GitHub ページで公開されています) 。

私は、サウザンアルバータ工科大学の IT (情報技術) セキュリティ専攻の学生である Kovan Mohammed Ameen と協力して、Python スクリプトを使用してURI で観測されたすべての HTTP ヘッダーをスクレイピングし、Kibana で分析するために NDJSON ファイルに保存しました。生データの結果それ自体が物語っていますが、常に悪魔は細部に宿るものです。.

収集されたデータのうち、1,483 件 (10.64%) のURI が HTTP によるものでした。これは、Mozilla と Let’s Encrypt が公開している、現在の HTTPS 採用率を示すデータと一致しています。12,448 件 (89.36%) の URI に HTTPS が使用されており、そのうち 3,947 件 (31.71%) に HSTS ヘッダーが設定されていました。

HTTP

一見すると、期待していたほどの効果は見られません。そもそも私は、2021 年には存在すべきでない HTTP のサイトを見て、この過去のプロトコルをいまだに使用しているものは何か、そしてそれがどのようなリスクをもたらすのかを確認したいと考えました。

昔の Flash や Java の時代には、エクスプロイトを発見して一斉に使用することが容易でしたが、最近ではエクスプロイトはそこまで見られず、プライバシーやデータの盗難が問題となっています。

1,483 件すべてを手作業でテストすることはできませんでしたが、リスト全体を目で見て確認し、また、普及率の高いものから順に上位 100 件を手作業で閲覧しました。

そのうち 14 件は、異なるドメインの HTTPS サイトにリダイレクトするインタースティシャルページでした。これは悪しき慣行であり、HSTS ヘッダーを適用することができず、誰かがそのドメインにアクセスするたびに HTTP セッションがハイジャックされてしまいます。新しいページにリダイレクトする前に、HSTS ヘッダーが設定された同じドメイン上の HTTPS ページにリダイレクトする方が良いでしょう。

また、上位 100 件には、少なくとも 50 の広告またはトラッキングのサイトが含まれていました。ドメインで正確に判断するのは難しいですが、半分以上はマーケティング業界のものだと確信しています。残りのページには、OS (オペレーティングシステム) メーカーがキャプティブポータル (パブリック Wi-Fi のログインページ) を利用しているかどうかや、コンピューターのネットワークが IPv6 (Internet Protocol Version 6) に対応しているかどうかをテストするページなど、予想通りのものが多く含まれていました。

HTTP サイトの上位 100 件では、膨大な数のトラッカー、ビーコン、アナリティクスが使用されていることや、暗号化を適切に実装する必要性を感じているサイトがないことを除けば、特に気になる調査結果はありませんでした。

HSTS を使用しない HTTPS

2 番目のグループ (HSTS を使用しない HTTPS) のサイトは、合計数が最も多い 8,501 でした。これらのサイトがなりすましを受けるには、いくつかの条件のいずれかを満たす必要があります。まず、攻撃者がダウングレード攻撃を行い、管理下にある暗号化されていない接続に被害者をリダイレクトすること。次に、攻撃者が認証局 (CA) に有効な証明書を発行させ、暗号化された接続でサイトになりすますこと。最後に、被害者がブラウザに表示される煩わしい警告をクリックして、偽造証明書で暗号化された攻撃者のサイトに接続するように仕向けることなどです。

これらの接続に侵入するために MitM の手法を使用することがまだ可能であることを考慮すると、銀行、電子メールプロバイダー、ソーシャルメディアサイト、ショッピングサイトなど、重要なログイン情報を扱うサイトがこのリストに含まれていないことを期待していました。

まず、上位 100 件までを調べてみました。上位 20 件のうち 14 件を広告、アナリティクス、コンテンツ配信ネットワーク (CDN) が占めています。下の表には、最も驚くべき異常値のリストを掲載しています。

これほど多くのセキュリティベンダーがランクインしていることに、私は驚きと落胆を隠せませんでした。また、Yahoo! Japan がこのリストに入っているのも残念でした。私の知る限り、他のすべての国の Yahoo は HSTS を使用していますが、日本では使用しておらず、Yahoo! Japan のサイトから Yahoo メールにログインするときでさえ使用していません。

重要なのは、サイトの一部、特にメインのランディングページ以外の部分に HSTS を導入するだけでは、HSTS を全く使用しないのと同じくらいの効果しかないということです。攻撃者はランディングページを侵害することができれば、「サインイン」リンクを元のサインインページとは異なる URL にリダイレクトするだけで、認証情報の収集を続けることができます。

このような挙動を示したサイトのほぼすべてが、サードパーティによる認証プロバイダーを使用していました。これは、そのサイト自体が HSTS を使用していなくても、指定されたプロバイダーが HSTS を使用していることを示しています。先ほども述べた通り、これは効果的な保護ではありませんが、認証プロバイダーが HSTS を使用することの価値を理解していることを示しています。

HSTS を導入しない理由として考えられるのは、Web サイトの運営者が HSTS について知らないか、サイトが暗号化されていない状態に戻ってしまうかもしれないと思っていることです。もう昔には戻れないのですから、より多くの Web 管理者にセキュリティを強化してもらえるように努力すべきです。私がデータを収集した時点 (2021 年 4 月) で HSTS を導入していなかったサイトの 5% 近くが、現在 (2021 年 11 月) は HSTS を導入しており、その中には hp.com のような大企業も含まれています。

HSTS を使用する HTTPS

安全なサイトに注意を向けることになぜ意味があるのでしょうか。

それは、すべてのサイトが正しく設定されているわけではないからです。HSTS には「max-age」と呼ばれる設定値があります。これは、サイトに接続する際に TLS のみを使用することを記憶する時間を、秒単位で Web ブラウザに伝えるためのものです。推奨値は 31,557,600 秒、つまり約 1 年です。

不思議なことに、HSTS ヘッダーを表示しているサイトの 4.86% は、max-age が 0 に設定されており、事実上無効になっていました。なぜそんなことをする企業があるのでしょうか。この数少ない企業リストの中には、oracle.com をはじめとする非常に大きな企業の名前が含まれていました。私はこの企業リストを徹底的に調べ、個人的に知り合いがいるセキュリティ企業を 2 社見つけました。

なぜこのような設定にしているのかを問い合わせたところ、どちらからも同じような答えが返ってきました。それは、Web サイトの開発時の古い設定のままとなっており、本番環境に移行する際に変更されることになっていた、とのことでした。セキュリティ証明書を更新しなくてもテストができるように、HSTS を無効にしていたところ、その設定を元に戻すのを忘れていたのです。

これは同様の設定をしている多くのサイトに当てはまる可能性があります。開発環境から本番環境への移行時に発生する問題は新しいものではなく、時折セキュリティの設定ミスやデータ漏洩の問題を引き起こします。すべての Web 管理者は、開発環境から本番環境に移行するときだけでなく、定期的にすべてのセキュリティ設定を見直すことが重要です。なぜなら、何が「十分」であるかという基準は改善され続け、ベストプラクティスは時間とともに進化するからです。

結論

Web の安全性はかつてないほど高まっています。

95% の Web ページが暗号化されており、暗号化されていないページもそこまでのリスクはないため、特にオンラインショッピングの繁忙期には、喜ばしいニュースと言えるでしょう。

セキュリティコミュニティは、少しずつ基準を改善し、遅れている企業にプレッシャーをかけ、インターネット上で安全に通信するためのコストを削減してきました。かつての問題の規模がいかに大きかったかを考えると、これまでの進歩は目覚ましいものがあります。

しかし、決して完璧とは言えません。HSTS を採用しているサイトは 31.6％ にとどまっており、無料で利用できて、セキュリティを大幅に向上させることができる機能であっても、必要な基準に達するほど広く普及していないことを示しています。

アプリケーション層のセキュリティを確保することは、ユーザーや安全性に大きな影響を与えます。私たちが利用しているネットワークのプロバイダーが私たちをスパイしたり、広告ネットワークに私たちの情報を売ったり、サイバー犯罪者に侵害されたりする危険性は依然としてあります。

しかし、HSTS と TLS のおかげで、信頼できない Wi-Fi やモバイルネットワーク上であっても、トラブルにつながるリスクを気にせず、自由に閲覧したり通信したりすることが可能となっています。