ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)

Webページのサブリソースを1つにまとめる 「Resource bundles」 という仕組みが検討されている。 [目次] はじめに 2行で説明すると 例 利用例 rbnファイルの取得 rbnファイルの中身 その他(標準化やツールについて) おわりに はじめに JavaScript, CSS, 画像といったWebページを表示するのに必要なリソースを一つのファイルにまとめるというのは、今でも行われておりwebpack、rollup、Parcel、esbuildといったツールが利用されている。 「Resource bundles」の目的を読むと、既存のバンドラーは、個々別にリソースをフェッチするのに比べいくつかのデメリットが有ると述べている。 リソース個別のフェッチであれば、MIMEタイプによってはフェッチしながらそのデータの処理を進められるが、それができない リソース個別のフェッチであれば、

ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中

@flano_yukiがHTTP/3について書きました。(無料です。 2020年6月時点の内容となっています。概ねQUICやHTTP/3の大枠は固まっており、2021年の内容と照らし合わせても、大きな変更はありません。PDFを下に貼ってあります。 , (宣伝) また、2021年6月にアップデートも含め、WEB+DB PRESS Vol.123に記事を書かせていただいております（有料） gihyo.jp http3-note https://github.com/flano-yuki/http3-note にPDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ

「Rougtime」という時刻同期プロトコルの標準化が進められている。 すでに、GoogleやCloudflareがRoughtimeサーバを公開している roughtime.cloudflare.com roughtime.sandbox.google.com もともとは、2016年頃にGoogleのAdam Langley氏が原案を公開しており、サーバの実装が進められた。その後、時刻同期プロトコルを扱うIETFのNTP WGに仕様が提出されました。そして2020年1月に、「Rougtime」としてWG Draftになり標準化が進められています。 Roughtimeプロトコルの特徴 Roughtimeは以下の特徴を持つ クライアントからリクエストを送信し、サーバから署名を付けてレスポンス(時刻+証明書+署名)を返す 複数サーバを利用することで、暗号的に不正なサーバを暗号的に検知できる U

関連記事 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 関連記事 まるっと解説記事を書き直しました 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

2021/01/30 追記:RFC8959で標準化されました https://www.rfc-editor.org/rfc/rfc8959.html セキュリティートークンを間違えて公開してしまうセキュリティインシデントが増えています。例えば、シークレットやトークンをソースコードに埋め込んだままコミット・公開してしまったりなどです。 機械的にセキュリティトークンを識別できるようになれば、意図せずそのようなセキュリティトークンがコミットされたり公開されるのを機械的に防げるようになります。 先日IETFに提出された「The secret-token URI Scheme」という仕様ではsecret-token URI Schemeを定義し、セキュリティトークンを識別できるようにします。 例 トークンにsecret-token:を付けます secret-token:E92FB7EB-D882-4

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とは異なりオリジンを超えて

IETFのdnsop WGで .internal ドメインを予約する「The .internal TLD.」という仕様が、GoogleのWarren Kumari氏によって提案されています。 DNSに関しては詳しくないのですが、ざっと読んだので簡単にメモ。 .internal .internalというドメインを内部的に使用しているという方もおられるでしょう。 .internal TLDは、ICANNの「DNS名前衝突ブロックリスト」に含まれており、gTLDになることはありません。その事に関しては以下のINTERNET Watch様の記事が詳しいです。 萌えドメインなのに……「anime.moe」の登録をICANNが禁じている理由とは -INTERNET Watch Watch しかし、この.internalはIANA(ポート番号や識別子を管理する組織)には登録されていません。現在ドメイン名

TLS over HTTPである。HTTP over TLSではない。 「Application-Layer TLS」という提案仕様がCiscoの方より提出されている。(仕様中ではATLSと記述される) HTTP上でTLSレコードを送受信する仕様である。 TLSレイヤの実装変更はなくレコードをHTTPのボディで送受信できるようにする。なお、httpとhttps両方で使用可能である。 また、TLS1.2とTLS1.3などすべてのTLSバージョンに対応する。 来週からはじまるIETF100でも議論されるようなので、かいつまんで読んで見る。 クライアント クライアントからの基本的なメッセージは、POSTでJSONを送信する。 Content-Typeにはapplication/atls+jsonを指定する POST /atls Content-Type: application/atls+jso

パスワードの管理に、1PasswordやLastPassといったパスワードマネージャを使うのは一般的になってきています。 そのようなパスワードマネージャはランダムなパスワードを生成しますが、Webサービスによって使える文字の種類や、長さというのはマチマチです。 そこで、Webサービス側からパスワードの要件について記述できるようにする仕様がIETFに提出されています。 どこのWGで議論するのか、標準化が進むのかよくわからないが、とりあえず読んでおく。 Open Password Automation Recipe Protocol パスワード自動生成出来るように提案されている仕様は「Open Password Automation Recipe (OPAR) Protocol」というタイトルです。 Webサービスはページ内に下記のようなJSONをOPAR_Policyという変数で埋め込むこと

HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。 この機能は、Fastly VCLの機能の標準化のようです。 少々想定している背景がわかりづらいのですが、自分なりに簡単にまとめてみる。 背景 Webにおいて、サーバはクライアントからのリクエストヘッダを見てコンテンツを出し分けています。 例えば、Accept-Languageリクエストヘッダを見てコンテンツの言語を変更しています。キャッシュサーバももちろんこのAccept-Languageを見て、それぞれ毎にコンテンツをキャッシュする必要があります。 次の例を見てみましょう 1. ブラウザは下記のHTTPリクエストを送信する GET /foo H

Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが) 発見者が脆弱性等の報告を出来るような情報を、Web作成者が提供できるようにする仕様がIETFに提出されている。 この「A Method for Web Security Policies」という提案仕様では、security.txtをドメイン直下のURLに配置し、連絡先などを記述するようになっている。 security.txt security.txtは例えば以下のとおりである # Our security address Contact: security@example.com Contact: +1-201-555-0123 Contact: https://example.com/secur

