Let's Encryptを発表して以来、フィッシングやマルウェアサイトに証明書を発行しないようにどのようにするのかという質問をよく受けてきました。最もよく表明される懸念は、有効なHTTPS証明書を持つことで、これらのサイトがより正当に見え、人々がそれらを信頼しやすくなるということです。

ここで何をするかを決定するのは困難でした。一方で、私たちは他の誰よりもこれらのサイトを嫌っていますし、私たちの使命はより安全でセキュアなウェブを構築することです。他方で、証明書の発行（少なくともドメイン認証の場合）が、2015年にフィッシングやマルウェアサイトを監視する適切なレベルであるかは確信がありません。この投稿では、これらの悪意のあるサイトとの戦いにおける認証局エコシステムの役割についての会話を促すために、私たちの考えを説明します。

認証局はコンテンツ監視役として不向き

Let's Encryptはドメイン認証（DV）証明書を発行する予定です。技術的なレベルでは、DV証明書は公開鍵がドメインに属することを表明するだけで、サイトのコンテンツや誰が運営しているかについては何も述べていません。DV証明書には、ウェブサイトの評判、現実世界のアイデンティティ、安全性に関する情報は含まれていません。しかし、多くの人々は、DV証明書の存在そのものが、少なくともこれらのことのいくつかを意味するはずだと信じています。

DV証明書をサイトのコンテンツに対する一種の「承認印」として扱うことは、いくつかの理由で問題があります。

まず、認証局は、フィッシングやマルウェア対策の活動、またはより一般的にコンテンツを監視するのに適した立場にありません。認証局は、サイトのコンテンツに対する十分な継続的な可視性を持っていないからです。最高の認証局ができるのは、マイクロソフトやグーグルのような、コンテンツの認識がはるかに高い組織に確認することです。グーグルとマイクロソフトは、大規模なクロールおよびレポートインフラストラクチャからウェブに関する膨大な量のデータを消費します。このデータにより、複雑な機械学習アルゴリズム（数十人のスタッフによって開発および運用）を使用して、悪意のあるサイトやコンテンツを特定できます。

たとえ認証局が優れたAPIでフィッシングやマルウェアのステータスをチェックしたとしても、フィッシングやマルウェアに関する情報を正確に表現する能力は非常に限られています。サイトのコンテンツは証明書の発行と失効サイクルよりもはるかに速く変化する可能性があり、フィッシングやマルウェアのステータスはページ固有である可能性があり、証明書とその関連するブラウザUIには、フィッシングやマルウェアのステータスに関する情報がほとんど、またはまったく含まれていません。認証局がフィッシングやマルウェアコンテンツを含むサイトの証明書を発行しない場合、ユーザーはロックアイコンを表示しなくなります。ユーザーは、ブラウザにフィッシング対策機能とマルウェア対策機能が含まれている場合に、より多くの情報が得られ、保護されます。これらの機能は、通常、これらの制限のいずれにも悩まされません。

DV証明書をサイトのコンテンツに対する「承認印」として扱うことに関するもう1つの問題は、主要なブラウザによって信頼されている数千の認証局全体で強制が不整合であるため、価値の高いドメインの単純なブラックリストを超えて、認証局のフィッシング対策およびマルウェア対策の基準がないことです。たとえ1つの認証局が悪質なサイトを排除するために並外れた措置を講じたとしても、攻撃者は単に異なる認証局を物色することができます。悪者はほとんどの場合、証明書を取得し、人々を搾取するのに十分な長さの間保持することができます。最高の認証局のフィッシング対策およびマルウェア対策プログラムがどれほど洗練されていても、最も悪いプログラムがどれほど優れているかだけが重要です。これは「最も弱いリンクを見つける」というシナリオであり、弱いリンクは見つけにくいものではありません。

ブラウザメーカーはこれらすべてを理解しています。そのため、彼らはフィッシング対策機能とマルウェア対策機能を推進し、証明書が実際に主張している内容をより正確に反映するようにUIを進化させています。

TLSはもはやオプションではない

1990年代に最初に開発されたとき、HTTPSとSSL/TLSは、オンラインバンキングやクレジットカードを受け入れるショッピングサイトのような特定の種類のウェブサイトでのみ必要または有用な「特別な」保護と見なされていました。それ以来、HTTPSはほぼすべてのウェブサイトにとって重要であることがわかりました。パスワードでログインできるウェブサイト、何らかの方法でユーザーを追跡するウェブサイト、コンテンツの改ざんを望まないウェブサイト、および人々が消費していることを他人に知られたくないコンテンツを提供するサイトにとって重要です。また、HTTPSで保護されていないサイトは他のサイトを攻撃するために使用できることも学びました。

TLSはもはや例外ではなく、そうあるべきでもありません。それが私たちがLet's Encryptを構築した理由です。TLSをウェブ上の通信のデフォルトの方法にしたいと考えています。TCPやHTTPのように、ファブリックの基本的な一部になるはずです。これが起こると、証明書を持つことは付加価値ではなく、実存的な問題になり、コンテンツの監視ミスは特にコストがかかります。技術的なレベルでは、ミスは発行と失効サイクルの遅さや、HSTSのような機能が原因で、重大なダウンタイムにつながります。哲学的および道徳的なレベルでは、ミス（無邪気であるか否かにかかわらず）は検閲を意味します。認証局はオンラインでの言論と存在のゲートキーパーになるからです。これはおそらく認証局にとって良い役割ではありません。

私たちの計画

少なくとも当面の間、Let's Encryptは証明書を発行する前にGoogle Safe Browsing APIでチェックし、フィッシングサイトまたはマルウェアサイトとしてフラグが立てられているサイトへの発行を拒否します。GoogleのAPIは、私たちがアクセスできるフィッシングおよびマルウェアステータス情報の最適なソースであり、発行前にこのAPIをクエリする以上のことを試みることは、ほぼ確実に無駄で非効率的でしょう。（更新：2019年1月10日現在、Safe Browsing APIに対してドメインをチェックすることはなくなりました。）

DV証明書の場合でも、多くの人々が認証局がフィッシング対策およびマルウェア対策の取り組みを完全に放棄することにまだ満足していないため、このフィッシングおよびマルウェアステータスのチェックを実施するつもりです。私たちは、多くの人々が重要であると認識している認証局の行動を放棄する前に、もう少し会話を続けたいと考えています。たとえ私たちが同意しないとしても。

結論

フィッシングやマルウェアコンテンツとの戦いは重要なものですが、少なくともDV証明書に関しては、認証局が最前線に立つことは理にかなっていません。そうは言っても、会話を続ける間、Google Safe Browsing APIに対するチェックを実施する予定です。

皆様のご意見をお待ちしております。お知らせください。