プロフィール
Research
Research のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。
ケースファイル
同じ 256 でも、同じ記録ではない：IPFIX の観測ドメインが定める証拠の範囲
接続が戻り、収集装置に再び 256 という番号が届く。前の接続で覚えた項目の並びを当てはめれば、数字は読めるかもしれない。しかし再接続の前後で、その番号が指す定義まで同じとは限らない。障害は通信の停止ではなく、意味の連続性を勝手に仮定した瞬間に始まる。
ケースファイル
TXT レコードは正しかった。それでも委託先はドメインではない――ACME DNS-01 と委任された検証権限
アプリ、CI、社員アカウント、証明書保管庫から委託先を外した企業が、契約終了を完了扱いにした。だが DNS には `_acme-challenge` を委託先の検証ゾーンへ送る委任が残っていた。委託先の ACME アカウントが新しいワイルドカード証明書を注文すると、正しい TXT ダイジェストが現れ、プロトコル上の検査はすべて成功した。壊れていたのは ACME ではなく、DNS まで届かなかった権限棚卸しだった。
ケースファイル
境界を越えたのは1経路、消えるのはセッション：BGP maximum-prefix の統治
BGP の maximum-prefix は、受信する経路数に上限を置くための機能である。しかし、設定された動作がセッション切断なら、上限を越えた1経路だけでなく、それ以前に同じ隣接から学習していた経路も同時に失われる。必要なのは大きな数字ではなく、数え方、守る資源、正当な増加、切断後の到達性まで説明できる境界である。
ケースファイル
DNS 応答が Secure でも、接続先はまだ選ばれていない：SSHFP 指紋の権限境界
運用担当者は `ssh db` と入力した。ネットワーク由来の検索サフィックスが短い名前を別の完全修飾名へ展開した。その SSHFP は DNSSEC Secure、提示されたホスト鍵の指紋も一致した。証明はすべて正しかった。ただし、利用者が意図したデータベースではなく、クライアントが選んだホストについてである。
ケースファイル
署名は通った。それでも From は署名者ではない――DKIM ドメイン署名の権限
画面の From ドメインには `bank.example`、判定には DKIM pass と出た。実際に署名したのは攻撃者の `receipt-alert.example` だった。検証は正しい。一つのドメインの証拠を別の名前へ移した判断が誤っていた。
ケースファイル
ダイジェストは一致した。それでも送信者は不明だった――HTTP `Content-Digest` が持つ権限の限界
設定ファイルは通信中に壊れたのではない。最初から有害で、しかも正しく計算された `Content-Digest` が付いていた。サービスは「検証済み」と表示し、そのまま変更を適用した。攻撃者はハッシュ関数を破っていない。本文とダイジェストの両方を自分で用意しただけだ。
ケースファイル
ヘッダーはクライアントを名乗った。接続元は同意しなかった：HTTP `Forwarded` とプロキシ連鎖の権限
本来は二段のリバースプロキシだけが到達できるオリジンに、外部から直接接続できる経路が残っていた。送信者は管理用許可リストのアドレスを `X-Forwarded-For` の左端に置き、IP 制御を通過した。文字列の解析は成功していた。失敗したのは、その接続元に過去の通信経路を証言する権限がなかったことである。
ケースファイル
TLSコンテキストを選んだ名前に、要求を許可する権限はない：SNIという経路ヒント
障害ではなく、成功ログが問題を隠した。ClientHello の`tenant-a.example`から意図した証明書が選ばれ、TLS 1.3も完了した。ところが認可層は、その選択ラベルを利用者の tenant ID として受け取った。クライアントはまだ何者とも確認されていなかった。
ケースファイル
証明書署名は通った。それでも握手は終わっていない：TLS 1.3 `Finished` の証拠境界
監視基盤は、サーバーの CertificateVerify 検証が成功した瞬間に「認証済み接続」を一件加算した。直後の`Finished`は不正で、クライアントは`decrypt_error`として接続を終了した。署名が証明した内容は正しかった。誤っていたのは、その証明にまだ到達していない完了状態まで背負わせた運用側だった。
インターネット史
返り道を証明したトークン――DNS Cookiesが身元証明ではない理由
EDNS に加わった小さなオプションは、DNS サーバーが UDP の送信元アドレスから読み取れる事実を一つ増やした。送信者が誰かではない。その見かけ上のアドレスへ以前送った応答を誰かが受け取り、サーバー発行のトークンを持ち帰った、という限定された事実である。
IETF
パケットは失われる前に印を受けた――ECNが問い続けた輻輳の知らせ方
インターネットは長いあいだ、損失を輻輳の証拠としてきた。キューがあふれ、パケットが届かず、送信側が速度を落とす。Explicit Congestion Notification（ECN）は、その順序を変えた。パケットを壊さずに警告を載せられるようにしたのである。ただし、2ビットが意味を持つには、キュー、受信側、トンネル、送信側が同じ約束を守らなければならない。
ケースファイル
エッジは HTTP/2、オリジンは HTTP/1.1：TLS ALPN が決められるのは一つの接続だけ
ブラウザーは `h2` と `http/1.1` を提示し、エッジは `h2` を選んだ。TLS は完了し、HTTP/2 のフレームも正しく流れた。それを根拠に資産台帳がオリジンを「HTTP/2 ネイティブ」と記録した瞬間、正しい観測は誤った主張になった。エッジは TLS を終端し、別の接続でオリジンへ HTTP/1.1 を送っていたからだ。
ケースファイル
CA 名は載っていた。それでも主体は許可されない：TLS `certificate_authorities` が持つ選択ヒントの権限
サーバーが示した CA 名に合うため、クライアントはある証明書を選んだ。サーバー側のパス検証も成功した。しかしサービスは、その主体が対象テナントに登録されていないとして操作を拒んだ。暗号処理は壊れていない。壊れていたのは、CA 名の一致をアクセス許可まで引き上げた運用上の意味づけだった。
ケースファイル
署名は正しくても、状態は古い：TLS OCSP ステープリングとキャッシュ回答の権限
10時07分に証明書が失効した。ところが10時11分の TLS 接続には、数時間先の `nextUpdate` を持つ署名済みの `good` 応答が添付されていた。改ざんではない。正規の応答が、定められた時間枠の中で現実に遅れたのである。障害を深めたのは、その違いを `revocation_checked=true` という一つの緑色表示に潰した運用だった。
ケースファイル
ソケットは閉じた。取引は終わっていない：TLS `close_notify`が持つ終了権限
決済クライアントには成功応答が届き、TLS 接続も正常終了に見えた。だがサーバー側のデータベースには結果が残っていなかった。`close_notify`が偽物だったのではない。サーバーがその方向で TLS メッセージをもう送らないことを正しく示しただけで、取引の永続化までは語っていなかった。接続の事実に業務判断を代行させたことが、障害の出発点だった。
ケースファイル
チケットは残った。セッションは残らなかった：TLS 1.3再開と持ち越し状態の権限境界
地域フェイルオーバー後のノードは、管理権限が取り消される前に発行された TLS 1.3チケットを受理した。暗号学的な検証は正しかった。クライアントは再開 PSK を知り、binder は新しい ClientHello を認証した。しかし、その証明のどこにも、古い権限が今も有効だとは書かれていなかった。
ケースファイル
レコードが長くても、メッセージが長いとは限らない：TLS 1.3パディングと観測長の権限境界
インシデント報告は、暗号化レコードの512バイト差をそのままリクエスト本文の差とみなし、利用者の操作まで特定した。計測値は正しかったが、意味づけが一層深すぎた。送信プロセスは TLS 1.3レコードを一定幅にそろえ、本文なしの Application Data も送れた。パケットから分かるのは保護後の長さであり、パディング前のアプリケーション長ではない。
ケースファイル
最初のHelloは退けられたが、消されてはいない：TLS HelloRetryRequestと記録の権限
調査用のキャプチャは二度目の ClientHello から始まっていた。鍵共有は一つだけで、サーバーはそれを受け入れ、ハンドシェイクも完了している。この断片だけなら、クライアントが初めからそのグループを選んだように見える。しかし最初のフライトでは別の予測が送られていた。TLS がそのハッシュを後続の記録へ残すのは、再試行を履歴の書き換えにしないためである。
ケースファイル
証明書を待つ接続に鍵だけが通った：TLS Raw Public Keyと検証権限の境界
暗号鍵が本物であることと、その鍵を受け入れる規則が正しいことは別である。wolfSSL が2026年に修正したのは、まさに後者だった。RPK 対応ビルドで、交渉されていない Raw Public Key が X.509 証明書の代わりに受理され、証明書チェーン検証を通らずに済む場合があった。交渉はデータ形式の案内ではない。どの信頼手続に決定権を与えるかを定めている。
NPNOG
同じ技術週間、異なる責任線――npNOG と SANOG-38 の記録
<!-- BTW:SLUG:hitotsu-no-shukan-futatsu-no-soshiki-futatsu-no-kaisu-npnog-sanog-38 -->