IPv4アドレスの枯渇すると言われ続けております。 「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。 実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240) 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0) 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127) IPアドレスのホスト部が0のものを利

「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では、そのような変更を入れる検討が始まっていま

IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で

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では出来

はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする

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(攻撃対象): ブラウザで攻撃者のサイトにアクセスすｒ

DNSでは、DNSSECでの不整合や、ポリシーによってブロックされて問い合わせがエラーとなることがあります。 Google Chromeでは「Extended DNS Errors(EDE)」という仕様のサポートが検討されています。これは、問い合わせに対するエラー原因を通知するための仕様で、EDNS0のオプション領域にエラーコードとエラー文を含めて応答できるようにするものです。現在IETFで標準化中になります。 これによってDNSのエラー原因がわかりやすくデバッグが用になるほか、ユーザへのエラー画面を出す際により分かりやすい文言を出せるようになります。 Chromeでの実装検討の詳細については下記の資料を参照ください。 https://docs.google.com/document/d/1PItRbCJHgv1CcqjnkOw1F8oup3oISkMf_xxKZmqGhiU/edit#h

「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って

NginxのHTTP/3対応版が公開されました。実際に動かしていきます。(なお、現在サポートしているのはHTTP/3 draft 27版です) www.nginx.com 基本的には 「README」 の通りやるだけです。 HTTP/3の詳細についてはガッツリ解説を書いたので、ご参考にしていただければ asnokaze.hatenablog.com 準備 (ちなみに環境は Ubuntu18.04 Bionicです) パッケージのインストールと、依存するboringsslのビルドをしておきます https://boringssl.googlesource.com/boringssl/+/HEAD/BUILDING.md $ sudo apt install mercurial ninja-build $ git clone https://boringssl.googlesource.com

「RFC 8307 Well-Known URIs for the WebSocket Protocol」でWebSocketにおいても Well-Known URIが使用できるようになりました。 この界隈では珍しく、個人ドラフトの-00から一気にRFCになっています https://datatracker.ietf.org/doc/rfc8307/ Well-Known URI httpやhttpsでは、Well-Known URIというものがあり特定用途に使用するURIが予約できるようになっています (RFC 5785) 例えば、https://example.com/.well-known/○○○○○ のように /.well-known/ 以下に特定用途のURIが予約されます。 現在登録されているWell-Known URIの一覧は、IANAのページから確認できます (URL) 例え

目次 背景と仕様 WebTransport over HTTP/2 (Http2Transport) 特徴 概要 WebTransport over HTTP/2のネゴシエーション WebTransport Connect StreamsとWebTransport Streams WTHEADERSフレーム 通信例 ネゴシエーション WebTransport Streams 中間装置(Proxy)の例 その他 背景と仕様 以前取り上げたように、WebSocketに変わるWebTransportという新しい双方向メッセージングプロトコルの標準化および実装が進められている。 asnokaze.hatenablog.com JavaScript APIに関してはW3C側で(仕様リンク)で策定されているが、プロトコルはIETFで策定が進められている。 使用するトランスポートプロトコルによって仕様が

HTTPメッセージに署名をするSignatureヘッダを定義する「Signing HTTP Messages」という仕様が提案されています。 HTTPメッセージへの署名は、様々なところで行われていますが、それぞれ独自の方式で行われています。例えば、AWS APIを叩く際に利用する「Signature Version 4 Signing」や、OAuth2.0 DPoPなどでHTTPメッセージへの署名が行われています。 その他にも、WebPackagingで使用される「Signed HTTP Exchanges」といったところでも署名が行われています。 一方でTLSではだめなのかという話もありますが、TLSを用いることでHTTPメッセージの機密性および完全性は保護されますが、TLS終端プロキシなどを経由するとそれ移行の部分で通信の完全性は担保されません。クライアントとサーバ間でHTTPメッセー

2021/02/09追記 RFC 8941: Structured Field Values for HTTP が出版されました 背景 概要 Lists Inner Lists Parameters Dictionaries Item 使用例 その他 2年前にも同様の記事を書きましたが、当時はdraft-00でしたが、2年ほど立ち draft-14が出ておりところどころ変わっているので書き直します。 asnokaze.hatenablog.com 背景 新しいHTTPヘッダを定義するときに、新しい仕様毎にシンタックスを記述するのは非常に煩わしい作業です。 そこで、リストや辞書形式のようなデータ構造の定義を「Structured Headers for HTTP」として与えることで、新しいHTTPヘッダを定義するときはこの仕様を参照しリストや辞書形式のヘッダを定義できるようになります。実際、

関連記事 WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog WebTransport over HTTP/2 の仕様について - ASnoKaze blog WebTransport over QUIC について - ASnoKaze blog WebTransportという新しい双方向通信フレームワークの議論が始まっている。 GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。 discourse.wicg.io WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計にな

QUIC, HTTP/3 関連記事 QUICのAckとロスリカバリについて - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog HTTP/3というかQUICの通信がどのように暗号化されているのか勉強がてら軽くまとめる。(執筆時点でQUIC-TLS Draft 19) QUICでは、通信の多くが暗号化されています。アプリケーションデータはもちろんのこ

[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICのAckとロスリカバリについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze

[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP

「418 I’m a tea pot」としてよく知られる 418 ステータスコードについて、IETF HTTPbis WGで議論になっていました。 「418 I’m a tea pot」はジョークRFCである「RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)」で定義されているステータスコードです。 ここで注意するのは、418はHTCPCPで定義されているステータスコードであり、HTTPで定義されているステータスコードではないという点です。 この議論については以前 Qiita で書いたとおりです。 qiita.com HTTPで418ステータスコードを予約 以前このブログで書いたとおり、HTTPセマンティクスに関して仕様の再改定が行われております asnokaze.hatenablog.com その後、3つの仕様に分割され

20190424 追記 IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。 現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。 この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。 現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて

20180713追記 Intervention reports について追記しました ブラウザのバージョンアップは定期的に行われており、その度に廃止される機能もあります。 廃止されることは公式にアナウンスされますが、そもそも自分が使っているかどうかすべてを把握することは難しいでしょう。JavaScriptのAPIであったり、HTTPヘッダだったりとその範囲は非常に広く、ライブラリの特定のバージョン以下だと問題になるといったケースも有るかと思います。 このような場合に役に立つ、廃止される機能が使用されていることをWebデベロッパー側で検知する仕組みが「Deprecation Reports」です。 Blink開発者メーリングリストでも議論されていますが、すでにChrome Canaryで動作するので、簡単に動作確認してみます。 Reporting API 表示してるページのエラーなどを指定し