プライベート用途に使える .internal ドメイン - ASnoKaze blog
2024年7月に、ICANNで .internal トップレベルドメイン(TLD) がプライベート用途として予約されたようです。 背景 長らくプライベート用途で利用できるトップレベルドメインについて議論されてきました。 現在、各組織が独自のTLDをプライベート用に利用しているケースがあります。しかし以下のような問題があります、 新gTLDが登録された際に、衝突する可能性がある Root DNSへ不要な問い合わせがある 実際、.home、.internal、.lan、.corp、.localdomain、.dlink、.zyxel-usg のような問い合わせがRoot DNSに来ていることが知られています。 そこで、.internal をプライベート用途として予約しようというのが、ICANNで議論されている『SAC113：SSAC私的利用TLDに関する勧告（SAC113）』です。 JPNIC
Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog
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属性"
HTTP/3コネクション上でSSHを実行するSSH3プロトコル - ASnoKaze blog
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を使うことで、そこでサービス
個人情報を共有しないように要求する Sec-GPC リクエストヘッダ - ASnoKaze blog
W3CのPrivacy Community Groupでは、Webのプライバシーについて取り組んでいます。 その取り組みとして「Global Privacy Control (GPC)」というドキュメントが書かれています。このドキュメントでは、ユーザが個人情報を共有しないように要求する Sec-GPC リクエストヘッダが定義されています。 多くのWebサイトでは個人情報の取り扱いについてオプトアウト方法を提供していますが、ユーザが個々にオプトアウトを行うよりか簡単な手段を提供するというモチベーションがあるようです。 また、この仕様は、各国のプライバシー法などの法的枠組みにおけるオプトアウトの意思表示として扱えることを意図しているようです。 Firefoxでも実装が進められています。 Intent to Prototype: Global Privacy Control Sec-GPC リク
逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
HTTPのキャッシュをグループ化する HTTP Cache Groups の仕様 - ASnoKaze blog
『HTTP Cache Groups』という提案仕様がIETFに提出されています。これは、HTTPキャッシュをグループ化し、グループの単位で無効化や再検証を行えるようにする提案です。 Webサイトで利用する複数のJavaScriptやCSSファイルはデプロイすることがあるため、それらのキャッシュの管理をグループで扱うことはメリットがあります。例えばグループ内の一つのキャッシュを再検証(Revalidation)することで、グループ内のほかのリソースも再検証したものとして扱えるようになります。 またCDNのレイヤにおいて、キャッシュの無効化(Invalidation)・パージもグループで行えるのは管理上都合が良いでしょう。 Cache-Groups レスポンスヘッダ レスポンスにおいてCache-Groupsヘッダでグループを指定できます。 Cache-GroupsヘッダはStructure
HTTPのキャッシュを無効化するAPIの標準化する提案仕様 - ASnoKaze blog
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:
新しいメディア転送プロトコル Media over QUIC Transport について - ASnoKaze blog
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のストリームフォーマットを定義す
失効が不要なShort-lived証明書に関するmemo - ASnoKaze blog
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.
HTTP上でL2VPNを実現する Proxying Ethernet in HTTP について - ASnoKaze blog
『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
DNSを使ってTLSハンドシェイクを高速化するZTLSについて - ASnoKaze blog
「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を含むレコードを並列に問い合わせ取
キャッシュを補助する HTTP Availability Hints の仕様 - ASnoKaze blog
「HTTP Availability Hints」という提案仕様がMark Nottinghamによって提出されています。 この提案仕様では、キャッシュで使用されるVaryを補助します。この情報により、キャッシュサーバは効率が向上します。 背景 例えば Client 1から英語(en)のコンテンツが要求され、CDNは英語コンテンツをキャッシュする Client 2から日本語(ja)のコンテンツが要求される CDNがOriginからレスポンスを受け取った際に、"vary: Accept-Encoding" がついています。そのため、CDNはオリジンのコンテンツがaccept-languageに依存していると判断して、日本語(ja)の要求をOriginにプロキシします。 このとき、Originが日本語(ja)には対応しておらず結局英語(en)のコンテンツが返ってくることもあります。CDNは英語
セキュリティ関連のHTTPヘッダを一括指定する Baseline ヘッダ - ASnoKaze blog
現在のWebでは、セキュリティ上レスポンスヘッダで色々なものを指定します。Webデベロッパーは個別に指定しなければなりません。 そこで、セキュリティ関連のヘッダを推奨デフォルト値に設定できるようにする「Baseline ヘッダ (Opt-into Better Defaults)」が、GoogleのMike West氏によって提案されています。 まだたたき台であり、これからW3CのWebAppSec WGで議論されている予定になっています。 Baseline ヘッダ 次のようにレスポンスヘッダを指定します。 Baseline: Security=2022これは、次のヘッダを送信するのと同様です。 Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'none'; require-trusted-ty
CookieのPartitioned属性 (CHIPS) の標準化はじまる - ASnoKaze blog
サードパーティCookieをトラッキングに使用できないようにする「Cookies Having Independent Partitioned State (CHIPS)」という仕組みが議論されています。 現在は、その仕組はW3CのPrivacy CGで議論されています。細かい仕組みは以前書いたとおりです。 ( トラッキングに利用できない3rdパーティクッキー「CHIPS」の仕組み (partitioned属性) - ASnoKaze blog ) このCHIPSは、Cookieに新しいPartitioned属性を利用します。Cookie自体の仕様は、IETFが発行するRFC 6265で定義されており、そこにPartitioned属性を追加してやる必要があります。 そのためIETF側にも「Cookies Having Independent Partitioned State specif
クエリパラメータ付きURLのキャッシュを改善する No-Vary-Search ヘッダ - ASnoKaze blog
キャッシュのキーとしてURLが使われます。このときURLのクエリパラメータも含めて考慮されます。 特定のクエリパラメータは、分析や別様とでアクセスログに残すために使われたりしますが、提供するリソースが変わらない場合があります。そのケースであれば、クエリパラメータが付いてたとしても、キャッシュがあればキャッシュを使ってもらいたいものです (ここでキャッシュは、HTTPキャッシュ及び、prefetchやprerenderを指します)。 そのため、クエリパラメータが付いている場合の扱いを改善する No-Vary-Search レスポンスヘッダ が、Chromeの方中心に議論されています。 github.com 例 No-Vary-Search レスポンスヘッダの例として次のものが上げられている クエリパラメータのキーの順序を考慮しない No-Vary-Search: key-order特定のクエ
HTTP/3のCONNECT-UDPを利用したWebRTC通信 - ASnoKaze blog
「Proxying Listener UDP in HTTP」という提案仕様がIETFに提出されている。 これは、HTTP/3のCONNECT-UDPを介してWebRTC通信を可能にするための提案である。まだ議論の呼び水と鳴るdraftであるため、ここから仕様は大きく変わると思うが、ざっと眺めていく。 HTTP/3のCONNECT-UDP 本論に入る前に、まずCONNECT-UDPについて説明します。 IETFではすでに「Proxying UDP in HTTP」という仕様が議論されている。これが通称CONNECT-UDPと呼ばれているものである。実は、AppleのPrivate Relayでもすでに使用されているものである。 これは、Proxyと確立したHTTP/3コネクションをトンネリングしてUDPパケットを中継させる機能です。 この通信は第三者からはただのHTTP/3通信としてか観測
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies - ASnoKaze blog
Blinkの開発者メーリングリストで「Intent to Prototype: Origin-Bound Cookies」という議論が行われています。 Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。 詳しい背景や仕組みについては次のページから確認できます。 github.com かんたんに、Origin-Bound Cookiesの動作をみていきましょう。 例 オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。 例えば、次のようになります。 http://example.comによってセットされたcookieは、http://example.comにのみ送信されます。ht
Webサイトのバグの報告先を示す contributing.txt - ASnoKaze blog
Webサイトのバグを見つけたとしても、その報告先を知る統一的な方法は現状ありません。 たとえば、脆弱性についてはsecurity.txt があります。https://www.facebook.com/security.txt などで使われています。 asnokaze.hatenablog.com 同様の仕組みで、contributing.txt という形式でバグの報告先を示せるようにする仕組みが提案されています。提案仕様は「a simple way to provide informations for contributors」としてIETFに提出されています。 例 contributing.txtをWebページの最上位階層に配置します (例: https://example.com/contributing.txt ) そのファイルは次の情報を含めることが出来ます。 Admin: Va
40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
