internet-draft

安全なコンテンツを要求するPrefer:safeヘッダ

Webサービスによっては、子供に見せたくない有害なコンテンツを非表示にできるサービスもあります。それの多くはcookieを使い、設定を保存するケースが多く個別に設定を有効にしていく必要があります。また、広告といった設定がし辛い部分もあります。こうい…

サービスやリソースの廃止時間を示すSunset HTTP ヘッダ (RFC8594)

RFC8594 で定義された、サービスの廃止時間を示すSunsetヘッダについて。

Cookie の SameSite=Lax をデフォルトにする提案仕様

20190526 追記 Chrome 77 (9月リリース)にて有効になりだす模様 https://groups.google.com/a/chromium.org/d/msg/blink-dev/AknSSyQTGYs/SSB1rTEkBgAJ 20190523 追記 Firefoxでも同様の動きがあります https://groups.google.com/forum/#!msg/mozilla.dev.p…

新しいWebの双方向通信 "WebTransport" について

WebTransportという新しい双方向通信フレームワークの議論が始まっている。GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。 discourse.wicg.ioWebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化された…

QUICの暗号化と鍵の導出について

QUIC, HTTP/3 関連記事 HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP3について) - ASnoKaze bl…

HTTP/2においてTLS1.3のpost-handshake authenticationの禁止

GoogleのDavid Benjamin氏より「Using TLS 1.3 with HTTP/2」という提案仕様が出されています。この仕様自体は、単純にHTTP/2においてTLS1.3のpost-handshake authenticationを禁止するものです。HTTP/2でTLS1.2を使用している場合はrenegotiatoinが禁止され…

「Address-bound Token for QUIC」が面白い

FastlyのKazuhoさんが「Address-bound Token for QUIC」という提案仕様を出している、この中で出てくる "Sharing the Congestion Controller" という仕組みが非常に面白かったので、簡単に書いてみようと思う。 address-bound token この提案では、同一エン…

HTTP/3のヘッダ圧縮仕様QPACKについて

この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである「QPACK 」について説明します。(執筆時 draft 07)HTTP/3については下記を一読頂ければ asnokaze.hatenablog.com HTTP/2の場合 ハフマン符号 静的テーブル、動的テーブル HTTP/3とQPACKの導…

中間証明書を要求しないTLSフラグ拡張

TLSハンドシェイクでは、サーバはエンドエンティティ証明書と任意でルート証明書までたどるための中間証明書を送信します。不要であればこの中間証明書を送信しないようにする「Suppressing Intermediate Certificates in TLS」という提案がMartin Thomson氏…

QUICにおいてNAT検出を行う拡張フレームの提案仕様

QUICを使用している際に、その通信がNATによってアドレス変換を行われているかを検出する「QUIC Address Extension」という提案仕様がAppleの人らによって出されています。具体的には、送信元IPアドレスがなんであるかを通信相手に確認します。そうすること…

HTTP/2をバイトストリームトランスポートとして利用する提案仕様

HTTP/2コネクション上で任意のバイトストリームをやりとりできるようにする「Using HTTP/2 as a Transport for Arbitrary Bytestreams」という仕様がAppleの人らによって提案されている。IETF103でも議論(資料)になったが、その後 draft-01 が出ているのが現…

Secondary Certificate Authentication in HTTP/2 という仕様について

目次 Secondary Certificate Authentication in HTTP/2 用途 サーバ側から証明書を要求するパターン クライアント側から証明書を要求するパターン 通信フロー サーバ側から証明書を要求する場合 クライアント側から証明書を要求する場合 Secondary Certifica…

HTTP/3で接続してVPNとして使うMASQUEプロトコルの提案仕様

GoogleのDavid Schinazi氏が「The MASQUE Protocol」という仕様を提出している。初版のdraftであり、議論の呼び水としての立ち位置が強いがまずは読む。 MASQUE Protocol MASQUEはMultiplexed Application Substrate over QUIC Encryptionの略称です。この提…

リバースプロキシのエラーを示す Proxy-Statusヘッダの提案仕様

CDNやクラウドのロードバランサを使用するのは一般的です。これらのリバースプロキシは様々な理由により502 Bad Gatewayや504 Gateway Timeoutを返しますが、トラブルシュートするには情報が少ない場合があります。また、追加の情報を示す場合においても、各…

Fake SNIという提案仕様について

SNIを用いた通信のブロッキング及び、「Encrypted SNI拡張」のブロッキングについてはIETFのTLS WGでも話題となりました((TLS) SK filtering on SNI, blocking ESNI)。Encrypted SNIはSNIを暗号化する一方で、ClientHelloにencrypted_server_name拡張をつ…

Delegated Credentials for TLS について

