0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Let’s Encryptが検証点を7回に増やす理由を、BGP攻撃の入口から追う

0
Posted at

1枚の証明書に、なぜそこまで厳重なのか

画像: cabforum.org より
画像: cabforum.org より

画像: letsencrypt.org より
画像: letsencrypt.org より

HTTPS の証明書は、ただ「このドメインは私のものです」と言う紙切れではない。ブラウザが相手先を信じてよいかを決める、Web PKI の入口そのものだ。だから発行前には、申請者が本当にそのドメインを制御しているかを確かめる。Let’s Encrypt の通常のやり方は、申請者に特定のファイルやトークンを決められた場所へ置かせ、それを CA 側が取りに行く、というものだ。

この仕組みは一見単純だが、ネットワークの途中で通信を横取りできる相手がいると崩れる。ドメインの所有者ではない第三者が、検証リクエストを別の場所へ誘導できれば、CA は「正しい持ち主が応答した」と誤認してしまう。2020 年の Let’s Encrypt の解説では、この種の攻撃は BGP を使った経路ハイジャックで起こりうると説明されている。BGP はインターネットの経路制御の基盤だが、すべての実装が強固というわけではない。RPKI や BGPsec のような防御策は進んでいるものの、そこに完全に頼れる時期がいつ来るかは分からない。Let’s Encrypt が「BGP が完全に安全になるのを待たない」と書いているのは、その不確実さを前提にしているからだ。

1か所で見ると、だまされる余地が残る

そこで出てきたのが、複数の視点から同時に確認するという発想だ。2020 年のブログでは、単一のネットワーク視点ではなく、複数の視点と自前のデータセンターから検証することで、攻撃者は同時に複数の経路をすり抜ける必要が出る、と説明されている。この時点では、主系 1 か所と複数の遠隔視点を合わせる構成だった。攻撃者に必要なのは、たまたま 1 本の経路を奪うことではなく、同じ瞬間に複数の経路を支配することになる。難易度が一段ではなく何段も上がる。

CA/B Forum でもこの考え方は制度側に取り込まれた。2024 年の Ballot SC067v3 では、Multi-Perspective Issuance Corroboration、つまり複数の Network Perspectives から domain validation と CAA check を行うことを、Baseline Requirements に入れる提案が進んでいる。背景には、BGP ハイジャックで検証をだまし、悪意ある証明書を得たとされる公開事例がある。Forum の文面はかなり率直で、ローカルな、しかも同じくらい具体的な prefix 攻撃は今なお Web PKI にとって重大な脅威だとしている。大げさな理屈ではなく、実際に HTTPS のなりすましへつながる経路がある、という認識だ。

Let’s Encrypt が受ける新しい制約

今回の Let’s Encrypt の更新は、その制度変更に合わせたものだ。コミュニティ投稿では、ドメイン検証のために新しい remote perspectives を 2 つ追加し、検証の安全性を高めると説明している。文中では、BGP attacks に対する可視性と保護を改善する、とも書かれている。しかも今回の変更で、検証要求の総数は 7 回になる。内訳は、primary datacenter から 1 回、remote perspectives から 6 回だ。以前は 4 回だったので、単なる増員ではなく、検証の立て方そのものが変わる。

この数字は地味に見えるが、運用の意味は重い。検証が 1 回増えるたび、単純にネットワーク往復が増えるだけではない。どの経路から見ても同じ応答が見えることが前提になるため、経路の偏りや地域差、途中の干渉に対して余地を小さくする。Let’s Encrypt は「ユーザーへの影響はほとんどないだろう」としている一方で、裏では失敗条件がより厳しくなる。primary server と remote perspectives の quorum が正しい challenge response を受け取らなければ発行できないからだ。

ここで気になるのは、なぜ 7 回なのかという点だ。2020 年の説明では、攻撃者は primary path と少なくとも 2 つの remote paths を同時に侵害しなければならないとされていた。では、2026 年の 7 回構成では何本の経路をどう見ているのか。CA/B Forum の要件は「少なくとも 5 つの remote Network Perspectives」を求め、しかもそれらが少なくとも 2 つの異なる Regional Internet Registries のサービス領域にまたがる必要があると書いている。Let’s Encrypt はこの基準に合わせて視点数を増やすわけだが、実際にどの視点をどう選び、どの quorum を満たすと成功になるのか、その内訳はまだ別の話になる。

どこまでが公開され、どこからがまだ先なのか

面白いのは、公式 FAQ が「どこから接続しているのかは変わる」と明言している点だ。Let’s Encrypt の検証地点は固定ではなく、時期によって変化する。2024 年の FAQ では、過去に 4 だった時期、3 に下がった時期、5 に戻った時期が説明されている。つまり、国名や IP レンジを前提にした防御や geoblocking は長続きしない。検証地点が動くなら、それに合わせて防御も組み替わるからだ。

そして今回の変更は、2026 年 10 月 27 日に staging で始まり、2026 年 11 月 10 日に production rollout する予定とされている。ここまでで見えてくるのは、検証地点の追加が単なるインフラ増強ではなく、BGP を前提にした発行プロセス全体の再設計だということだ。1 枚の証明書を出すために、なぜそこまで多くの視点が必要なのか。その答えは、攻撃者が狙うのが証明書そのものではなく、検証の視界だからだ。では、その 7 回の検証が実際にはどのように quorum を作り、どこまでの攻撃を弾けて、どこから先はまだ苦しいのか。ここから先が本番になる。

👉 続き(核心はここから)は PaPoo で読めます: https://papoo.work/doc/f422b8fc3e946e90

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?