#呼び出すまでの経路 脆弱性のある関数は tcp_collapse_ofo_queue() と tcp_prune_ofo_queue() です。これらが呼び出されるまでの経路は以下です。 tcp_v4_rcv()→tcp_rcv_established()→tcp_data_queue()→tcp_data_queue_ofo()→tcp_try_rmem_schedule() tcp_try_rmem_schedule()から脆弱性のある２関数が呼び出されます。 tcp_collapse_ofo_queue tcp_try_rmem_schedule()→tcp_prune_queue()→tcp_collapse_ofo_queue() tcp_prune_ofo_queue() tcp_try_rmem_schedule()→tcp_prune_queue()→tcp_prune_
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
まずは前回の記事で盛大な誤認をしていたことを訂正しなければなりません。 hb.matsumoto-r.jp 前回の記事では、高速にリモートホストのポートチェックを3パケットで実現する実装を行うために、RAWソケットとユーザランドの簡易TCPスタックを実装してパケットを放出しましたが、カーネルのTCPスタックによって自動的にRSTパケットが返されるため、RSTパケットが返されるよりもはやくrecvfromしないとSYN+ACKを受け取れないと述べました。 しかし、以下のようにご指摘を頂き、 @matsumotory LinuxのSOCK_RAW+IPPROTO_TCPの場合、カーネルがRSTを送出したとしても同マシン上の既存raw socketに対するrecvfrom()が0を返すことはないと思うのですが、検証されているカーネルのバージョンはいくつでしょうか？— Hiroki Sato (@
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く