サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
asnokaze.hatenablog.com
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
IETFのTLS WGでは、Googleの方らによって提案されている『TLS Trust Anchor Negotiation』という仕組みが議論されています。 これは、クライアントとサーバ側で共に信頼できるCA(トラストアンカー)をネゴシエーションし、複数あるサーバ証明書から適切なものを提供できるようにする仕組みです。 (引用: IETF 120 スライド PDF より) 具体的な提案仕様よりも、explainer を読むのが分かりやすい。自分用に軽く目を通しておく https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md 目次 背景 目標 実現案 Trust Expressions Trust Anchor Identifiers 背景 現状、クライアントがどのCAを信頼しているか伝えず、サーバ側は
TCP(+TLS)上でQUICおよびHTTP/3の通信を行うことを可能にする『QUIC on Streams』という仕様がFastlyのOku Kazuho氏らによって提案されている。 今年3月に行われたのIETF119で提案されている。 仕様は、TCP/TLS上でQUIC通信を行う『QUIC on Streams』と、それを使ってHTTP/3通信を行う『HTTP/3 on Streams』に分かれている。 『QUIC on Streams』 『HTTP/3 on Streams』 今週IETF120があるので、キャッチアップしておく。 モチベーション この提案の背景にあるのは、WebTransportといったHTTP上で動作する新しいプロトコルを設計する際に HTTP/3版とHTTP/2版の両方を設計・メンテナンスを行っているところにあります。 (引用: IETF119スライドPDFより
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属性"
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アドレスは、短期的に同一ユーザを識別するのに使用できる コネクションは、一連の通信が同一ユー
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
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 する議論が行われました。 議論は、標準化上の話しと実利用の話しが色々議論されましたが
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
以前紹介したように、ブラウザで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)に記載されます
「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は英語
ピクチャーインピクチャー (PIP) ピクチャーインピクチャー (PIP)は、ブラウザ上で小窓で動画視聴できる仕組みです。 例えば、YouTube上で右クリックして、『ピクチャー イン ピクチャー』を選択すると 次のように小窓で動画を再生してくれます。 他のタブを表示したり、ウィンドウを最小化しても再生され続けるため、作業しながらの視聴時に大変助かります。 Document Picture-in-Picture 現在の『ピクチャー イン ピクチャー』はHTMLVideoElementでしか行なえません。そのためYouTubeのプレイヤー操作(シークバー操作やショートカットキーによる早送り/巻き戻し)は出来ません。 現在 任意のHTMLElements を『ピクチャー イン ピクチャー』可能にする「Document Picture-in-Picture Explained」の議論がされいます
現在の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
PCの負荷状況に合わせて、Webサイトでの処理を軽量なものに切り替えたい場合があります。 それを可能にする仕組みである「Compute Pressure API 」がChromeで実装が進められています。なお、仕様の方もW3Cで「Compute Pressure Level 1」が公開されています 例 Compute Pressure APIを使うと、PCのCPU負荷が4段階で確認できます。 Nominal: 負荷が低い状態 Fair: システムは正常に動作しており、追加のワークロードを実行できる Serious: 負荷が高い状態。追加のワークロードを実行するとCriticalになりうる Critical: 負荷が限界に近い状態 詳しいCPU情報はプライバシーの観点から公開しない設計になっています。 実行例 Compute Pressure API は現在Chromeの開発版で動作確認でき
次のページ
このページを最初にブックマークしてみませんか?
『ASnoKaze blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く