匿名かつ検証可能な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
ホスト名の最後が数字なURLの扱いについて - ASnoKaze blog
「WHATWG URL」の仕様で、ブラウザにおいて、ホスト名がIPv4でないが、数値で終わるURLは拒否されるように変更された。 github.com 例えば次のようなものです foo.0 bar.0.09 1.2.3.4.5 今まで、これらのホスト名は、その他のドメインと同じように、通常通り名前解決されます。Issueの起案者は、すでに具体的な攻撃があるわけではないとしつつも、紛らわしさや、eTLD+1 (same-site)の扱いの問題があるとのことです。 なお、次のようなものはIPv4アドレスにマッピングされアクセスできます。 http://127.1 http://1.65793 Deprecate support for URLs with non-IPv4 hostnames ending in numbers 実際に、Chromeでは、そのような変更を入れる検討が始まっていま
タイムゾーンを含むタイムスタンプ文字列表現の標準化 - ASnoKaze blog
「Date and Time on the Internet: Timestamps with additional information」という提案仕様がIETFで提出されているので簡単に紹介する。 この仕様では、下記のようなタイムスタンプの文字列フォーマットの定義を行う 1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew] 背景 TC39 Temporal Temporalという時間を扱う新しいAPIが、TC39でStage 3となっている。 tc39.es このAPIでは、タイムゾーンを含む文字列を生成できる。 const zonedDateTime = Temporal.ZonedDateTime.from({ timeZone: 'America/Los_Angeles', year: 1995, month:
HTTPSの接続情報を通知する "HTTPS DNSレコード" の提案仕様 (2021/07更新) - ASnoKaze blog
HTTPSで通信を開始する際に、事前に知っていると有用な情報が幾つかあります。 サーバがHTTP/3に対応しているか(Alt-Svc情報) TLS Encrypted Client Hello で必要な情報 サーバがHSTSを要求してくるか このような情報を提供する新しいDNSレコードを定義する仕様が提案されています。提案仕様「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」では、サービスに関する情報を通知する一般形式であるSVCBレコードと、HTTPS用であるHTTPSレコードを定義しています。 もともとはHTTPSSVCレコードという名称でしたが、最近改称されHTTPSレコードになりました。 また、このHTTPSレコードを用いることでANAMEレコードが解決しようとしていた
HTTPセマンティクス仕様の改訂版(RFC9110) まとめ - ASnoKaze blog
HTTPのGETといったメソッドやヘッダの意味を定義したHTTPセマンティクス仕様の改訂版である「HTTP Semantics」が標準化の大詰めを迎えている。(RFC9110となる予定) 既存の仕様から幾つか大事な変更が含まれているので簡単に紹介する。 目次 セマンティクス仕様の改訂作業 ざっくり変更点 用語整理 (Field) 用語整理 (body) 用語整理 (interim/final レスポンス) ステータスコードのレンジを明確化 ステータスコード418 unused Rangeを指定したPUTリクエスト GET, HEAD, DELETEでコンテンツを含めるのを非推奨 (SHOULD NOT) プロトコルのマイナーバージョンについて 更に詳しく知りたい場合 おわりに セマンティクス仕様の改訂作業 HTTPセマンティクス及び、HTTP/1.1の仕様の改定作業がIETFのHTTP W
WebTransport over HTTP/2 の方向性 (2021年5月の中間会議をうけて) - ASnoKaze blog
5月21日に行われた WebTransport WGの中間会議で、WebTransport over HTTP/2の方向性が見えてきたのでメモとして残しておく WebTransportの動向 WebTransportと呼ばれる新しい双方向通信の仕組みが議論されています。 WebSocketの次世代版とも呼ばれており、HTTP/3上で動作します。現在、Chrome で実装が進められていたりします。 さて、このWebTransportの標準化は、IETFでプロトコルを、W3Cでインターフェースの仕様が議論されています。 W3C WebTransport IETF WebTransport over HTTP/3 WebTransport using HTTP/2 1月にあったIETF WebTransport WGの中間会議では、QUICとHTTP/3を使うもののうち、HTTP/3を使うWeb
QUIC Version 2 という個人ドラフト(draft-duke-quic-v2❩ - ASnoKaze blog
2021/11/23 追記 進展があったので、新しく記事を書きました asnokaze.hatenablog.com == QUIC Version 1はQUIC WGとしてはとりくみが終わり、RFCとして出るのを待つばかりとなっています。 現在は、v1以後のQUICバージョンの前準備として、バージョンネゴシエーションの仕組みづくりの議論が活発に行われています。先日も、中間会議でバージョンネゴシエーションについて議論が行われました (詳細へのリンク) そのバージョンネゴシエーションの議論のなかで、「QUIC Version 2 (draft-duke-quic-v2-00)」という DraftがIETFに提出されました。 draftは個人が自由に提出出来るということに注意してください。審査などもありません。これは、IETFやQUIC WGとしての意見を表すものではなく、何かが決まってしまう
WebTransport over HTTP/3のプロトコル仕様 - ASnoKaze blog
WebSocketに変わる、Webの新しい双方向通信仕様 WebTransportの標準化・実装が進められています。 このWebTransportではHTTP/3の特徴を活かし、パケットの順番が入れ替わったり、パケットロスがあったとしても受け取った順番に処理を行うことが出来ます。DATAGRAM拡張を使えば、パケットロスしたデータも再送不要にできます。 前回紹介した通り、WebTransportは「WebTransportover QUIC」や「WebTransportover HTTP/3」がありましたが、HTTP/3を使う方向で議論が進んでいます。 asnokaze.hatenablog.com Chromeの開発者メーリングリストでは、この「WebTransport over HTTP/3」実装が進められている事が書かれています。 groups.google.com そこで、今回はプ
ZeroSSL ならIPアドレスのサーバ証明書が取得できる - ASnoKaze blog
IPアドレスのサーバ証明書が欲しい場合があります。そうすれば、ドメインを取得せずともサーバとHTTPS通信ができるようになります。 その他にも例えばDNS over HTTPSではIPアドレスでアクセス出来るように、有効な証明書がセットされていたりします。 https://1.1.1.1 https://8.8.8.8 しかし、Let's Encryptでは、IPアドレスのサーバ証明書は取得できません ~$ sudo certbot certonly --nginx -d 160.16.124.39 Requested name 160.16.124.39 is an IP address. The Let's Encrypt certificateauthority will not issue certificates for a bare IP address.ZeroSSLでは出来
URLリソースの非推奨を示すDeprecationヘッダ - ASnoKaze blog
APIのURLや、リソースが非推奨となっている事を示す、新しいDeprecationヘッダを定義する「The Deprecation HTTP Header Field」という仕様が提出されています。 この仕様はすでに、HTTPAPI WGに採用せています。なお、HTTPAPI WGは2020年10月 新しく出来たWGで、HTTPのAPI利用のための拡張を議論するWGになっています。 Deprecationヘッダ レスポンスに、下記の様なヘッダを付けることで、そのリソースが非推奨になっている事を示します Deprecation: trueDeprecation: Sun, 11 Nov 2018 23:59:59 GMT true: 非推奨になっている 日付: 指定した日付で非推奨になる Linkヘッダ 「RFC8288 Web Linking」の仕組みを用いて、 Linkヘッダで追加の情
TCPとTLSを連携させるTCPLS - ASnoKaze blog
2021/10/26追記、TCPLSの提案仕様がIETFに提出されました https://www.ietf.org/archive/id/draft-piraux-tcpls-00.html ルーヴァン・カトリック大学のFlorentin Rochet氏らによって「TCPLS: Closely Integrating TCP and TLS」という論文が出されています。 面白そうなのでかんたんにメモしておく。 詳しくは論文や文末記載の資料を御覧ください。 TCPLS この論文では、TCPとTLSを連携させるTCPLSを考案しています。スタック図ではTCPとTLSがくっついてるようなものになりますが、くっついた新しいTCPLSというプロトコルというよりかは、TCPとTLSが連携して動作できるようにするイメージです。 ですので、飛び交うパケットとしては通常のTCPやTLSであり、通信経路上での
TLS1.3の0-RTT通信と、HTTP 425 ステータスコードの提案仕様(RFC8470) - ASnoKaze blog
20190502 追記 動いた NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す - ASnoKaze blog 20180922 追記 RFC8470として標準化されました 無事Too Earlyのステータスコードが 425になりました (URL) 本記事は、draft-00時点の記述の通り、未定を示す4NNのままとしておきます。 2020/01/19追記 #http_tokyo で詳しい説明をしました。あわせてどうぞ Status 425 HTTP/Tokyo from yuki-f www.slideshare.net TLS1.3では、0-RTTハンドシェイクの際にearly_dataとしてアプリケーションデータを送信できます。しかし、この0-RTTハンドシェイクで送信するデータには、リプレイ攻撃のリスクがあります。 そのリスクをさけるため
RFC8879 TLS Certificate Compression について - ASnoKaze blog
「RFC8879 TLS Certificate Compression」が昨日公開されました。 これは、TLSハンドシェイク中に送信されるサーバ証明書を圧縮する仕組みを定義しています。 これによって、ハンドシェイクの通信量を削減できます。ハンドシェイク中は、パケットロスが起こっても後続のパケットは多くないのでロスリカバリとしては不利な状況です。ハンドシェイクに必要なパケット数が減るというのはメリットが有るのかなと思います。 また、QUIC(HTTP/3)においてもTLSハンドシェイクを利用していますが、QUICではClient Address Validationが終わるまで一度に送れる通信量に制限があるため、通信量が減ることはそういった意味でもメリットがあります。 この点については、FastlyのPatrick McManus氏がブログを書かれています。実際に送信されるパケット数がどう
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
NAT Slipstreaming攻撃とブラウザ側の対策 - ASnoKaze blog
2021/01/29 NAT Slipstreaming v2が公開されたので、追加記事を書きました https://asnokaze.hatenablog.com/entry/2021/01/29/014759 2020年10月31日に「NAT Slipstreaming」という攻撃手法が発見されてます samy.pl これは簡単に言うと 罠サイトを踏ませることで、SIPのApplication Level Gateway機能を持つNATの内側に居るクライアントに対して、外側からそのクライアントの任意のTCP/UDPポートに接続できる。という攻撃のようです。 この攻撃はさまざなテクニックを使用しており大変面白いです。調査過程も含め詳細は上記のサイトに書かれているので、そちらを読むことを強く推奨します。 ざっくり 登場人物 victim(攻撃対象): ブラウザで攻撃者のサイトにアクセスすｒ
HTTP/2の仕様、改定作業が始まる - ASnoKaze blog
[追記] 2021年10月時点の変更点について新しく記事を書きました asnokaze.hatenablog.com == もくじ HTTP/2の改定作業 修正点 優先度制御について TLS1.3および0-RTT GREASEのコードポイントの予約 疑似ヘッダの扱い h2cの削除 セマンティクス仕様への参照 そのた参照の更新 security considerations の追記 HTTP/2の改定作業 HTTP/2の仕様は2015年に「RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)」として標準化されています。 RFCは公開されたあとに、エラッタが見つかることがあります。このようなエラッタを修正するために、新しくRFCを出し直すということが行われます。 HTTP/2においてもいくつかのエラッタが公開されています (参考リンク)。
ブラウザからTCP, UDPソケットを操作するDirect Sockets API - ASnoKaze blog
2020/01/14: 実際に動くのを確認しました asnokaze.hatenablog.com (2020/09/17 注釈: Raw SocketsからDirect Socketsに名称が変更されました) ブラウザでTCP, DUPソケットを操作可能にする「Direct Sockets API」という仕様がW3CのWICGで議論されている。 また、blink-devでも「Intent to Prototype: Raw Sockets API」とプロトタイプの議論が行われている。 多くの方がセキュリティ上の懸念を抱くと思うが、ドキュメントでも慎重に検討すると書かれている。GithubでIssueを立てることも可能なので、思うことがある方は、まだまだ議論は始まったばかりでもあるので是非フィードバックされると良いと思う。(割と普通に聞いてもらえます) なお、Raw Socketsという名
QUIC for SSH の提案仕様が出たよ - ASnoKaze blog
「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
