2023-06-27

HTTPのキャッシュをグループ化する HTTP Cache Groups の仕様

HTTP internet-draft

『HTTP Cache Groups』という提案仕様がIETFに提出されています。これは、HTTPキャッシュをグループ化し、グループの単位で無効化や再検証を行えるようにする提案です。

Webサイトで利用する複数のJavaScriptやCSSファイルはデプロイすることがあるため、それらのキャッシュの管理をグループで扱うことはメリットがあります。例えばグループ内の一つのキャッシュを再検証(Revalidation)することで、グループ内のほかのリソースも再検証したものとして扱えるようになります。

またCDNのレイヤにおいて、キャッシュの無効化(Invalidation)・パージもグループで行えるのは管理上都合が良いでしょう。

Cache-Groups レスポンスヘッダ

レスポンスにおいてCache-Groupsヘッダでグループを指定できます。
Cache-GroupsヘッダはStructured Field Values 形式のリストです。下記は"ExampleJS", "scripts"グループに所属しています。

また、ExampleJSグループはrevalidateを共有することを示しています。

HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "ExampleJS";revalidate, "scripts"

Cache-Group-Invalidation レスポンスヘッダ

あるリクエストに応じて特定のグループのキャッシュを無効化 (Invalidation)を指示するのに、Cache-Group-Invalidation レスポンスヘッダが使えます。

下記はCache-Group-Invalidationヘッダで、"eurovision-results", "kylie-minogue"グループのキャッシュを無効化します

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "kylie-minogue"

2023-06-26

HTTPのキャッシュを無効化するAPIの標準化する提案仕様

HTTP internet-draft 雑

CDNはキャッシュをパージする機能をよく有しています。そのキャッシュの無効化(もしくはパージ)を要求するためのAPIを標準化するための『An HTTP Cache Invalidation API』という提案仕様がIETFに提出されています。

この提案仕様は、HTTP界隈では著名な Mark Nottingham氏による提案です。まだ最初の提案であり、来月あるIETF会合で紹介があるものと思われる。

An HTTP Cache Invalidation API

この仕様では、次のペイロードを含むPOSTを送ることで、キャッシュの無効化を要求できる

{
    "type": "uri",
    "selectors": [
      "https://example.com/foo/bar",
      "https://example.com/foo/bar/baz"
    ],
    "purge": true
}

type: uri, uri-prefix, origin, group が指定できる
- uri: 一致したURI
- uri-prefix: 前方一致したURI
- origin: 一致したオリジン
- group: キャッシュに指定されたグループ (別の仕様でgroupの仕組みが定義されるHTTP Cache Groups)
selectors: typeに合わせたキャッシュをパージするリソースの指定
purge: trueの場合無効化するだけでなくキャッシュが削除される

レスポンス

上記の無効化要求に対して次のステータスコードでの応答がありえます

200 OK: キャッシュの無効化(パージ)が完了した
202 Accepted: 要求を受け付けた。直にキャッシュの無効化(パージ)が完了する
501 Not Implemented: 要求された指示 (typeやpurgeの指定)をサポートしてない

おまけ

typeのところで説明した、groupについては追加で記事を書いときました
asnokaze.hatenablog.com

2023-06-12

新しいメディア転送プロトコル Media over QUIC Transport について

QUIC internet-draft

QUIC上でライブメディアなどを扱うプロトコルの標準化が、IETFのMoQ WGで進められています。

WarpやRUSHというプロトコル案が出ていましたが、プロトコルの設計が進み、コアプロトコルになる『Media over QUIC Transport (MOQT)』が登場しています。この仕様は、Twitch、Facebook(Meta)、Cisoco、Googleの方の共著となっています。

プロトコルスタック

MOQTは、QUICプロトコルもしくはWebTransport上に位置するプロトコルです。その上に、Warpのようなメディアフォーマット・ストリームフォーマットを定義する仕様が乗っかります。(WarpとMOQTの役割が分割された感じになります。)

(MoQ WG中間会議資料より)

Warp

「WARP Streaming Format」は、MOQTのストリームフォーマットを定義する仕様であり、CMAF [CMAF] 準拠のメディアコンテンツを配信します。

登場人物

MOQTでは、通信の種類として下記の3つの利用を想定しています。

動画のアップロード (ingestion)
動画の視聴 (delivery)
CDNなどによる中継 (relay)

そのうえで、登場人物は次のようになります。

ここで、Client/Serverはプロトコルの通信をどちらか開始するかの観点の用語です。Clientには役割に応じて、メディアを送信するProducerと、メディアを受信するConsumerが居ます。その間に通信を中継するRelayサーバが存在し得ます。

また、上記の図では片方向的な送信でしたが、ビデオカンファレンスのようにRelayサーバを介した双方向メディア通信もありえます。その場合はClientはProducerとしてもConsumerとしても振る舞うことになります。

オブジェクトモデル

MOQTはメディアのデータを「Objects」「Groups」「Tracks」という単位で管理します。

