フィッシング詐欺やマルウェアとの戦いにおける認証局の役割

Let's Encrypt を発表してから、私たちはよく、「どうやってフィッシング詐欺サイトやマルウェア配布サイトにSSL/TLSサーバ証明書を発行しないことを保証しているのか」と尋ねられます。

最もよくあるのは、「フィッシング詐欺サイトやマルウェア配布サイトが有効な HTTPS 証明書を持ってしまうと、それらのサイトがより正当なサイトに見えてしまい、それらのサイトを信用してしまう人々が増えてしまうのではないか」という懸念です。

この問題についての方針を決めることは、とても困難です。

一方で、私たちはフィッシング詐欺サイトやマルウェア配布サイトを他の誰よりも嫌っており、私たちの使命はより安全で安心できるWebの構築を助けることだと考えています。

しかしもう一方では、2015年現在の段階において、私たちが（フィッシング詐欺サイトやマルウェア配布サイトに対しても、他のWebサイトに対してと同じように）SSL/TLS証明書を発行することが（少なくともドメイン認証のみを行うDV証明書の発行である場合）、正しいことであるかどうかについて、いまひとつ確信が持てずにいます。

この記事では、悪質なサイトとの戦いにおける認証局エコシステムの役割についての議論を促進するために、私たちの考えを説明していきます。

Let's Encrypt は、ドメイン認証（DV）証明書を発行しています。

技術的な観点からすると、DV証明書は公開鍵がそのドメインに属することを明白にしているに過ぎず、サイトのコンテンツの内容や運営者が誰であるかについては一切言及していません。DV証明書には、Webサイトの評価・現実世界における身元・安全性に関する情報は一切含まれていないのです。

しかし、多くの人たちは、DV証明書という存在に、Webサイトの評価・現実世界における身元・安全性に関する情報のうちの少なくとも一部を含めるべきであると考えています。

DV証明書をWebサイトのコンテンツに対する「承認シール」の一種として扱ってしまうと、複数の問題が生じます。

認証局は、アンチフィッシングやアンチマルウェアの働きをしたり、広くコンテンツを取り締まったりする立場にありません。認証局には、Webサイトのコンテンツを継続してチェックする能力がないのです。

それが可能な認証局は、大量のコンテンツを扱っている組織（Microsoft や Google など）と協力して、コンテンツのチェックを行っています。Google と Microsoft は、大規模なクロールや報告の受け取り基盤により、Webに関する膨大なデータを処理しています。これらのデータは、複雑な機械学習アルゴリズム（沢山のスタッフが開発・運営）を、悪意のあるサイトやコンテンツの識別に使用することを可能とします。

たとえ、認証局が、フィッシング詐欺やマルウェアを含むWebサイトかどうかを良い API でチェックしたとしても、フィッシング詐欺やマルウェアについての情報を正確に提供することは困難です。また、Webサイトのコンテンツは、証明書の発行と失効のサイクルよりも速く変更することが可能です。

Webページ固有のフィッシング詐欺やマルウェアの有無に関するステータスの表示機能は、ブラウザのUIに組み込まれています。認証局がフィッシング詐欺やマルウェアを含むWebサイトに証明書を提供しない場合であっても、ユーザーからするとそれらのWebサイトで「錠アイコン」を見ることがなくなるだけですが、Webブラウザに搭載されているフィッシング詐欺対策機能やマルウェア対策機能ならば、認証局が悪意のあるサイトへの対策を行う場合のような制約を受けることがないので、ユーザーはより良い説明と保護を受けることができます。

DV証明書をWebサイトコンテンツの「承認シール」として扱うことについての他の問題点は、ドメインを単純にブラックリスト化したものより優れている、認証局がフィッシング詐欺対策やマルウェア対策をおこなう上での標準規格が存在しないことです。そのため、悪意のあるサイトへの対策を、主要なWebブラウザが信頼している数多くの認証局の間で、一貫性をもっておこなうことができません。たとえ認証局の1つが悪いWebサイトを除去するために特別な処置を講じたとしても、悪意のある人物は他の認証局を使用することができてしまいます。悪意のある人物は、ほとんどの場合、証明書を入手して、悪用をおこなうのに十分な期間証明書を保持できてしまうでしょう。

