QUICのAckとロスリカバリについて自分なりにまとめる。 （トランスポートは詳しくないのでご容赦ください） あわせて、関連記事もどうぞ 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と、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog とくに、ストリームやフレームに関しては下記記事を参照のこと asnokaze.hatenablog.com はじめに QUICで

こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk

追記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.3では0-RTTハンドシェイクという、1度通信を行い鍵が共有できている相手とはハンドシェイク中にアプリケーションデータ(Early Data)を送信する手順があります。 "先日のコミット"によって、Chromeでも使用できるようになったので試す。なお再送攻撃に対して脆弱なため、GETリクエストのときのみ使用されます。 まだChrome Canaryまでしかこの機能が降ってきてないので、Canary で試す。 chrome://flags より、「TLS 1.3 Early Data」を有効にする サーバ側 「NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す」の通り。0-RTT対応サーバを用意する。 現在はOpenSSLでビルドしても、ssl_early_data on;にすれば動作する。 今回はHTTP/2は無効にしておく 動作確認 今回

TCP Fast Open TCP Fast Openと呼ばれる技術があり、RFC 7413として標準化されている。 このTCP Fast Openを使うと、一度コネクションを貼った相手とは、TCPの3ウェイハンドシェイク中にデータを送受信できるようになる。クライアントからSYNとともにデータを送信することで、実際にデータを送受信開始するまでの待ち時間が短縮できる。 Linuxではすでにクライアント/サーバ両方でTCP Fast Openを使用できる。 TCP Fast Openの闇 しかし、数年前よりこのTCP Fast Openには一部のネットワークで奇妙な振る舞いをすることが知られている。Appleの人が実際にデプロイした時に見つけたもので、IETFやNANOGにて報告されており、その時の資料は下記のとおりである Deploying TCP Fast Open in the wild