Scribble at 2026-07-09 18:57:19 Last modified: unmodified

ブログ記事の筆者が言うには、ウェブの「エンド・ツー・エンドの暗号化」というものは、実は成立しない。これは、たとえば HTTPS プロトコルの通信などが該当する。既に SSL 証明書を利用する常時 HTTPS 化が普及して久しく、サイトに導入できないのは無知か無能の証拠でしかないとすら言われているが、果たしてそうなのかというわけだ。筆者がエンド・ツー・エンドの暗号化を疑う理由は、暗号を実装するクライアント側のコードを配布するのはサーバ運営側だからだ。つまり、サーバ側が悪意を持てば、暗号化を破る JavaScript コードをいつでも配布できる。ゆえに、ウェブ・サーバの運営側が悪意をもつ場合の想定ができていない以上、そのような暗号化に整合性はないというわけだ。そして、これはデスクトップのアプリケーションで使われている暗号化された通信にも言える。たとえば、Adobe Creative Cloud はユーザのパソコンに Node.js というツールをインストールして、パソコン側から勝手に Adobe のサーバに向けて情報を送信している。彼らは認証情報や動作の安定性にかかわる情報を収集したり通信しているというが、Adobe のエンジニアに悪意があれば、アップデートでマルウェアを正規のプログラムとして配布することは可能であり、Node.js は事実上のバックドアとなる。Adobe Creative Cloud を利用しながら、このようなリスクを防ぐ方法はない。つまり正規の Adobe Creative Cloud の認証情報が格納されたデータ領域（ペイロード）に僕らのプライバシー情報などをどさくさで追加されても、そういう不正な通信を防ぐ方法はないのだ。

したがって、企業（その典型は、Let's Encrypt を普及させた Google などだ）が SSL による暗号化通信を普及させたい理由は、実は通信データの保護などではなく、「暗号化しているから解読できない」という弁解を可能にすることで、政府などからの通信内容に関する要求へ対応するコストを減らしたり回避したいということなのである。したがって、「常時 SSL」は「セキュリティ劇場（security theatre）」あるいは「安全の茶番劇」と呼ばれるものの一つでしかない。実際、かつて FBI は Apple に対して通信内容を監視できるような iOS を作るように要求したが、Apple は拒否しただけである。これはつまり、作ろうと思えば作れるという意味であって、Apple 側が対応を変えれば通信内容なんていくらでも監視可能なフォーマットにできるのだ。

では、どうすれば僕らの通信内容は守れるだろうか。送出される通信データの安全性を測るには、まず送信データの内容を事前に暗号化される前の状態でサード・パーティのプログラムがフックできなくてはいけないが、これはどう考えてもアプリケーションの利用規約に違反するだろう。したがって、暗号化の仕組みをアプリケーションに実装して企業側がユーザのパソコンへインストールさせている限り、ここで説明しているようなリスクを回避することは不可能である。

この主張について、たとえば Hacker News ではおおむね同意しながらも、やはり企業側でそのように悪意のあるコードを仕込むことは難しい（必ず内部通報者が出てくるし、もし明るみになれば途方もない金額の集団訴訟に負ける）ということと、企業側の悪意というリスクを脇に置けば、やはり言い訳でも何でも政府や警察からの要求を撥ね付ける理由になっているのだから、暗号化通信には一定の意味があるという反論がある。

ただ、やはり企業を信頼してよいかどうかという議論の出発点は、きちんと一定の方針をもっておく方が望ましいと思う。僕が、「パーソナル ISMS」というアイデアをここで何度か提案したのも、この手のリテラシーは家計を守るために無駄遣いしないといったことに匹敵する、家庭や個人の生活態度にまで普及させた方がいいと思うからだ。