つまり、最高のフィッシング詐欺対策プログラムやマルウェア対策プログラムを認証局が用いるか否かといった洗練された問題ではなく、単に何が良くて何が最悪であるかという問題です。これは悪意のある人物が「最も脆弱な経路」を見つけるシナリオであって、その「脆弱な経路」を見つけ出すことは困難ではないのです。

Webブラウザの制作者は、これらを完璧に実現しています。これが、フィッシング詐欺・マルウェア対策機能をプッシュする理由で、証明書が確実に作られるように、その UI をよりよくしていきます。

最初に開発された1990年代には、HTTPS と SSL/TLS は、一般に、オンラインバンキングやクレジットカードを受け入れるショッピングサイトなどの特定の種類のWebサイトでのみ特に必要・有益な「特別」な保護であると考えられていました。

私たちは、それ以来、HTTPS はほぼ全てのWebサイトにとって重要であると考えてきました。何故ならば、パスワードによるログインを受け付ける全てのサイト、ユーザーをトラッキングしている (英文) 全てのサイト、コンテンツを改ざんされたくない (英文) 全てのサイト、他の人に閲覧していることを知られたくない全てのサイトにとって、HTTPS と SSL/TLS は重要だからです。また、HTTPS によるセキュリティが確保されていない全てのWebサイトは、他のWebサイトを攻撃する目的 (英文) で使用できてしまいます。

TLS はもはや 特別なものではなく (英文)、使った方がよいという程度のものでもありません (英文)。これが、私たちが Let's Encrypt を築き上げた理由です。私たちは、TLS が Web における通信のデフォルトのメソッドになることを望んでいます。TCP や HTTP のように、骨組みの土台となるべきです。

そうなると、証明書を持つということが付加価値ではなく存在の問題となり、コンテンツの警護ミス発生時に、特にコストがかかることになります。技術的なレベルでは、発行・取り消しのサイクルの遅延や HSTS のような機能に関わるミスが、大きなダウンタイムを生んでしまいます。

哲学的な観点・道徳的な観点からすると、認証局がネット上の言論や存在の門番となるため、認証局のミス（悪意のないミスやそれ以外のミス）が検閲となってしまいます。

これは、おそらく、認証局の役割としては適切ではありません。

少なくとも当分の間、Let's Encrypt は証明書の発行前に Google セーフブラウジング API を用いてチェックをおこなうことで、フィッシング詐欺サイトやマルウェア配布サイトのフラグが立っているWebサイトへの証明書の発行を拒否します。Google の API は、私たちがアクセスできる中では最も良いフィッシング詐欺サイトやマルウェア配布サイトに関する情報源なので、Google の API を用いる以外の試みをおこなったとしても、ほぼ確実に無駄となり効果が得られないでしょう。

私たちが、フィッシング詐欺サイトやマルウェア配布サイトであるかどうかのステータスをチェックするのは、DV証明書の場合でさえ、認証局が完全にアンチフィッシングとアンチマルウェアの努力を放棄することに、多くの人たちがまだ慣れていないからです。

私たちは、たとえ意見が一致しなかったとしても、多くの人たちが認証局の重要な振る舞いとして理解していることを置き去りにしてしまわないように、少し時間をかけて話し合いを続けていこうと思います。

フィッシング詐欺やマルウェアを含むコンテンツとの戦いは重要ですが、少なくともDV証明書であるならば、認証局が前線に立つべきではありません。

とはいっても、私たちは、話し合いを続けていきながら、 Google セーフブラウジング API に対する調査を実施していくつもりです。

私たちは、あなたのご意見をお待ちしております。是非ともご意見をお聞かせください (英文)。