HTTP/3コネクション上でSSHを実行するSSH3プロトコル - ASnoKaze blog
IETFに『Secure shell over HTTP/3 connections』という提案仕様が提出されています。 これは、HTTP/3コネクション上でSSHを実行するプロトコルを定義しています。なお、"SSH3"という名称を仕様中で使用していますが、あくまで提案段階ですので今後変わる可能性もあります。 SSH3ではHTTP/3を使うことにより以下の特徴を持ちます QUICのメリットが享受できる（例えばIPアドレスが変わってもコネクションを維持できる） HTTPの認証方式をサポートする（Basic認証、OAuth 2.0、Signature HTTP Authentication Scheme） SSH通信の秘匿 (第三者からするとただのHTTP通信にみえる) エンドポイントの秘匿 (Signature HTTP Authentication Schemeを使うことで、そこでサービス
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
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
時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog
IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で
Cookieの新しい属性、SameParty属性について - ASnoKaze blog
ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
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ハンドシェイクを行って
DNS ANAMEレコードの提案仕様 - ASnoKaze blog
20181019追記 「Address-specific DNS aliases (ANAME)」として、新しい draft-02が出されました 20180912追記 この提案仕様はexpireしてしまいました。 完璧に代替するものではありませんが、いくつかの方法について議論がされているようです。 IETFでのDNS関連の標準化は普段追ってないので恐縮だが、DNSOP(DNS OPerations)WGで気になったドラフトがあったので読んで見る。 「Address-specific DNS Name Redirection (ANAME)」という提案仕様であり、先日WGドラフトになったようだ。著者は、ISC, PowerDNS, DNSimple の方々でありDNS実装に関わっている人が書いているようだ。 PowerDNSでは、すでにALIASと言う似たような機能が実装中のようですし、Cl
HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog
[追記] 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の話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog
[追記] 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
NTPを暗号化する Network Time Security for NTP の提案仕様 - ASnoKaze blog
2020/10/02 追記 RFC8915として標準化されました RFC 8915 - Network Time Security for the Network Time Protocol サーバが正しい時刻に設定されていることは重要であり、時刻同期に使用されるNTPにおいてもサーバの認証や改ざんを防ぎたいというモチベーションは理解できる。 IETFのNTP WGでは、まさにNTPを暗号的に保護する「Network Time Security for the Network Time Protocol」という仕様策定が進められている。 NTPにはいくつかモードがあるが client-server モードを前提としている。 NTPは詳しくないがざっと見てみる (正しくはNTPの暗号化ではなく、保護的な感じはある) 目的 Network Time Securityの目的は以下の通り Iden
DNS over HTTPSサーバを見つけるためのTXTレコードの提案仕様 - ASnoKaze blog
20190821 追記 この提案は廃案されました https://mailarchive.ietf.org/arch/msg/doh/qkmhh93Id6XIngH3LJwp-HokH_Y DNS over HTTPS(DoH)の標準化が進められており、引き続き注目を集めている。 asnokaze.hatenablog.com 一方で、DoHサーバをどのように見つけるか、見に行かせるかの議論が始まっています。 JPNIC Blog :: DNS over HTTPSとDHCP －IETF102における議論－ で紹介されている通り、先月行われたIETF102でもDNSリゾルバの識別子と利用についてのBoFがありました。 例えば、設定ファイルだったり、DHCPでDNSサーバを設定する際にDoHサーバを設定する際にどうすればいいか、どのようディスカバリさせるかといった議論です。 その流れで、Do
Cookieにかわる Sec-HTTP-State ヘッダの提案 - ASnoKaze blog
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とは異なりオリジンを超えて
NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す - ASnoKaze blog
追記20180922 OpenSSLも対応しました 「support for TLSv1.3 early data with OpenSSL.」 http://hg.nginx.org/nginx/rev/548a63b354a2 昨日、NginxがTLS1.3の0-RTTハンドシェイクをサポートしたので試した。無事動作することが確認できた。 該当コミットはこの2つ SSL: enabled TLSv1.3 with BoringSSL. SSL: support for TLSv1.3 early data with BoringSSL. TLS1.3の0-RTTハンドシェイクは、一度ハンドシェイクをした相手とはClientHelloに続けてアプリケーションデータ(HTTPリクエスト)を送信することで、より早くデータのやりとりを開始する方法です。 (引用: https://blog.cl
TLS1.0, TLS1.1 の廃止する提案仕様 - ASnoKaze blog
TLS1.3にRFC8446が採番され、RFCとして出るのを待つばかりになっている。 一方で、「Deprecating TLSv1.0 and TLSv1.1」というTLS1.0とTLS1.1の廃止についての提案仕様がIETFで出ている。 TLS1.0, TLS1.1 廃止事情 カード情報セキュリティの国際統一基準 PCI DSS では2018年6月30日以降はTLS1.1を禁止している他、アメリカ国立標準技術研究所(NIST)もTLS1.2の移行を以前から推奨している。 実サービスにおいては、GithubやAmazon ELBやCloudFlareなどTLS1.0, TLS1.2の廃止を進めているサービスも多い。 また、IPAの出している「SSL/TLS暗号設定ガイドライン」でも、高セキュリティ型要件ではTLS1.2だけのサポートと書かれている。また「「SSL/TLS暗号設定ガイドライン
TLSにおけるTicketRequest拡張の提案仕様 (RFC 9149) - ASnoKaze blog
(追記) 2022年、RFC 9149として標準化されました == Appleの人らによって「TLS Ticket Requests」という、TLSでのセッション再開に利用するチケットに関する拡張仕様が提案されています。 TLSはあまり詳しくないのですが簡単に読む TLS session ticket まず、TLS session ticketとセッション再開について確認する TLSでは一度ハンドシェイクを行った相手と、セッションを再開するための手順が用意されています。これにより処理量を少なくできます。 セッション情報を暗号化しTicketとしてクライアントに渡すことで、サーバ側はセッション再開のために情報を保持しておく必要がなくなります。 Ticketに関する拡張仕様は、RFC5077「TLS Session Resumption without Server-Side State」で標
Web5Gとはなんなのか - ASnoKaze blog
W3Cでは、「Web5G」を掲げ5G及び関連するネットワークの進化に向けて、それにあわせたWeb標準技術・APIを模索しているようである。 個人的な印象としては、ネットワークレイヤとWebアプリケーションレイヤが連携するようなイメージでいる。ネットワークを性能ごとに切り出して提供するネットワークスライスや、ネットワークエッジで処理を行うモバイルエッジコンピューティング(MEC)を具体的に想定しているものもあれば、そうでないものもある。 すでに幾つかの資料がネット上に上がっており、僕は5Gは全然詳しくないが、今回は「Web5G Roadmap」と「Web5G Workshop」を眺めつつ、どのような事が思い描かれているかみていく。 5Gとどのように関わるかわからないが、BBCのネットワークエッジまで HTTP over QUICマルチキャストで配信する例は非常に興味深い Web5G Road
ライブコンテンツにおけるHTTP Rangeリクエストを改善する提案仕様 (RFC8673) - ASnoKaze blog
追記2019/11/28 RFC8673になりました ライブコンテンツやログデータといった常に大きくなり続けるコンテンツに対するRangeリクエストを改善する提案仕様がIETFのHTTPbisで出ています。 その仕様は「HTTP Random Access and Live Content」であり、すでにWGアイテムとなっておりWorking Group Last Callを迎えようとしてます。 現状のライブコンテンツとRangeリクエスト 常にコンテンツが大きくなり続けるファイルに対して、Rangeリクエストでデータを受信し続ける場合を考えます。クライアントはRangeリクエストを繰り返すような流れになります。 クライアントはRangeヘッダで1000バイト目より後ろを要求します。Rangeヘッダでは後ろの明示しないことも出来ます HEAD /resource HTTP/1.1 Rang
TLS over HTTPの提案仕様 - ASnoKaze blog
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
