サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
asnokaze.hatenablog.com
Cookieの改訂版仕様 rfc6265bis について、その変更点をざっと眺めていく はじめに SameSite属性 Cookie名プレフィックス (Cookie Name Prefixes) __Secureプレフィックス __Hostプレフィックス 非セキュアなオリジンからの Secure属性の上書きを禁止 nameless cookieの許容 Cookie名、Cookie値の上限長の指定 Expires属性の年が2桁の場合の処理の指定 Max-Age/Expires の上限 その他 今回入らなかった機能 はじめに Cookieの仕様は『RFC 6265: HTTP State Management Mechanism』として標準化されています。 そのCookieの仕様の改訂版が『rfc6265bis』と呼ばれているもので、現在標準化作業が進められいています。"SameSite属性"
Webサイト利用者に関するプライバシーが重要視されるなか、プライバシーポリシーURLや各種オプトアウト用URLを提示できる『privacy.txt』の仕様がIETFに提出されている。 このprivacy.txtは、『robots.txt』『security.txt』『ads.txt』と同様に、ドメイン直下のPATH、もしくは/.well-knownのパスに配置される。 privacy.txtの中身 何が記述できるかについては『A File Format to Aid in Consumer Privacy Enforcement, Research, and Tools』仕様に書かれている プライバシーポリシー情報 プライバシーポリシーに関するURLを提示できる Privacy-policy: URL プライバシーポリシーのURLを提示 Privacy-policy-text: URL プ
RFC 9000 QUICには、経路上のスイッチから明示的な輻輳シグナルを受け取る ECN (Explicit Congestion Notification) という機能に対応しています。 Googleではサーバ側はQUIC ECN対応がデプロイされており、Chromeでの実装も進められている事が報告されています。 mailarchive.ietf.org 概要 ECNに対応したネットワーク機器は、輻輳が起こると該当のパケットにおいて、IPヘッダのTOS fieldのCE(Congestion Experience)ビットをセットする 受信したIPヘッダのCE(Congestion Experience)ビットがセットされている場合、パケットの送信者にフィードバックするため、QUICのACK-ECNでそれを通知する ACK-ECNを受け取ったエンドポイントは輻輳が起こっている事を把握し、
IETFに『Secure shell over HTTP/3 connections』という提案仕様が提出されています。 これは、HTTP/3コネクション上でSSHを実行するプロトコルを定義しています。なお、"SSH3"という名称を仕様中で使用していますが、あくまで提案段階ですので今後変わる可能性もあります。 SSH3ではHTTP/3を使うことにより以下の特徴を持ちます QUICのメリットが享受できる(例えばIPアドレスが変わってもコネクションを維持できる) HTTPの認証方式をサポートする(Basic認証、OAuth 2.0、Signature HTTP Authentication Scheme) SSH通信の秘匿 (第三者からするとただのHTTP通信にみえる) エンドポイントの秘匿 (Signature HTTP Authentication Schemeを使うことで、そこでサービス
『Oblivious HTTP』はユーザのプライバシを向上するための技術であり、各ブラウザベンダーおよびCDNベンダーが実装を行っています。 取り組みについては、幾つかの記事があがっています 『Google、Chrome ユーザーのオンラインプライバシー保護を強化するプライバシーサンドボックスのイニシアチブに Fastly Oblivious HTTP リレーを採用』 『Built for privacy: Partnering to deploy Oblivious HTTP and Prio in Firefox』 今回は仕様の観点で、プロトコルの中身に触れていく 背景と目的 通信観点のプライバシーについては、通信の暗号化によりほとんどが保護されています。しかし、幾つか懸念が残っています。 IPアドレスは、短期的に同一ユーザを識別するのに使用できる コネクションは、一連の通信が同一ユー
新しいHTTPステータスコード"420 Requester Impaired"を定義する『An HTTP Status Code to Report Requester Impairment』という提案仕様が提出されています。 これは、送信者の障害によりサーバは処理を拒否したことを示します。 目的として、重機などの機械やAIシステムが故障してることを示唆することを掲げています。提案仕様のなかでも次のように書かれています。 ある種のAIシステムは、与えられた入力に対して幻覚を見たり、不正確な答えを返したり、異なる答えを返したりといった行動を示すことがある。このようなAIが動作するスピードを考えると、人間の要求者と同様に、AIの要求者の障害を検出することも重要である。 (DeepL) 例 ステータスコードの定義なのでそのままなんですが、例としては次のとおりです (ボディは、RFC9457 形式
Apple勢から「Origin-Bound One-Time Codes」というSMSで発行するワンタイムコードのフォーマットの提案仕様がIETFに提出されています。 こちらの仕組みの標準化ということで良いかなと思います。 developer.apple.com 背景 Webのログイン時にSMSでワンタイムコードを送信し、入力させることがあります。昨今ではformの 『autocomplete="one-time-code"』属性によりユーザエージェントがSMSのコードを自動入力してくれたりします。 こちらのサイトでも書かれているように、攻撃者がフィッシングの手口で入力させたID/Passを正規サイトにインプットさせるとSMSコードを自動入力させる事ができます。 akaki.io そこで、SMSで発行したワンタイムコードをドメインに紐付けることでこのような攻撃を防ぐのが今回の目的です Or
『DNS Multiple QTYPEs』という提案仕様がIETFで議論されています。 これは、"A", "AAAA", "HTTPS"など複数のレコードタイプを一度に問い合わせする仕組みを定義しています。 背景: 複数Questionセクションは使えない もともと、一つのパケットに複数のQuestionセクションを含めることは可能ですが、下記の理由により使用されていません QNAME フィールドが複数あるので、一貫性のあるレスポンスが生成できない RFC1035 などで 多くのケースで Questionセクションが単一であることを暗に述べている 実装がサポートしていない DNS Multiple QTYPEs 『DNS Multiple QTYPEs』では、EDNSオプションを使います。 QTD: リクエストでは0, レスポンスでは1。(エコーするサーバを検知するのに使用) QTCOUN
IETFに「Using QUIC to traverse NATs」という提案仕様が提出されています。 このDraftでは「WebRTC over QUIC」や「P2P QUIC」のユースケースを想定しています。 大まかな流れとしては 『Proxying Listener UDP in HTTP』といったProxy経由でクライアントはサーバに接続する そのコネクション上でIPアドレスを交換してICE相当の処理を行う QUICのPath validationの仕組みを用いてホールパンチングする コネクションマイグレーションを行う IETF 118の発表スライドがわかりやすいので、それをもって流れを説明していく Address Discovery QUICがProxyを経由してコネクションが確立したあと、サーバから ADD_ADDRESSフレームで候補となるIPアドレス及びポートをクライアント
IPv4とIPv6デュアルスタック環境において、早く通信確立できた方を使用する『Happy Eyeballs』という仕組みがあります。 「RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency」においては、次のようにAAAAレコードとAレコードの名前解決を行い早く通信確立できたものを使用するようになっています。 今回、そのVersion 3となる『Happy Eyeballs Version 3: Better Connectivity Using Concurrency』という提案仕様が提出されています。著者はAppleやGoogleの方々で、QUIC WGやTLS WGで精力的に活動されている方々です。 Happy Eyeballs Version 3 『Happy Eyeballs Versio
HTTP/2のDDoS攻撃手法として『HTTP/2 Rapid Reset』(CVE-2023-44487)が世間を賑わせています。 各ベンダーから情報が出ています AWS 『How AWS protects customers from DDoS events』 GCP『The attack used a novel technique, HTTP/2 Rapid Reset, based on stream multiplexing』 Cloudflare『HTTP/2 Rapid Reset: deconstructing the record-breaking attack』 このDDoS攻撃はストリームのオープン(HTTPリクエスト)とストリームのキャンセルを繰り返すことで行われます。HTTP/2では、ピアが同時に開くストリーム数を制限する事ができますが、それではオープン/クロー
IETFに『TLS 1.2 is in Feature Freeze』という提案が出されています。 これは、標準化作業上、TLS1.2に新しい機能追加を停止しようという提案です(ただしセキュリティ対応は除く)。TLS1.2やTLS1.3にはエクステンションや、新しい暗号アルゴリズム、Supported Groupsなどを追加できるようになっていますが、それらの追加をTLS1.2では承認しないという話しです。 アプリケーションプロトコルがTLS1.2を利用することを禁止するものではありません。 議論 2023年 3月に行われた IETF 116 TLS WGのミーティングで『TLS 1.2 Deprecation (PDF)』という話しがありました。そこでは、標準化上 TLS 1.2をDeprecation する議論が行われました。 議論は、標準化上の話しと実利用の話しが色々議論されましたが
HTTP/2やHTTP/3のレイヤで追加のサーバ証明書を送信可能にする『Secondary Certificate Authentication of HTTP Servers』という仕様がHTTP WGで議論されています。著者はAppleの方とAkamaiの方の共著になっています。 以前にも、共著に入っているMike Bishop氏から2016年~2018年に同様の提案が出ておりましたが改めて提案されています。前回はクライアント側からのクライアント証明書の追加送信サポートしていましたが、今回はサーバからの追加の証明書を送信するユースケースに絞った提案になっています。 モチベーション HTTPレイヤで追加のサーバ証明書を送信するモチベーションについて説明します。 HTTP/2ではTCPコネクション、HTTP/3ではQUICコネクション上でHTTPリクエストを送信します。極力そのコネクション
W3CのPrivacy Community Groupでは、Webのプライバシーについて取り組んでいます。 その取り組みとして「Global Privacy Control (GPC)」というドキュメントが書かれています。このドキュメントでは、ユーザが個人情報を共有しないように要求する Sec-GPC リクエストヘッダが定義されています。 多くのWebサイトでは個人情報の取り扱いについてオプトアウト方法を提供していますが、ユーザが個々にオプトアウトを行うよりか簡単な手段を提供するというモチベーションがあるようです。 また、この仕様は、各国のプライバシー法などの法的枠組みにおけるオプトアウトの意思表示として扱えることを意図しているようです。 Firefoxでも実装が進められています。 Intent to Prototype: Global Privacy Control Sec-GPC リク
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
「The Off-The-Record Response Header Field」という仕様がIETFに提出されています。これは、Webサイトの閲覧履歴をブラウザが保存しないように指示するHTTPレスポンスヘッダです。 このレスポンスヘッダを使うことで、Webサーバ側から自身のサイトの閲覧履歴を残さないようにすることができます。家庭内暴力の相談やセンシティブな医療サイトの閲覧情報がブラウザに残らないようにできます。 Braveブラウザの1.53 (beta)ではflagsで有効にするとすでに使えるようになっています。動作としては、Webサイトを閲覧する際にOTRモードで閲覧するか確認画面が出るようです。 Request-OTR ヘッダ Request-OTR ヘッダは、RFC 8941 Structured Field Valuesに準じており、ブール値を指定します Request-OT
現状UDPヘッダには、TCPやSCTPにあるようなオプションを指定できません。 新しい「Transport Options for UDP」という仕様では、UDPにおいてオプションを付けられるようになります。 その仕組が面白かったので簡単に紹介します。 どこが面白いかというと、UDPヘッダは下記の通り「送信元ポート」「送信先ポート」「長さ」「チェックサム」からなり、その後に実際のデータが続きます。 固定長のヘッダしかないUDPにおいて、既存の実装に対してもそのままUDPパケットを扱えるようにオプション領域をどう確保したのか、考えてみると面白そうと感じていただけると思います。 Transport Options for UDP 「Transport Options for UDP」では、UDPオプションを格納するのにsurplus areaという領域を確保します。それはIPヘッダについても知
『HTTP Cache Groups』という提案仕様がIETFに提出されています。これは、HTTPキャッシュをグループ化し、グループの単位で無効化や再検証を行えるようにする提案です。 Webサイトで利用する複数のJavaScriptやCSSファイルはデプロイすることがあるため、それらのキャッシュの管理をグループで扱うことはメリットがあります。例えばグループ内の一つのキャッシュを再検証(Revalidation)することで、グループ内のほかのリソースも再検証したものとして扱えるようになります。 またCDNのレイヤにおいて、キャッシュの無効化(Invalidation)・パージもグループで行えるのは管理上都合が良いでしょう。 Cache-Groups レスポンスヘッダ レスポンスにおいてCache-Groupsヘッダでグループを指定できます。 Cache-GroupsヘッダはStructure
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:
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のストリームフォーマットを定義す
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.
Chromeではバージョン115 (6月リリース予定)で、『HTTPS Upgrade』という機能が導入される予定です。これは、ナビゲーション時にHTTPからHTTPSに自動でアップグレードするものです。 chromestatus.com その動作についてドキュメントを読む 背景 『HTTPS Upgrade』を導入する背景としては 多くのWebサイトがHTTPSに対応していますが、いくつかのケースでHTTPのアクセスがあり、それらを保護するためです。 HTTPSをサポートしているページでもHTTPをリッスンしている場合は、次のケースでHTTPアクセスが発生します HSTS Preloadを登録していないケース HSTSを利用していても、初回のアクセスするケース HSTSを利用しておらず、HTTPをHTTPSにリダイレクトしないケース 動作 一言でその動作を表現すれば、『ナビゲーションの際
2024/03/03 追記 現在は「The Signature HTTP Authentication Scheme」という仕様名になっています。 == 『HTTP Unprompted Authentication』という提案仕様がGoogleのDavid Schinazi氏らによって提出されている。 この仕様は、WebサーバにおいてHTTP認証を行っている事を秘匿するための仕様です。これによりWebサーバ上に管理者向けエンドポイントや、VPNサービスなどが動いてることを隠すことができます。 そのために必要なこととして、もちろん通信の暗号化も必要ですが、さらに正規ユーザでない第三者が認証用エンドポイントにリクエストしても「401 Authorization Required」で応答しないという要件があります。「401 Authorization Required」を返さないため、認証に使
「ZTLS: A DNS-based Approach to Zero Round Trip Delay in TLS」という論文が公開されている。アイデアが面白いので簡単に眺める。 PDFも今のところACMのサイトから見れる https://dl.acm.org/doi/abs/10.1145/3543507.3583516 概要 DNSからTLSハンドシェイクに必要な情報を通知し、0-RTTハンドシェイクを行う 通常のTLSと互換性がある シーケンス図 (引用: 「ZTLS: A DNS-based Approach to Zero Round Trip Delay in TLS」 Figure 3) 事前に、サーバ側はZ-Data(ハンドシェイクに必要な情報)をDNSにアップロードしておく クライアントはサーバDNSに対してAレコードと、Z-Dataを含むレコードを並列に問い合わせ取
『Proxying Ethernet in HTTP』という仕様がGoogleのAlejandro R Sedeño氏から提出されています。これは、HTTP上でイーサネットフレームを送受信させるための仕様です。 背景として、IETFでは、Masque WGにおいてHTTPコネクション上で通信をトンネリングする仕組みの標準化を行っています。 RFC 9298 Proxying UDP in HTTP Proxying IP in HTTP すでに標準化が進められている、上記の仕様に続きイーサネットフレームを取り扱えるようにするというのが今回の提案です。ユースケースについては、L2VPNを実現するのに利用する例が挙げられています。 Proxying Ethernet in HTTPの概要 『Proxying Ethernet in HTTP』では、"RFC 9297 HTTP Datagram
「Link relationship types for authentication」という仕様が、IETFのHTTPAPI WGで議論されています。 例を見るのがわかりやすいと思います。 authenticate aリンクで、リンク先をログインページということを示すことが出来るようになります。コレに対してブラウザは、ログインをナビゲーションするUIを表示したりできるようになります。 <a href="/login" rel="authenticate">Login</a> authenticated-as authenticated-as を使うことで、認証されたユーザの情報を取得できるリンクを示します。自身が誰として認証されているかわかります。 これは、特にAPIコールするときに有用です。自身がどの権限でAPI叩いてるかがわかるリンクを取得できるようになります。 下記はレスポンスヘッ
現在 ChromeではHTTPの通信をBrotliの辞書で圧縮する『Feature: Compression dictionary transport with Shared Brotli』という仕組みの開発が進められています。 この仕組は、来週開催されるIETF 116のサイドミーティングでも議論が行われる予定になっています。 なので、軽くその仕組について予習をしておく。仕組みについて説明したドキュメントはこれ github.com Compression dictionary transport 基本的なアイデアとしては、サーバからBrotliの辞書データを提供して、以降のHTTP通信では(使える場合は)その辞書を活用してHTTPレスポンスを圧縮する (辞書データは他のサイトとは共有されない。Pathに合わせて複数の辞書を使い分けできるようになっている) 辞書データとしては、大きく2種
以前紹介したように、ブラウザでTCPソケットを扱う『Direct Sockets API』という仕様があります。 asnokaze.hatenablog.com 前回紹介したときから時間はたち、Isolated Web Appsでの利用に限定されたり、TCPサーバソケットをリッスンできるようになったりしている。 Isolated Web Apps Isolated Web Appsは、Web技術を用いて作られたアプリケーションを独立した環境で動作させる仕組みです。現在、フラグ付きでChromeを起動することで動作させることが出来ます。 github.com アプリケーションの例として、Telnetクライアントを動作させる Isolated Web Apps が公開されています。 github.com Webアプリケーションに署名し、サーバを起動させた、フラグ付きで起動したChromeで動作
ついに、IETF 116 Yokohamaが始まりましたね!!横浜で僕と握手!! WGのミーティングは月曜日からですので、ちょうど直前ということになります。 パシフィコ横浜ノース 3Fで受付を済ませたあとは、アジェンダ(URL)のページを参考に会議室に行くだけです。 WGのミーティングでは、前回議論した提案仕様のIssueが議論されます。できれば、WGミーティングのAgendaは抑えて予習はしておいた方が良いかと思います。とはいえ、会議中にちんぷんかんぷんでも情報を追うコツを幾つか書いておこうと思います。 心得 英語は分からない、、、みんな分からない大丈夫!! せっかくなので色々な人に話しかけよう (議論とかは詳しい人に聞こう!) 無理して全部のミーティングに出る必要はない! WG ミーティング materials 各WGのアジェンダ及び発表資料は マテリアルページ(URL)に記載されます
次のページ
このページを最初にブックマークしてみませんか?
『ASnoKaze blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く