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
UDPにオプション領域を追加する仕様 - ASnoKaze blog
現状UDPヘッダには、TCPやSCTPにあるようなオプションを指定できません。 新しい「Transport Options for UDP」という仕様では、UDPにおいてオプションを付けられるようになります。 その仕組が面白かったので簡単に紹介します。 どこが面白いかというと、UDPヘッダは下記の通り「送信元ポート」「送信先ポート」「長さ」「チェックサム」からなり、その後に実際のデータが続きます。 固定長のヘッダしかないUDPにおいて、既存の実装に対してもそのままUDPパケットを扱えるようにオプション領域をどう確保したのか、考えてみると面白そうと感じていただけると思います。 Transport Options for UDP 「Transport Options for UDP」では、UDPオプションを格納するのにsurplus areaという領域を確保します。それはIPヘッダについても知
HTTPSに自動で切り替えるChromeのHTTPS Upgradeについて - ASnoKaze blog
Chromeではバージョン115 (6月リリース予定)で、『HTTPS Upgrade』という機能が導入される予定です。これは、ナビゲーション時にHTTPからHTTPSに自動でアップグレードするものです。 chromestatus.com その動作についてドキュメントを読む 背景 『HTTPS Upgrade』を導入する背景としては 多くのWebサイトがHTTPSに対応していますが、いくつかのケースでHTTPのアクセスがあり、それらを保護するためです。 HTTPSをサポートしているページでもHTTPをリッスンしている場合は、次のケースでHTTPアクセスが発生します HSTS Preloadを登録していないケース HSTSを利用していても、初回のアクセスするケース HSTSを利用しておらず、HTTPをHTTPSにリダイレクトしないケース 動作 一言でその動作を表現すれば、『ナビゲーションの際
HTTPの通信を辞書で圧縮する提案について - ASnoKaze blog
現在 ChromeではHTTPの通信をBrotliの辞書で圧縮する『Feature: Compression dictionary transport with Shared Brotli』という仕組みの開発が進められています。 この仕組は、来週開催されるIETF 116のサイドミーティングでも議論が行われる予定になっています。 なので、軽くその仕組について予習をしておく。仕組みについて説明したドキュメントはこれ github.com Compression dictionary transport 基本的なアイデアとしては、サーバからBrotliの辞書データを提供して、以降のHTTP通信では(使える場合は)その辞書を活用してHTTPレスポンスを圧縮する (辞書データは他のサイトとは共有されない。Pathに合わせて複数の辞書を使い分けできるようになっている) 辞書データとしては、大きく2種
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
UUIDv6~UUIDv8と uuidrev の動向 - ASnoKaze blog
UUIDの新しいフォーマットとしてversion6~version8を追加する提案がIETFで行われていることは、以前記事で取り上げたとおりです。 asnokaze.hatenablog.com その後、IETFでRevise UUID WGが立ち上がるなど、標準化に向けて動きがあったので簡単に紹介する （今回は、具体的なUUIDv6~UUIDv8 の紹介は割愛する） uuidrev 今年の8月、Revise UUID WG (uuidrev) が立ち上がりました。このWGの主な作業領域は次のとおりです。 UUIDを定義した RFC4122 を改訂し、既存のエラッタを治す 改訂版仕様にUUIDv6~UUIDv8 を組み込む なお、これらの作業のマイルストーンとして2023年3月にIESGに提出することが掲げられています。 WG設立の流れは、7月に行われたIETF114の議事録に議論の様子が
一般ユーザに払い出すと危険なサブドメインやメールアドレス - 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が
ブラウザでTCPを直接送受信できるDirect Sockets APIについて - ASnoKaze blog
ブラウザから直接TCP・UDPで送受信する「Direct Sockets API」という仕組みが議論されています。 実験段階ですが、Chromeでは起動時にオプションを付けることでこの機能を有効にできます。今回はTCPの方で簡単に動作を見てみます。 Direct Sockets API Direct Sockets APIは、TCP・UDPで直接送受信可能にするAPIです。既存のアプリケーションプロトコル(SSHやIRC)、P2Pのような機能を実現可能になります。 もちろんセキュリティ上の問題もあるので、Chromeでは現状デフォルトでは有効になっていない機能です。 セキュリティ面についてはだいぶGithubリポジトリで議論されておりますので目を通すと良いでしょう。ローカルネットワークへの通信やSame-Origin-Policy(CORS)回避の話が上がっていますが、今回は細かくは紹介し
gRPC over HTTP/3のプロトコルと実装を眺める - ASnoKaze blog
gRPC over HTTP/3のプロポーザルと、実装が出てきています。 プロトコル仕様: https://github.com/grpc/proposal/blob/master/G2-http3-protocol.md 実装 (.NET6): https://devblogs.microsoft.com/dotnet/http-3-support-in-dotnet-6/ 今回は、仕様を眺めつつ、Ubuntuで実装を動かすところまで試してみようと思います プロトコル仕様 プロポーザルは、現在 "In review" の状態となっています。 github.com HTTP/3の基本 HTTP/3はHTTP/2と機能上は大きな違いはありません。HTTPリクエストで通信が始まり、各HTTPリクエスト・レスポンスはQUICのストリームによって多重化されます。そのため、gRPC over HTT
QUIC Version 2 の仕様 (RFC 9369) - ASnoKaze blog
(追記: 2023/06/01 RFC 9369になりました) 「QUIC Version 2」という仕様が提案されています。これは、「RFC 9000」で標準化されたQUIC v1と機能上はまったく同じものです。 この提案仕様の目的は、主にふたつあります。 硬直化(ossification)の問題を緩和し将来のQUICバージョンをインターネットでデプロイしやすくする バージョンネゴシエーションを実行できるようにする 11月に実施されたIETF 112の後に、QUIC WGのメーリングリストで、この仕様にWGとして取り組んでいくコンセンサスが得られました。現在はWG Draftとなっています。 なお、Version 2はまだ2番目のバージョンということで便宜上そう呼んでいるようです。バージョン番号の正式なアサインは後に行われます。 硬直化(ossification)の問題の緩和 硬直化とは
新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
匿名かつ検証可能なPrivate Access Tokensの提案仕様 (プライベートアクセストークン) - ASnoKaze blog
「Private Access Tokens」という提案仕様が、Google, Apple, Fastly, Cloudflareの方々らの共著でIETFに提出されています。なお、すでに実装が進められているそうです。 この「Private Access Tokens」の一つのモチベーションに次のようなものがあります。 昨今、プライバシー保護の要求は高まっており、ユーザのIPアドレスを秘匿する、iCloud Private RelayやOblivious HTTPといった技術が出てきています。いままではIPアドレスベースでアクセスレートリミットを行っていましたが、 そのような環境でも、アクセスのレートリミットを設けたいというというのが一つの目的です。 それを、追加のユーザインタラクション無しに、かつユーザをトラッキングできないような匿名なトークンで行うというのがPrivate Access
HTTP/2の改定版仕様(RFC9113)の変更点について - ASnoKaze blog
2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。 作業中のドキュメントは「http2bis」として公開されている。 現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。 HTTPセマンティクス仕様を参照 もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。 それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。 セマンティクス側の変更点について以前書いた記事を参照ください。 asnokaze.hatenablog.com TLS 1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