Tracks: 例えばHD Videoトラック、SD Videoトラックといったもので、Consumerが視聴を要求する単位です
Groups: 複数のObjectのグループで、視聴を開始点できる単位です。例えば、Group Of Picture (一連のI, P, Bフレーム)のグループです。
Objects: メタデータとペイロードからなるメディアデータ。リレーサーバによって変更や分割・結合は行われない。

TrackはConsumerにより視聴が要求されるため、そのためにFull Track Nameを持ちます。例をみるとわかりやすいかと思います。

Track Namespace = security-camera.example.com/camera1/
Track Name = hd-video
Full Track Name = security-camera.example.com/camera1/hd-video

なお、単一のObjectをQUICの単方向ストリームで送信することを想定しています。こうすることでHead of Line Blockingを狙いです。

プロトコルメッセージ

MOQTではプロトコルのメッセージとして以下のものが定義されています。QUICもしくはWebTransportのコネクションが確立するとストリーム上で送受信されます。

OBJECT: ObjectのPayload及び、配送に必要な情報を含みます。
SETUP: MOQTの通信の最初にやりとりされる。プロトコルバージョンなど、通信に必要な情報を交換する。
SUBSCRIBE REQUEST: トラックの受信(subsribe)を要求する
SUBSCRIBE OK: SUBSCRIBE REQUESTが成功したことを示す
SUBSCRIBE ERROR: SUBSCRIBE REQUESTが失敗したことを示す
ANNOUNCE: 受信者がSUBSCRIBEできるトラックを通知する
ANNOUNCE OK: ANNOUNCEが成功したことを示す
ANNOUNCE ERROR: ANNOUNCEが失敗したことを示す
GOAWAY: 通信を終了する

Consumerの通信例

(MoQ WG中間会議資料より)

Producerの通信例

(MoQ WG中間会議資料より)

2023-05-31

失効が不要なShort-lived証明書に関するmemo

雑 Web internet-draft

IETFやCAB Forumで有効期限の短い証明書(Short-lived Certificate)について議論があるようなので軽く眺めておく

詳しい人は補足いただけると嬉しいです

背景

Googleでは、Webをより安全にするためにWeb PKIのポリシーについて様々な取り組みを行っています。
www.chromium.org

その取り組みのなかにはCAが証明書の発行ポリシーに関するものもあります。

有効期間の短い Short-lived証明書の利用を促し、より自動化を促進するために、CA/Browser ForumのBaseline Requirementsに対して提案を行っています。

具体的なProposalでは、OCSPをOptinalにすることと、Short-lived Certificateで失効(Revocation)が不要であるとすることを提案しています。
github.com

Short-lived Certificate

Short-lived Certificateの有効期限は次のとおりです

2026 年 3月15日より前に発行された証明書の場合、有効期間が 10 日以下
2026 年 3月15日以降に発行された証明書の場合、有効期間が 7 日以下

この10日というのは、CRLの"nextUpdate"及びOCSPレスポンスの有効期間の最長と一致しています。

Short-lived Certificateの失効

Short-lived Certificateについては、CAは失効処理が不要なようである。

また、Short-lived Certificate自体にもCRL Distribution Points拡張を含めるべきではない。さらに、このProposalはShort-lived Certificateに限らずOCSPをOptionalにすることを提案している。

noRevAvail

また、IETFには次の提案が提出されています『No Revocation Available for Short-lived X.509 Certificates』。

これは、失効情報が提供されないShort-lived Certificateに対しては明示的に、noRevAvail拡張をつけようという提案です。

感想

Googleの言うWebPKI領域の自動化が進むことは良いことだなと思う。

ブラウザ側もCA側も失効処理及びOCSPやCRLのデータ量が小さくなることは良いことだなとおもいつつ、ブラウザ側は独自に失効管理してたりするので、各ステークホルダの狙いみたいなところがProposalからだけだとちょっと理解しづらいので、詳しい人に話しを聞きたいところ

2023-05-29

HTTPSに自動で切り替えるChromeのHTTPS Upgradeについて

whatwg Web

Chromeではバージョン115 (6月リリース予定)で、『HTTPS Upgrade』という機能が導入される予定です。これは、ナビゲーション時にHTTPからHTTPSに自動でアップグレードするものです。
chromestatus.com

その動作についてドキュメントを読む

背景

『HTTPS Upgrade』を導入する背景としては

多くのWebサイトがHTTPSに対応していますが、いくつかのケースでHTTPのアクセスがあり、それらを保護するためです。

HTTPSをサポートしているページでもHTTPをリッスンしている場合は、次のケースでHTTPアクセスが発生します

HSTS Preloadを登録していないケース
HSTSを利用していても、初回のアクセスするケース
HSTSを利用しておらず、HTTPをHTTPSにリダイレクトしないケース

動作

一言でその動作を表現すれば、『ナビゲーションの際に自動でHTTPからHTTPSに切り替える』というものです。もちろん、HTTPSでの接続に失敗した場合は、HTTPにフォールバックします。

細かい仕様については、whatwgのfetchの仕様にプルリクを確認することが出来ます
github.com

幾つかの具体動作

