Meta tags:
description= プロトコル, W3Cの仕様やセキュリティなど;
keywords= IETF W3C プロトコル;
Headings (most frequently used words):
structured, http, field, for, one, の提案仕様, codes, time, 概要, bound, origin, fields, retrofit, おまけ, 背景, ビット, ipヘッダの, ct, valuesとしてマップする, values, httpsレコードの使用, その他のトピック, ce, asnokaze, quicのack, ecn, dns, 通信の開始, チャネル, ストリームの利用, 登場人物, 通信の流れ, パフォーマンス, リプレイ攻撃対策, relay, resourceの転送先について, 暗号化まわり, 背景と目的, greasingについて, the, 新しいステータスコード, quicにおける, 明示的な輻輳シグナルを受け取る, ecn対応, 3コネクション上でsshを実行するssh3プロトコル, dnsプロトコルの拡張性を担保するgreasingの提案, rfc, 9458, oblivious, の仕組みについて, について, 420, in, requester, impaired, example, アーキテクチャ, プロトコル, 実装, blog, greasing, protocol, extension, points, valuesとしてパースする,
Text of the page (most frequently used words):
http (41), 2023 (17), rfc (16), #oblivious (16), 2024 (14), #structured (14), 2016 (13), 2017 (13), 2022 (13), 2020 (13), 2019 (13), 2018 (13), 2021 (13), 2015 (12), #読者になる (12), #gateway (12), #example (12), #field (12), #asnokaze (11), #relay (11), for (11), https (10), 2014 (10), 2013 (10), #content (10), item (9), 2012 (8), プロトコル (8), dns (8), com (8), hpke (7), 2010 (7), もっと読む (7), 広告を非表示にする (7), ietf (7), コメントを書く (7), retrofit (6), time (6), #fields (6), request (6), draft (6), the (6), internet (6), type (6), 2011 (6), ssh (5), key (5), list (5), message (5), ohttp (5), target (5), one (5), requester (5), org (5), length (5), encode (5), blog (5), google (4), quic (4), resourceは (4), impaired (4), ipアドレス (4), protocol (4), authentication (4), origin (4), bound (4), codes (4), ssh3 (4), 閉じる (3), points (3), code (3), 420 (3), proxy (3), これは (3), signature (3), erratic (3), channel (3), 例えば (3), scheme (3), date (3), and (3), extension (3), basic認証 (3), apple (3), greasing (3), symmetric (3), cookie (3), congestion (3), algorithms (3), hdr (3), resource (3), ecn (3), ipヘッダの (3), カプセル化 (3), concat (3), tls (3), values (3), されたhttpリク (3), location (2), oauth (2), modified (2), req (2), username (2), info (2), 4443 (2), そこで (2), encapsulated (2), above (2), enc (2), ドメイン (2), sctxt (2), 読者をやめる (2), 747723 (2), since (2), secure (2), match (2), cdn (2), これにより (2), 0x3a (2), httpリク (2), 0x2a (2), 0x1a (2), messages (2), リプレイ攻撃 (2), マッピング (2), 先述の通り (2), トを受け取り (2), 処理をして (2), httpレスポンスを返す (2), resource宛のhttpリク (2), conversation (2), svc (2), clientは (2), valuesとしてマップする (2), uri (2), post (2), host (2), clientの (2), chrome (2), 0x0a (2), の提案仕様 (2), について (2), 例としては次のとおりです (2), おまけ (2), ecn対応 (2), experience (2), 明示的な輻輳シグナルを受け取る (2), quicにおける (2), という提案仕様が提出されています (2), detected (2), 9458 (2), 3コネクション上でsshを実行するssh3プロトコル (2), dnsプロトコルの拡張性を担保するgreasingの提案 (2), が利用できる (2), 2009 (2), の仕組みについて (2), public (2), quicのack (2), 読者です (2), tos (2), ack (2), しかし (2), requests (2), web (2), フィールドをecn用に, 手法についてはもちろん守備範囲に入っていません, ラッキング, コネクションは, 2ビット使用します, の目的です, rfc2481において, 例えばあるサービスで, ect0と呼ばれる, ログアウトして別アカウントとして再ログインすると, が起こっている事を示すのに使用します, ecnに対応している事を示すのに使用します, サービス側には同じ人物であることが分かってしまいます, それぞれect1, 2以降複数のhttpリク, ecn非対応, このようなユーザを識別する情報をさらに隠すのが, 一連の通信が同一ユーザであることを識別するのに使用できます, 通信の暗号化によりほとんどが保護されています, トにコネクションを再利用する, フレームタイプとして0x03を使用します, ベンダーが実装を行っています, quicではackフレームにecn, 各ブラウザベンダーおよび, はユーザのプライバシを向上するための技術であり, countsの情報を格納します, 幾つかの記事があがっています, ecn情報を持つackは, 取り組みについては, リレーを採用, fastly, ユーザーのオンラインプライバシー保護を強化するプライバシーサンドボックスのイニシアチブに, firefox, prio, deploy, partnering, privacy, built, ceと呼ばれ, の中身に触れていく, 今回は仕様の観点で, 背景と目的, 幾つか懸念が残っています, 通信観点のプライバシーについては, 短期的に同一ユーザを識別するのに使用できる, 通信以外のト, resourceにアクセスを行いたい者, アプリケーションレイヤなど, その方法は, トを暗号化するために, あるtarget, ecnに対応したネットワーク機器は, エンコード, が起こると該当のパケットにおいて, representation, binary, 9292, resourceにpostします, そのデータを暗号化して, その後, で定義されています, します, resourceの鍵情報を取得しておきます, fieldのce, ビットをセットする, ではサーバ側はquic, ecn対応がデプロイされており, トをまずバイナリ表現に, での実装も進められている事が報告されています, mailarchive, 9000, net, quicには, 経路上のスイッチから明示的な, シグナルを受け取る, explicit, notification, 別経路で事前に, 9458では入手方法は定義されていないが, 受信したipヘッダのce, httpの全体概要は次のとおりです, 登場人物, ceの受信数をピアに通知します, httpの通信の開始者, ビット, client, トの中身は分からない, は分かるが, ecnを受け取ったエンドポイントは, httpの中継者, が起こっている事を把握し, は分からない, 送信量を下げる, トの中身を取り出すことが出来る, 実際のhttpリク, レコードをいる手法が別, httpの終端者, resourceから実際のhttpリク, ビットがセットされている場合, パケットの送信者にフィードバックするため, ベンダーなどが担っている例があります, ecnでそれを通知する, httpの仕組みでユーザのプライバシーが保護されます, それにより, resourceは独立した別の組織によって運営されていることを前提としています, resourceと, ここで, 通信の流れ, 9540, になっている, ランダムな値を使ってしまうと, countsとしてect, 通信の秘匿, 拡張connectメソッドを使ってssh3通信を開始します, パケットのreordaringが不要なquic, datagram, user, rfc9221, フォワ, httpを使うことでロードバランサ, resourceは転送する, などが利用できます, ホスト名やパスによるルーティング, エンドポイントの秘匿, を使うことで, そこでサービスが動いてることを隠せる, 認証方式として, protocol疑似ヘッダには, からするとただのhttp通信にみえる, 拡張connectメソッドを送信する際にhttpレイヤでの認証を実行します, httpの認証方式をサポートする, では以下のような通信になります, ストリームの利用, quicのメリットが享受できる, チャネル, トストリームとは別で新しく開始します, webtransportと同様に, クライアント開始の双方向ストリームをチャネルと利用します, 双方向ストリームには最初に次のとおりに書き込まれます, この時, が指定されます, size, される, のメッセージを乗っけるわけのではなく拡張connectメソッド, レスポンスに, 3のリク, アーキテクチャ, sshv2は下記のとおりです, 3のコネクションをssh3用に利用する形になります, webtransportの利用も検討されていますが, 現状はhttp, ssh3では次のとおりになります, 3レイヤで処理する, url関連はhttp, 認証や, チャネルの機能はquicレイヤに, パスには, トランスポートはquicが担い, 3を利用する仕様になっています, フォールバック先としてhttp, 2を利用, rfc8441, ポート, ーディング時に, 通信の開始, 拡張connectメソッドをsettingsで有効にします, datagramおよび, その際に, 3通信を開始します, エンドポイントに対してquicコネクションを確立し, テンプレートでユーザ名を指定できるようになっています, が変わってもコネクションを維持できる, maximum, youtube, を拡張した際, 実装や中継機器などが存在します, 実インターネットでは様々な, 無視するための拡張を定義して送信するのがgreasingです, の未知の拡張を無視するという挙動を実装に意識させるために, 実際にインターネットでの疎通問題として注目されました, 3策定時に, tls1, suitesおよびalpn識別子に次の値を付与して良いことになっています, 例えばcipher, 8701でgreasing用の値が定義されており, over, connections, 最初に述べた通り, ただし, サポートしてない拡張値を無視する要件が守られていることを保つようにしています, ではすでにecnに対応しているため, ecnを送ってきます, 次の値をgreasing対象として検討している, 実装がそれを特別扱いできてしまいます, 一方で予約値を使うと, 将来利用される番号と衝突してしまう場合の影響が未知数となってしまいます, でquicを復号すると次のようにみることが出来ます, をつかって, greasingようの値を予約するかは現在検討中になっているようです, greasingにランダムな値を使うか, と同様予約値を与えるので十分なんじゃないかなとは思います, 個人的には, wireshark, 既存実装にそれらの拡張が無視される事が期待されます, 実装や中継機器の予期せぬ動作を引き起こし, 0xaf3627e6, あくまで提案段階ですので今後変わる可能性もあります, ssh3ではhttp, value, signal, 3を使うことにより以下の特徴を持ちます, 3コネクション上で, チャネルが開設したあとはsshv2同様のメッセージを投げることが出来ます, を実行する, で必要な値ですね, を定義しています, それ以外は, トストリームとの紐づけを行う事ができます, idとして, という名称を仕様中で使用していますが, shell, github, 実装も公開されている, に提出されている, という提案が, の拡張性を担保するために, オペコードやリソースレコードタイプなどにランダムな値が設定される可能性がある, greasingについて, greasingという仕組みが導入される事があります, の将来の拡張性を担保するために, ミドルウェア, ossification問題と呼ばれる, の利用が阻害される事が知られています, 結果として新しい, resourceが設定されている, pkr, resourceにpostする, および, 新しいステータスコード, smsのワンタイムコードの自動入力が幅広く使われると便利になりますね, で議論は具体的には行われてないですが, 標準化まで進むと良いなーって思いました, で実装されているようです, impairment, your, exampleco, 747723が, でのみ自動入力されます, ではsmsやメールで発行するワンタイムコードのフォーマットを定義しています, そこに, httpステータスコード, report, smsで発行したワンタイムコードを, deepl, 与えられた入力に対して幻覚を見たり, 不正確な答えを返したり, 異なる答えを返したりといった行動を示すことがある, このようなaiが動作するスピードを考えると, 人間の要求者と同様に, aiの要求者の障害を検出することも重要である, 目的として, status, 重機などの機械やaiシステムが故障してることを示唆することを掲げています, 提案仕様のなかでも次のように書かれています, 送信者の障害によりサーバは処理を拒否したことを示します, 新しい, を定義する, 名を追加しています, に紐付けることでこのような攻撃を防ぐのが今回の目的です, ステータスコード, dateタイプをもつsf, unmodified, none, expires, etag, このように次のヘッダはマップしたものが定義されます, 784111777, dateを定義します, referer, sun, nov, 1994, last, set, こちらのサイトでも書かれているように, 昨今ではformの, 攻撃者がフィッシングの手口で入力させたid, passを正規サイトにインプットさせるとsmsコードを自動入力させる事ができます, akaki, webのログイン時にsmsでワンタイムコードを送信し, 入力させることがあります, autocomplete, 属性によりユーザエージェントがsmsのコードを自動入力してくれたりします, こちらの仕組みの標準化ということで良いかなと思います, developer, 勢から, というsmsで発行するワンタイムコードのフォーマットの提案仕様が, に提出されています, ある種のaiシステムは, rfc9457, dateヘッダは, ネゴシエーション, イベントレポート, mysql, 時刻同期, ヘッダ圧縮, mptcp, whatwg, 126, nginx, apache, w3c, spdy, tcp, 228, 引用をストックしました, 限定公開記事のため引用できません, 引用をストックできませんでした, 再度お試しください, ログイン, 引用するにはまずログインしてください, ストック一覧を見る, powered, 月別アーカイブ, ブログを報告する, hatena, 注目記事, ご意見先, リンク, 237, 形式での応答例です, 0239, html, application, problem, json, language, title, behavior, detail, potentially, dangerous, の定義なのでそのままなんですが, ボディは, 2023octdec, archives, カテゴリー, flano_yuki, 最新記事, このブログについて, flano_yukiをフォロー, プロトコルとかセキュリティとか, twitter, yuki, 次のページ, 著者によると, 元々のアイディアでは, トを送信した人間に問題があるというエイプリルフールネタとして書いていたみたいです, aiによる現実性があるとして通常の提案仕様として提出したとのことです, lists, gmt, すでに使われているhttpヘッダでパースできないものは, postのデータをそのまま, 詳しくは, kem, npk, 65532, configuration, トの暗号化にはhpkeが使用されます, を参照のこと, config, 暗号化まわり, relayで複数のoblivious, への転送をサポートするために, 6570, templateを使うように書かれていますが具体的な使用方法は書かれてなさそうです, クライアントやoblivious, identifier, aead, のurlを分かっている前提になっているのかなと思いました, kdf_id, network, with, khronos, レコードの使用, key_id, kem_id, aead_id, kdf, encode_str, bhttp, setupbases, seal, enc_request, 暗号化, relayは事前知識として, 送信先, filtering, typeは, 特にサーバの近くに配置することでオーバヘッドを抑えられると述べている, パフォーマンス, 幾つか仕様内にかかれているトピックを紹介する, その他のトピック, 以下逆向きに処理をしてレスポンスがclientに返る, なおcontent, res, httpでは暗号化及び遅延のオーバヘッドがあります, になる, resourceはclientからpostされたデータを復号し, バイナリ表現からデコードして通常のhttpリク, トに戻します, それをtarget, resourceに転送します, resourceをクライアントとサーバの間, resourceが転送先の, とも書かれています, resourceをどう選択するかは, 中には書かれていません, リソースと, リソース間の固定の, を前提としています, resourceの転送先について, トを一意に識別する方法はあります, トにdateヘッダフィールドを追加することが推奨されています, これにより時間を開けて再送信されたものを検知できるようになります, resourceはhttpリク, トの中身は見えないものの, resourceに対して, を行うことが出来ます, トの暗号化にしようされたnonceを用いることで, mechanism, selection, マップした値をいれられるものとします, 8941ではスコープには入っておりませんでした, そのままstructured, valuesとしてパースしても問題なさそうなヘッダを指定する, 戦略は2つあります, すでに使用されているhttpヘッダをstructured, valuesとしてパースすることを目的とした仕様です, 既存のhttpヘッダに適応することは, 既存のhttpヘッダもstructured, それ以外のものは, valuesとしてパースしようというのが, になります, パーサーを再利用可能にする, 新しいhttpヘッダを定義する際につどabnfで定義を与えるのではなく, valuesのtypeで構文定義を与えられるようにする, valuesの目的は主に2つあります, 新しくstructured, 具体例を見ると分かりやすいかと思います, tea, 構文エラー時の挙動の違い, alt, retry, after, などは実装や一部互換性の無い値が知られている, 値が空文字の場合エラーとなる, integerは15桁まで, dictionaryのパラメータキーとして大文字, valuesとしてパースする, 小文字を区別するケース, クオートのルール, ただし注意点があり, valuesとして扱う上で次のことを気をつけなければなりません, すでに使われているhttpヘッダでパースできそうなものは, 提案仕様のなかでこのように羅列されます, sugar, rum, 9523, レコードを介しoblivious, からkey, configを提供します, 7200, alpn, レコードの例, httpサポートを示し, well, config配布する方法については, という, で記述されています, でもrelay, resourceの検出及び設定はスコープ外, known, という提案仕様が出ているので簡単に紹介する, dict, httpでは, foo, bar, その仕様では, listやdictionaryといったタイプが定義されています, httpヘッダ, wgで, フィールド, の値を構造化データとして扱えるようにする, という仕様があります, 8941, 前提にある, についてまず触れる, のhttp, という機能に対応しています,
Text of the page (random words):
asnokaze blog asnokaze blog 読者になる asnokaze blog 2024 03 05 quicにおける 明示的な輻輳シグナルを受け取る ecn対応 quic 雑 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を受け取ったエンドポイントは 輻輳 が起こっている事を把握し 送信量を下げる ipヘッダの ct ce ビット rfc2481において ipヘッダの tos フィールドをecn用に 2ビット使用します 00 ecn非対応 01 10 ecnに対応している事を示すのに使用します それぞれect1 ect0と呼ばれる 11 ceと呼ばれ 輻輳 が起こっている事を示すのに使用します quicのack ecn quicではackフレームにecn countsの情報を格納します ecn情報を持つackは フレームタイプとして0x03を使用します ecn countsとしてect ceの受信数をピアに通知します example 最初に述べた通り google youtube ではすでにecnに対応しているため ack ecnを送ってきます wireshark でquicを復号すると次のようにみることが出来ます asnokaze 2024 03 05 00 09 読者になる 広告を非表示にする もっと読む コメントを書く 2024 03 04 http 3コネクション上でsshを実行するssh3プロトコル quic http internet draft 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 を使うことで そこでサービスが動いてることを隠せる httpを使うことでロードバランサ ホスト名やパスによるルーティング が利用できる ポート フォワ ーディング時に パケットのreordaringが不要なquic datagram rfc9221 が利用できる http 3のリク エス ト レスポンスに ssh のメッセージを乗っけるわけのではなく拡張connectメソッド rfc8441 をつかって http 3のコネクションをssh3用に利用する形になります なお webtransportの利用も検討されていますが 現状はhttp 3を利用する仕様になっています フォールバック先としてhttp 2を利用 アーキテクチャ sshv2は下記のとおりです ssh3では次のとおりになります 認証や url関連はhttp 3レイヤで処理する トランスポートはquicが担い チャネルの機能はquicレイヤに マッピング される プロトコル 通信の開始 エンドポイントに対してquicコネクションを確立し http 3通信を開始します その際に quic datagramおよび http 3 拡張connectメソッドをsettingsで有効にします 拡張connectメソッドを使ってssh3通信を開始します この時 protocol疑似ヘッダには ssh3 が指定されます パスには uri テンプレートでユーザ名を指定できるようになっています https example org 4443 ssh3 user username https proxy example org 4443 ssh3 username また 拡張connectメソッドを送信する際にhttpレイヤでの認証を実行します 先述の通り 認証方式として basic認証 oauth 2 0 signature http authentication scheme などが利用できます http basic認証 では以下のような通信になります チャネル ストリームの利用 クライアント開始の双方向ストリームをチャネルと利用します webtransportと同様に リク エス トストリームとは別で新しく開始します 双方向ストリームには最初に次のとおりに書き込まれます channel signal value i 0xaf3627e6 conversation id i channel type length i channel type maximum message size i ssh messages conversation idとして リク エス トストリームとの紐づけを行う事ができます それ以外は ssh で必要な値ですね チャネルが開設したあとはsshv2同様のメッセージを投げることが出来ます 実装 実装も公開されている github com asnokaze 2024 03 04 00 06 読者になる 広告を非表示にする もっと読む コメントを書く 2024 02 24 dnsプロトコルの拡張性を担保するgreasingの提案 dns internet draft dns プロトコル の拡張性を担保するために greasing protocol extension points in the dns という提案が ietf に提出されている これにより オペコードやリソースレコードタイプなどにランダムな値が設定される可能性がある 背景 greasingについて プロトコル の将来の拡張性を担保するために greasingという仕組みが導入される事があります 実インターネットでは様々な ミドルウェア 実装や中継機器などが存在します プロトコル を拡張した際 既存実装にそれらの拡張が無視される事が期待されます ただし 実装や中継機器の予期せぬ動作を引き起こし 結果として新しい プロトコル の利用が阻害される事が知られています ossification問題と呼ばれる これは tls1 3策定時に 実際にインターネットでの疎通問題として注目されました そこで プロトコル の未知の拡張を無視するという挙動を実装に意識させるために 無視するための拡張を定義して送信するのがgreasingです 例えば tls では rfc 8701でgreasing用の値が定義されており 例えばcipher suitesおよびalpn識別子に次の値を付与して良いことになっています 0x0a 0x0a 0x1a 0x1a 0x2a 0x2a 0x3a 0x3a これにより サポートしてない拡張値を無視する要件が守られていることを保つようにしています greasing protocol extension points in the dns greasing protocol extension points in the dns では 次の値をgreasing対象として検討している greasingにランダムな値を使うか greasingようの値を予約するかは現在検討中になっているようです ランダムな値を使ってしまうと 将来利用される番号と衝突してしまう場合の影響が未知数となってしまいます 一方で予約値を使うと 実装がそれを特別扱いできてしまいます 個人的には tls と同様予約値を与えるので十分なんじゃないかなとは思います asnokaze 2024 02 24 00 54 読者になる 広告を非表示にする もっと読む コメントを書く 2024 02 13 rfc 9458 oblivious http の仕組みについて http oblivious http はユーザのプライバシを向上するための技術であり 各ブラウザベンダーおよび cdn ベンダーが実装を行っています 取り組みについては 幾つかの記事があがっています google chrome ユーザーのオンラインプライバシー保護を強化するプライバシーサンドボックスのイニシアチブに fastly oblivious http リレーを採用 built for privacy partnering to deploy oblivious http and prio in firefox 今回は仕様の観点で プロトコル の中身に触れていく 背景と目的 通信観点のプライバシーについては 通信の暗号化によりほとんどが保護されています しかし 幾つか懸念が残っています ipアドレス は 短期的に同一ユーザを識別するのに使用できる コネクションは 一連の通信が同一ユーザであることを識別するのに使用できます http 2以降複数のhttpリク エス トにコネクションを再利用する 例えばあるサービスで ログアウトして別アカウントとして再ログインすると サービス側には同じ人物であることが分かってしまいます このようなユーザを識別する情報をさらに隠すのが oblivious http の目的です アプリケーションレイヤなど 通信以外のト ラッキング 手法についてはもちろん守備範囲に入っていません 概要 oblivious httpの全体概要は次のとおりです 登場人物 client oblivious httpの通信の開始者 target resourceにアクセスを行いたい者 relay resource oblivious httpの中継者 clientの ipアドレス は分かるが httpリク エス トの中身は分からない gateway resource oblivious httpの終端者 実際のhttpリク エス トの中身を取り出すことが出来る clientの ipアドレス は分からない target resource gateway resourceから実際のhttpリク エス トを受け取り 処理をして httpレスポンスを返す ここで relay resourceと gateway resourceは独立した別の組織によって運営されていることを前提としています それにより oblivious httpの仕組みでユーザのプライバシーが保護されます relay resourceは 先述の通り cdn ベンダーなどが担っている例があります 通信の流れ clientは あるtarget resource宛のhttpリク エス トを暗号化するために 別経路で事前に gateway resourceの鍵情報を取得しておきます rfc 9458では入手方法は定義されていないが dns https レコードをいる手法が別 rfc になっている rfc 9540 clientは target resource宛のhttpリク エス トをまずバイナリ表現に エンコード します その方法は rfc 9292 binary representation of http messages で定義されています その後 そのデータを暗号化して relay resourceにpostします post request example net proxy http 1 1 host proxy example org content type message ohttp req content length 78 content is the encapsulated request above relay resourceは postのデータをそのまま gateway resourceにpostする relay resourceは転送する gateway resourceが設定されている post oblivious request http 1 1 host example com content type message ohttp req content length 78 content is the encapsulated request above gateway resourceはclientからpostされたデータを復号し バイナリ表現からデコードして通常のhttpリク エス トに戻します それをtarget resourceに転送します target resourceは httpリク エス トを受け取り 処理をして httpレスポンスを返す 以下逆向きに処理をしてレスポンスがclientに返る なおcontent typeは message ohttp res になる その他のトピック 幾つか仕様内にかかれているトピックを紹介する パフォーマンス oblivious httpでは暗号化及び遅延のオーバヘッドがあります relay resourceをクライアントとサーバの間 特にサーバの近くに配置することでオーバヘッドを抑えられると述べている リプレイ攻撃 対策 relay resourceはhttpリク エス トの中身は見えないものの gateway resourceに対して リプレイ攻撃 を行うことが出来ます カプセル化 されたhttpリク エス トの暗号化にしようされたnonceを用いることで リク エス トを一意に識別する方法はあります また カプセル化 されたhttpリク エス トにdateヘッダフィールドを追加することが推奨されています これにより時間を開けて再送信されたものを検知できるようになります relay resourceの転送先について relay resourceが転送先の gateway resourceをどう選択するかは rfc 中には書かれていません oblivious relay リソースと oblivious gateway リソース間の固定の 1 対 1 マッピング を前提としています とも書かれています クライアントやoblivious relayは事前知識として 送信先 のurlを分かっている前提になっているのかなと思いました また oblivious relayで複数のoblivious gateway への転送をサポートするために rfc 6570 uri templateを使うように書かれていますが具体的な使用方法は書かれてなさそうです 暗号化まわり カプセル化 されたhttpリク エス トの暗号化にはhpkeが使用されます 詳しくは rfc を参照のこと key configuration hpke symmetric algorithms hpke kdf id 16 hpke aead id 16 key config key identifier 8 hpke kem id 16 hpke public key npk 8 hpke symmetric algorithms length 16 4 65532 hpke symmetric algorithms 32 暗号化 hdr concat encode 1 key_id encode 2 kem_id encode 2 kdf_id encode 2 aead_id info concat encode_str message bhttp request encode 1 0 hdr enc sctxt setupbases pkr info ct sctxt seal request enc_request concat hdr enc ct https レコードの使用 dns https レコードを介しoblivious httpサポートを示し key config配布する方法については rfc 9523 a secure selection and filtering mechanism for the network time protocol with khronos という rfc で記述されています この rfc でもrelay resourceの検出及び設定はスコープ外 https レコードの例 svc example com 7200 in https 1 alpn h2 ohttp また target resourceは well known ohttp gateway からkey configを提供します asnokaze 2024 02 13 00 17 読者になる 広告を非表示にする もっと読む コメントを書く 2024 01 31 retrofit structured fields for http について http internet draft 雑 ietf のhttp wgで retrofit structured fields for http という提案仕様が出ているので簡単に紹介する structured field values for http 前提にある structured field values for http についてまず触れる httpでは httpヘッダ フィールド の値を構造化データとして扱えるようにする rfc 8941 structured field values for http という仕様があります その仕様では listやdictionaryといったタイプが定義されています 例 example list sugar tea rum example dict a 0 b c foo bar structured field valuesの目的は主に2つあります 新しいhttpヘッダを定義する際につどabnfで定義を与えるのではなく structured field valuesのtypeで構文定義を与えられるようにする パーサーを再利用可能にする 既存のhttpヘッダに適応することは rfc 8941ではスコープには入っておりませんでした 既存のhttpヘッダもstructured field valuesとしてパースしようというのが retrofit structured fields for http になります retrofit structured fields for http retrofit structured fields for http では すでに使用されているhttpヘッダをstructured field valuesとしてパースすることを目的とした仕様です 戦略は2つあります そのままstructured field valuesとしてパースしても問題なさそうなヘッダを指定する それ以外のものは 新しくstructured field valuesとしてマップする 具体例を見ると分かりやすいかと思います structured field valuesとしてパースする すでに使われているhttpヘッダでパースできそうなものは 提案仕様のなかでこのように羅列されます ただし注意点があり structured field valuesとして扱う上で次のことを気をつけなければなりません dictionaryのパラメータキーとして大文字 小文字を区別するケース クオートのルール 構文エラー時の挙動の違い integerは15桁まで 値が空文字の場合エラーとなる alt svc content length retry after などは実装や一部互換性の無い値が知られている structured field valuesとしてマップする すでに使われているhttpヘッダでパースできないものは マップした値をいれられるものとします 例えば dateヘッダは date sun 06 nov 1994 08 49 37 gmt dateタイプをもつsf dateを定義します sf date 784111777 このように次のヘッダはマップしたものが定義されます sf content location item sf cookie list sf date item sf etag item sf expires item sf if match list sf if modified since item sf if none match list sf if unmodified since item sf last modified item sf location item sf referer item sf set cookie list asnokaze 2024 01 31 01 28 読者になる 広告を非表示にする もっと読む コメントを書く 2023 12 13 origin bound one time codes の提案仕様 雑 web internet draft 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で発行したワンタイムコードを ドメイン に紐付けることでこのような攻撃を防ぐのが今回の目的です origin bound one time codes origin bound one time codes ではsmsやメールで発行するワンタイムコードのフォーマットを定義しています そこに ドメイン 名を追加しています 例としては次のとおりです 747723が example com でのみ自動入力されます 747723 is your exampleco authentication code example com 747723 おまけ apple および google で実装されているようです smsのワンタイムコードの自動入力が幅広く使われると便利になりますね まだ ietf で議論は具体的には行われてないですが 標準化まで進むと良いなーって思いました asnokaze 2023 12 13 00 42 読者になる 広告を非表示にする もっと読む コメントを書く 2023 12 12 新しいステータスコード 420 requester impaired の提案仕様 http internet draft 新しい httpステータスコード 420 requester impaired を定義する an http status code to report requester impairment という提案仕様が提出されています これは 送信者の障害によりサーバは処理を拒否したことを示します 目的として 重機などの機械やaiシステムが故障してることを示唆することを掲げています 提案仕様のなかでも次のように書かれています ある種のaiシステムは 与えられた入力に対して幻覚を見たり 不正確な答えを返したり 異なる答えを返したりといった行動を示すことがある このようなaiが動作するスピードを考えると 人間の要求者と同様に aiの要求者の障害を検出することも重要である deepl 例 ステータスコード の定義なのでそのままなんですが 例としては次のとおりです ボディは rfc9457 形式での応答例です http 1 1 420 requester impaired content type application problem json content language en type https example com erratic requests title requester impaired erratic behavior detected detail potentially dangerous and erratic requests detected おまけ 著者によると 元々のアイディアでは リク エス トを送信した人間に問題があるというエイプリルフールネタとして書いていたみたいです しかし aiによる現実性があるとして通常の提案仕様として提出したとのことです https lists w3 org archives public ietf http wg 2023octdec 0239 html asnokaze 2023 12 12 00 07 読者になる 広告を非表示にする もっと読む コメントを書く 次のページ yuki プロトコルとかセキュリティとか https twitter com flano_yuki 読者です 読者をやめる 読者になる 読者になる flano_yukiをフォロー このブログについて 検索 最新記事 quicにおける 明示的な輻輳シグナルを受け取る ecn対応 http 3コネクション上でsshを実行するssh3プロトコル dnsプロトコルの拡張性を担保するgreasingの提案 rfc 9458 oblivious http の仕組みについて retrofit structured fields for http について カテゴリー internet draft 237 http 228 tls 55 quic 92 w3c 63 apache 7 nginx 24 web 56 cookie 17 dns 17 whatwg 13 http ネゴシエーション 5 mptcp 7 http ヘッダ圧縮 6 時刻同期 7 mysql 1 イベントレポート 4 spdy 15 雑 126 tcp 8 月別アーカイブ 2024 2024 3 2024 2 2024 1 2023 2023 12 2023 11 2023 10 2023 9 2023 8 2023 7 2023 6 2023 5 2023 4 2023 3 2023 2 2023 1 2022 2022 12 2022 11 2022 10 2022 9 2022 8 2022 7 2022 6 2022 5 2022 4 2022 3 2022 2 2022 1 2021 2021 12 2021 11 2021 10 2021 9 2021 8 2021 7 2021 6 2021 5 2021 4 2021 3 2021 2 2021 1 2020 2020 12 2020 11 2020 10 2020 9 2020 8 2020 7 2020 6 2020 5 2020 4 2020 3 2020 2 2020 1 2019 2019 12 2019 11 2019 10 2019 9 2019 8 2019 7 2019 6 2019 5 2019 4 2019 3 2019 2 2019 1 2018 2018 12 2018 11 2018 10 2018 9 2018 8 2018 7 2018 6 2018 5 2018 4 2018 3 2018 2 2018 1 2017 2017 12 2017 11 2017 10 2017 9 2017 8 2017 7 2017 6 2017 5 2017 4 2017 3 2017 2 2017 1 2016 2016 12 2016 11 2016 10 2016 9 2016 8 2016 7 2016 6 2016 5 2016 4 2016 3 2016 2 2016 1 2015 2015 12 2015 11 2015 10 2015 9 2015 8 2015 6 2015 5 2015 4 2015 3 2015 2 2015 1 2014 2014 12 2014 10 2014 8 2014 6 2014 5 2014 4 2014 3 2014 2 2014 1 2013 2013 12 2013 8 2013 7 2013 6 2013 5 2013 4 2013 3 2013 2 2013 1 2012 2012 12 2012 11 2012 8 2012 7 2012 4 2012 2 2012 1 2011 2011 12 2011 11 2011 8 2011 5 2011 2 2010 2010 12 2010 10 2010 9 2010 8 2010 6 2010 5 2009 2009 11 リンク ご意見先 注目記事 asnokaze blog powered by hatena blog ブログを報告する 引用をストックしました ストック一覧を見る 閉じる 引用するにはまずログインしてください ログイン 閉じる 引用をストックできませんでした 再度お試しください 閉じる 限定公開記事のため引用できません 読者です 読者をやめる 読者になる 読者になる
|