BoringSSLが「Delegated Credentials for TLS 」に対応したので、簡単に仕様を眺める。 「Delegated Credentials for TLS 」の仕様は、もともとはTLS1.3の仕様の著者でもあるEric Rescorlaによって書かれていたようだが、すでに WG DraftとなっておりMozilla…

HTTP/2 ORIGINフレームのセキュリティを改善する提案仕様

AkamaiのMike Bishop氏らから、「DNS Security with HTTP/2 ORIGIN」という提案仕様が出ている。簡単に読む ORIGINフレームとは ORIGINフレームとは、RFC8336で標準化されているHTTP/2の拡張フレームです。HTTP/2では、複数のドメインへのリクエストでもコネ…

QUIC,HTTP/3 の draft-17に関するメモ

12月8日に現在標準化が進められているQUICの仕様のdraft-17が出ました。以下の記事で書いたように、"HTTP over QUIC" のHTTP/3への名称が含まれています。 asnokaze.hatenablog.comその他にも幾つかの変更が含まれているのでざっと目を通す。 「Hypertext Tr…

新しいユーザエージェント表現 User Agent Client Hints の提案仕様

20190218追記 Implement `Sec-CH-UA-*` replacements for `User-Agent`. https://chromium.googlesource.com/chromium/src/+/2fddeeb74abcc3c9e3ba88df4cfb0c1c07e43fc6Chromeでは実装が進められている ユーザエージェントは歴史的背景により、複雑な文字列…

HTTP over QUICと、その名称について (HTTP3について)

さてHTTP/3というと、なにか新しそうなHTTPのような気がしますが、まず基本的なHTTPのセマンティクスに変更はありません。GETやPOSTといったHTTPリクエストがあって、ステータスコードを持つレスポンスが返されます。ただその伝達方法がQUICトランスポートに…

QUICの話 (QUICプロトコルの簡単なまとめ)

[追記] QUIC, HTTP/3 関連記事 QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over …

HTTP 418ステータスコードが予約される

「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)」で定義されているステータス…

NTPを暗号化する Network Time Security for NTP の提案仕様

サーバが正しい時刻に設定されていることは重要であり、時刻同期に使用されるNTPにおいてもサーバの認証や改ざんを防ぎたいというモチベーションは理解できる。IETFのNTP WGでは、まさにNTPを暗号的に保護する「Network Time Security for the Network Time …

QUICの信頼性のないデータグラム拡張(MESSAGEフレーム/Datagramフレーム)

QUICはUDP上で暗号化された信頼性のあるデータ通信を提供するトランスポートプロトコルです。現在IETFの「QUIC WG」で標準化が進んでおり、先行して実装されていたGoogle版QUICもIETF版QUICへの移行が進められています。 QUICのアプリケーションレイヤ 現在Q…

キャッシュがHitした情報を示すCacheヘッダの標準化提案

CDNなどのサービスは、リクエストがキャッシュにヒットしたかどうかをx-cacheヘッダに格納してレスポンスしてくれますこのx-cacheヘッダは独自の形式であり、例えば以下のようになっています。 (CDNによっては、x-cache以外のヘッダを使うものもあります)f…

DNS over HTTPSサーバを見つけるためのTXTレコードの提案仕様

DNS over HTTPS(DoH)の標準化が進められており、引き続き注目を集めている。 asnokaze.hatenablog.com一方で、DoHサーバをどのように見つけるか、見に行かせるかの議論が始まっています。 JPNIC Blog :: DNS over HTTPSとDHCP -IETF102における議論- で紹…

セキュリティトークンを識別するための secret-token URI Scheme の提案仕様

セキュリティートークンを間違えて公開してしまうセキュリティインシデントが増えています。例えば、シークレットやトークンをソースコードに埋め込んだままコミット・公開してしまったりなどです。機械的にセキュリティトークンを識別できるようになれば、…

Cookieにかわる Sec-HTTP-State ヘッダの提案

20190424 追記 IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに…

TLS1.0, TLS1.1 の廃止する提案仕様

TLS1.3にRFC8446が採番され、RFCとして出るのを待つばかりになっている。一方で、「Deprecating TLSv1.0 and TLSv1.1」というTLS1.0とTLS1.1の廃止についての提案仕様がIETFで出ている。 TLS1.0, TLS1.1 廃止事情 カード情報セキュリティの国際統一基準 PCI …

(RFC8586) Forwarding-Loop Attacks攻撃を防ぐCDN-Loopヘッダの提案仕様

RFC 8586 Loop Detection in Content Delivery Networks (CDNs)として、標準化されました (2019/4/25 追記) Forwarding-Loop Attacks攻撃を防ぐ「CDN Loop Prevention」 という仕様が提案されています。 背景 CDNへのDoS攻撃として、リクエストをCDN内でル…