20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。

2017/09/13 更新 Googleのブログで公式アナウンスが出ました。 一部対応者の表記がDigiCertになりましたが、大きなスケジュール変更はありません security.googleblog.com 今年の上旬より、Chromeが古いシマンテックの証明書を失効扱いするニュースが世間を賑わせたのは記憶にあたらしいかと思います。 internet.watch.impress.co.jp 議論は続いており、Blinkの開発者メーリングリストの「Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates」にてシマンテックとGoogle(+ Mozilla)が協議を重ねていることがわかります。 本日、「Google ChromeとChromiumプロジェクトを代表して」という形で最終になるで

20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog 20180208追記 Bundled HTTP Exchangesについて記事を書きました Bundled HTTP Exchanges とは (WebPackagingの議論より) - ASnoKaze blog 20180121追記 署名の仕組みとして Origin-Signed HTTP Exchanges を利用する方向のようです HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様 - ASnoKaze blog 20171001追記 IETF99にてユースケースについてまずまとめるべき気というフィードバックが有り、それをうけて「Use Cases and

「Moving towards a more secure web」でアナウンスされているように、2017年1月にリリースされる予定のChrome 56でHTTPサイトへの警告が表示されるようになる。 日本語のサイトでも取り上げられている Google、2017年からChromeでいくつかのHTTPサイトを「安全ではない」と警告 日本語版表示 Chrome Canaryで、chrome://flagsより 下記設定を有効にすることで、日本語版の警告表示が確認できる。 "保護されていない発行元に「保護されていない発行元」のマークを付ける" http://asnokaze.com https://asnokaze.com 日本語だと、また印象が変わる。HTTPS対応できてないサイトへの影響は結構ありそうである。

W3CでFeature Policyという仕様が議論されています。仕様は著者であるGoogleのIlya Grigorik氏のリポジトリ(URL)より確認できます。 このドキュメントはまだW3C公式のドキュメントとはなってはいませんが、先月行われたFace-to-Faceのミーティングでも議論がされています(議事録) Feature Policy セキュリティやパフォーマンスの観点で、Webデベロッパーがブラウザの特定のAPI（機能）を無効にしたい場合もあります。 そこで、 Feature-Policyヘッダを用いて以下のようにブラウザの機能を制限できるようにするのがこの仕様です。 また、このFeature-Policyヘッダは現在IETFで議論が行われている"A JSON Encoding for HTTP Header Field Values"(URL)というHTTPヘッダ値にjso

GoogleやMicrosoftが、将来的にSHA-1を使用した署名の証明書を安全なものとして扱わないとするアナウンスは、記憶に新しいかと思います。 Google Online Security Blog: Gradually sunsetting SHA-1 Windows PKI blog: SHA1 Deprecation Policy このアナウンスを受けて認証局各社ともSHA-2への移行を薦めている。 さて、仮にクライアントがSHA-2に対応していない場合はどうなるのでしょうか？サーバは証明書を出し分けたり出来るのでしょうか？ （実装はともかくして）TLS1.2より、ハンドシェイク時にクライアントのサポートしてる署名アルゴリズムを伝えられるようです。 Signature Algorithms Signature Algorithms extension はRFC5246の7.4.