サブリソース: 今回の変更の影響は受けない。（ユーザエージェントによりmixed contentの自動Upgradeするものもある）
URLバーナビゲーション: http:// が指定された場合は自動Upgradeしない
Javascriptナビゲーション: window.locationなどによるナビゲーションは自動Upgradeの対象
POSTリクエスト: FormなどによりPOSTリクエストによるページ遷移は対象外 (mixed contentの対象ではある)
リダイレクトループ: リダイレクト処理は自動Upgradeの対象で、HTTPからHTTPSにアップグレードされるが、リダイレクトループするばあいはフォールバックしてhttpでアクセスする。

試す

Chromeバージョン111より、chrome://flags のページから下記を有効にすると試せる

#https-first-mode-v2
#https-upgrades

2023-05-07

認証エンドポイントを秘匿する HTTP Unprompted Authentication の仕様

HTTP internet-draft

2024/03/03 追記
現在は「The Signature HTTP Authentication Scheme」という仕様名になっています。

==
『HTTP Unprompted Authentication』という提案仕様がGoogleのDavid Schinazi氏らによって提出されている。

この仕様は、WebサーバにおいてHTTP認証を行っている事を秘匿するための仕様です。これによりWebサーバ上に管理者向けエンドポイントや、VPNサービスなどが動いてることを隠すことができます。

そのために必要なこととして、もちろん通信の暗号化も必要ですが、さらに正規ユーザでない第三者が認証用エンドポイントにリクエストしても「401 Authorization Required」で応答しないという要件があります。「401 Authorization Required」を返さないため、認証に使うNonceを別途共有する必要が出てきます。

『HTTP Unprompted Authentication』はそのための仕組みを提供します。

Nonceの生成

この仕様では通信はTLSもしくはQUICを利用している事を前提としています。
Nonceの生成には、『RFC 5705 Keying Material Exporters for TLS』を利用しセッションに固有な秘密値を得ます。これをNonceとして利用します。

なお、ラベルには認証方式にあわせて次のどちらかを使用します

EXPORTER-HTTP-Unprompted-Authentication-Signature
EXPORTER-HTTP-Unprompted-Authentication-HMAC

認証用ヘッダ

認証用ヘッダとして新しくUnprompted-Authenticationヘッダを定義します。

Signatureで認証する場合の例

Unprompted-Authentication: Signature k=:YmFzZW1lbnQ=:;s=7;
  p=:SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo
  aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ==:

HMACで認証する場合の例

Unprompted-Authentication: HMAC k="YmFzZW1lbnQ=";h=6;
  p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl
  cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ=="

それぞれヘッダのパラメータの意味は次のとおりです

k: クライアントが認証に用いた鍵の識別子
p: 鍵情報の所持を証明するためのデータ
s: pを導出するのにつかった署名アルゴリズムの番号(TLSのIANAで定義される)
h: pを導出するのにつかったハッシュアルゴリズムの番号(TLSのIANAで定義される)

動作

クライアントは、そこに認証用エンドポイントがあるという知識を持って認証用エンドポイントにアクセスします。そのときにUnprompted-Authenticationを送信することで認証を試みます。

サーバは、送られてきたUnprompted-Authenticationヘッダを持ってユーザを認証します。認証が通れば200を返すことになります。それ以外の場合は、認証エンドポイントを秘匿するために404で応答します。

2023-05-06

再送はしてもらう Reliable QUIC Stream Resets の仕様

QUIC internet-draft

『Reliable QUIC Stream Resets』という提案仕様が提出されています。

もともと、RFC 9000 QUICではRESET_STREAMフレームを送信しストリームを中断するとそのストリームではデータは再送されません。『Reliable QUIC Stream Resets』ではストリームを終了しつつもパケロスしたデータは再送するように指示できます。

ユースケースとして挙げられているのは、WebTransportでのユースケースです。WebTransportではストリームの最初にHTTPリクエストと紐づけるためのセッションIDを持ちます。リセットはしつつも、パケロスしたセッションIDは再送してもらいプロトコルを利用するアプリケーション側にその情報を通知したいです。

特に難しいことはないですが、『Reliable QUIC Stream Resets』で定義されるRELIABLE_RESET_STREAMフレームを見ていきます。

Reliable QUIC Stream Resets

この仕様では、新しくRELIABLE_RESET_STREAMフレームを定義します。これはReliable Sizeを除き、RFC 9000 QUICのRESET_STREAMフレームと同様です。
(2023年7月追記: 最新draftでは、RELIABLE_RESET_STREAMフレームはCLOSE_STREAMフレームに改称されいています)

Reliable Sizeは再送して欲しいデータのオフセットを指定します。

Cache-Groups レスポンスヘッダ

Cache-Group-Invalidation レスポンスヘッダ

An HTTP Cache Invalidation API

レスポンス

おまけ

プロトコル スタック

登場人物

オブジェクトモデル

プロトコル メッセージ

Consumerの通信例

Producerの通信例

背景

Short-lived Certificate

Short-lived Certificateの失効

noRevAvail

感想

背景

動作

幾つかの具体動作

試す

Nonceの生成

認証用ヘッダ

動作

Reliable QUIC Stream Resets

プロトコルスタック

プロトコルメッセージ