Extensibility」という仕様が長らく議論されてきました。2020年1月に無事RFC8701になったので、その話を簡単に紹介する。実際にいくつかの実装がすでに使っている。日記なお、GREASEの仕組み自体はTLS以外にも他のプロトコルでも導入が検討されてたりします(HTTP2の例)。GREASETLS1.3の標準化をすすめる中で新しいTLS拡張などを定義しました。未知のTLS拡張は無視されなければなりませんが、正しく処理せず接続を拒否する実装などがありました。そのため、未知のTLS拡張などを正しく無視するのを確認する用の番号群を定義するのがGREASEです。バージョン番号などにGREASE用の値が確保されます。クライアントはそれらの値を含めてネゴシエーションしていいことになっています。その値をサーバが選んでしまった場合は切断しなければなりません。サーバはGREASE用の値を特別扱いせず未知の値として無視しなければなりません。Policy」という仕様をサポートしてるようなので、簡単に試してみる。PolicyContent-Security-PolicyやFeature-Policyといった、ブラウザがページを表示する際に機能を制限したりセキュリティ上の制限を与える機能があります。これらの機能はレスポンスヘッダに該当のヘッダを付けることでポリシーを適応させることができます。そのため、これらの機能をもれなく適応するにはレスポンスの都度きちんとこれらのヘッダーを付加しなければなりません。CSPやFeature-Policyのヘッダは1キロバイトになるほど多いものもあります。HTTP/2やHTTP/3の場合はヘッダ圧縮がありますが動的ヘッダテーブルを圧迫してしまい、効率を悪くしてしまいます。Policyを適応するために、まずSec-Origin-Policyレスポンスヘッダで適応するポリシーを通知します。httpsでないとダメです。policy=example-policyブラウザはこのレスポンスヘッダを見て、該当するポリシーファイルを参照しに行きます。「https://<ドメイン名>/.well-know/origin-policy/example-policy」ポリシーファイルは以下のように、featuresとcontent_securityにそれぞれのポリシーを記述するだけです。Policyによってジオロケーションへのアクセスを禁止していますので、コンソールからジオロケーションにアクセスしようとすると、ちゃんとブロックされることが確認できました。ポリシーに沿ってブロックしました。ポリシーの適用を求めていますが、このポリシーは現在適用することができません。QUIC"の標準化及び、Chromiumでの実装が進んでいます。今回はクライントを書いて、Chromiumに同梱されているquic_transport_simple_serverと通信してみました。buildフェッチに時間がかかります。DATAGRAMフレームのサポートが必須です。実際にはトランスポートパラメータでmax_datagram_frame_sizeを指定する必要があります。今回はDATAGRAMフレームをサポートしてる、PythonのQUICライブラリ「aioquic」を利用します。(exampleとして、DATAGRAM検証用プロトコル"siduck"実装が含まれてるのも選んだ理由です)インストール方法は「aioquicのgithubリポジトリ」を参照。クライアントを作成します。デバックログをファイルに出力、-lは復号用の鍵ファイルをファイルに出力)quic_transport_simple_serverにデータを送って、Echoを受信することに成功しました。ソース的には未実装?)終わりにとりあえず、通信できるところまでうまく行ったので、ちゃんとクライアントを実装したい。Contentsでブロック対象になる話があります。http://でリンクされたファイルをダウロードしようとするとブラウザによってブロックされます。(デベロッパーツールには表示される)。その挙動について簡単に確認してみます。ダウンロード用リンクがあります。zipドキュメントによるとファイルは拡張子で判断し、実行可能ファイルなどリスクの高いものをブロックすると書いてあります。https://なページから、http://なリンクをクリックしてzipファイルをダウンロードしようとするとブロックされます。見た目上は何も起こりません。同様に、右クリックにて"名前をつけてリンク先を保存"しようとしても何も起こりません。デベロッパーツールには以下のように、ブロックした旨ログが出ます。80ですとちゃんとダウンロードできます。画像aリンクにdownload属性を付与した場合の動作も確認します。Contentsの場合は、新しいタブが開きダウンロードは開始されません。https://のリンクの場合はダウンロードが開始されます。Contentsでも通常通り行えます。Messages」という仕様が提案されています。HTTPメッセージへの署名は、様々なところで行われていますが、それぞれ独自の方式で行われています。DPoPなどでHTTPメッセージへの署名が行われています。Exchanges」といったところでも署名が行われています。TLSではだめなのかという話もありますが、TLSを用いることでHTTPメッセージの機密性および完全性は保護されますが、TLS終端プロキシなどを経由するとそれ移行の部分で通信の完全性は担保されません。クライアントとサーバ間でHTTPメッセージの完全性を保つために、HTTPメッセージに署名する方法が必要です。HTTPはProxyなどを通ると、viaヘッダやX-Forwarded-Forヘッダが足されたり、順序が入れわかったり、同名のヘッダが結合されたりされます。Messages」です。Richer氏のもと再出発となっています。同名の仕様ですので注意が必要です。今回は正規化方法を説明し、残りふたつは合わせて説明します。HTTPメッセージの正規化Proxyによって、HTTPヘッダは順番が入れ替わったり、同名のヘッダが結合されたりします。その他にも実装によって、大文字小文字の変換、HTTP/1.1とHTTP/2での変換、obs-fold(行頭空白を用いた改行)の追加・削除、などさまざまな変形が行われる可能性があります。そのため、正規化処理を行います。must-revalidate次のようにソート、正規化されます。HTTPリクエストの場合はメソッドやパスも署名対象であり、リクエストターゲットも正規化されます。その例は次のとおりです。HTTPボディはどうするのかというと、digestヘッダを用いてボディのダイジェストをHTTPヘッダに組み入れることでボディも合わせて署名対象に入れることができます。署名の対象はheadersで指定された、正規化されたメタデータ及びヘッダ値を改行(\n)で連結したものです。whitespace.検証する側は同様に、HTTPメッセージの正規化を行い署名値を計算することによって検証を行います。振り返り今年も大晦日になりました。例年通り振り返ります。今年も全52記事と、たくさん書いた。一方でイベント類やアウトプットは少なかった気がする。今年特に印象深いのが、「ブログ、読んでますよー」とお声がけいただく機会が何度かあった。本当に励みになるので感謝しかない。登壇や関わったイベントは多くありませんでした。connpassHTTP/3やQUIC、WebTransportなどでお話できることもあるとおもいますので、話者をお探しでしたらお声がけいただければお手伝いできればなーと思う所存です。(自分より適任者は多そうですが...)一方で、少人数のクローズドなディスカッションを定期的に開催したりと、ちょっとは活動した。(記事参照)を書いたりしたが、手を動かす系は相変わらず弱かった。プロトコルのIssue立てたりして直してもらったりしたのは良かった。記事HTTP/3やQUIC関連の仕様をたくさん書いた。目次はじめにUDPロードバランサラウンドロビン方式ハッシュ方式ハッシュの再計算コネクションマイグレーションが出来ないその他の懸念事項NLBを用いたハッシュの再計算の実験QUICの負荷分散についてはじめにHTTP/3はQUICというトランスポートプロトコルを利用しています。QUICはUDPを利用していますが、QUIC自体はステートフルなプロトコルです。ステートフルなQUICを、QUICを解釈しないUDPロードバランサでバランシングしようとするにはいくつかの注意問題点があります。今回は簡単に説明し、NLBでも実験をしてみました。もとにハッシュを計算し、振り分け先を決定しますラウンドロビン方式ステートレスなUDPパケットを順々に各サーバに振り分けます。QUICコネクションを処理するサーバが変わってしまうため、ハンドシェイクすら成功しないでしょう。一緒であれば、同じサーバに振り分けられるため、一見うまくいくように見えます。いくつかの注意点がありますハッシュの再計算1つめはハッシュの再計算が起こる点です。UDPロードバランサは、特定のタイミングでハッシュの再計算が発生しえます。振り分け先のサーバが増減した際や、設定を更新した際に振り分け表がクリアされるロードバランサもあります(*)ハッシュの計算が変わった場合、既存の通信の振り分け先が変わってしまいます。resetとなります(QUICパケットは暗号化する必要があり、鍵を失った際の切断方法)。実際は振り分け先の台数に依存しますが、現在扱っている接続のうち多くの接続が切断されることになります。コネクションマイグレーションが出来ない2つめはコネクションマイグレーションが出来ない点です。QUICのコネクションマイグレーションは以前書いたとおりです。asnokaze.hatenablog.comQUICでは送信元IPや送信元ポートが変わっても通信をそのまま継続できます。そのため、クライアントはそれらが変わったとしてもそのまま通信を継続しようとします。resetを行うことになります。resetとなります。NATの変換テーブルから消えてる場合ですので、通信がない時間がある場合に起こります。再接続で問題ないケースが多いでしょう。PINGフレームを送ることで回避もできそうです。その他の懸念事項その他にもいくつかの懸念事項があります例えばUDPロードバランサは、コネクションクローズタイミングが分かりません。QUICはコネクションをクローズしたつもりはないのに、UDPロードバランサが割当表からエントリを先に削除してしまうと、別のサーバに割り振られてしまいます。これはPINGフレームを定期的に送ることで回避できます。NLBでUDPロードバランサはハッシュを用いて振り分けを行っています(Docs)、ハッシュの再計算が発生するか確認します。今回は簡易的に、HTTP/3ではなく単純にUDPを使用して実験を行います。UDPで指定されたNLBに定期的にメッセージを送ります。UDPでリッスンし、UDPパケットが届くと、自身のホスト名を返します。(手抜きで、全部unhealtyで均等に処理させる)ip-10-xxx-yyy-232ip-10-xxx-yyy-181ip-10-xxx-yyy-225ip-10-xxx-yyy-74ip-10-xxx-yyy-119clientを実行すると、5つの送信元ポートでメッセージを送信し受信するのを、数秒おきに行います。5つの送信元ポートは同じ順序で使うため、縦に同じホストが表示されます。インスタンスの増減を行ったタイミングで、ハッシュ計算が代わり振り分け先ホストが変わるのが確認できます。(QUIC)をNLBで負荷分散するのは適切とは言えません。QUICの負荷分散についてQUICのロードバランシングについてはIETFでも議論が行われています。基本的にはQUICを解釈してロードバランスを行います。QUICのコネクションIDにサーバの識別子を暗号化して入れておき、それを見て適切なサーバに振り分けるなどの方法が考えられています。その他にも、間違ったサーバに振り分けられた際に、自分宛てでないパケットを適切なサーバに転送するなども考えられますが、構成が複雑になってしまいそうですね。いうことで、通常はHTTP/3を終端しバックエンドにはHTTP/1.1で振り分けとかを行う構成が普通かなとは思います。一般的なUDPロードバランサすべてに当てはまるわけではないので、表現を変更しました。以前「UDPロードバランサは、特定のタイミングでハッシュの再計算を行います。振り分け先のサーバが増減した際や、設定を更新した際にハッシュの再計算が起こります。以後「UDPロードバランサは、特定のタイミングでハッシュの再計算が発生するものもあります。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。