HTTP/2 Rapid Reset：記録的な攻撃を分解する(翻訳記事）
この記事は以下のブログの翻訳です。 公式翻訳が完了次第削除します。 技術情報に誤りがある場合、遠慮なく、むしろ積極的に@kameoncloudまで連絡下さい。 2023年8月25日から、多くのお客様を襲った異常に大規模なHTTP攻撃に気付き始めました。これらの攻撃は当社の自動DDoSシステムによって検知され、軽減されました。しかし、これらの攻撃が記録的な規模に達するまでそれほど時間はかかりませんでした。これは、過去最大の攻撃の約3倍の規模でした。 懸念されるのは、攻撃者がわずか2万台のボットネットでこのような攻撃を行えたという事実である。今日では、数十万台から数百万台のマシンで構成されるボットネットが存在する。ウェブ全体のリクエスト数は通常1秒間に10億から30億に過ぎないことを考えると、この方法を使えば、ウェブ全体のリクエストに相当するものを少数のターゲットに集中させることができる可能性
HTTP/2 Rapid Reset Attack Impacting F5 NGINX Products - NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack | Google Cloud Blog
Hear monthly from our Cloud CISO in your inboxGet the latest on security from Cloud CISO Phil Venables. Subscribe A number of Google services and Cloud customers have been targeted with a novel HTTP/2-based DDoS attack which peaked in August. These attacks were significantly larger than any previously-reported Layer 7 attacks, with the largest attack surpassing 398 million requests per second. The
JVNVU#99039870: HTTP WebプロキシやWebアクセラレータのHTTP/2実装不備によるHTTPリクエストスマグリングの脆弱性
JVNVU#99039870 HTTP WebプロキシやWebアクセラレータのHTTP/2実装不備によるHTTPリクエストスマグリングの脆弱性 HTTP/2をサポートするHTTP WebプロキシやWebアクセラレータに対して、HTTP/1への変換処理の実装不備によりHTTP Request Smuggling攻撃が可能になる脆弱性が報告されています。 HTTP/2 をサポートするWebプロキシやアクセラレータを、HTTP/1 のみをサポートしているWebサーバと組み合わせて使用している場合、HTTP/2リクエストはHTTP/1リクエストに変換されてWebサーバに届けられます。 一部のWebプロキシやアクセラレータでは、HTTP/2からHTTP/1への変換処理において、不正な形式のリクエストやレスポンスを生成してしまうことが報告されています。 例えば、HTTP/1リクエスト(やレスポンス)で
Parallel streaming of progressive images
Progressive image rendering and HTTP/2 multiplexing technologies have existed for a while, but now we've combined them in a new way that makes them much more powerful. With Cloudflare progressive streaming images appear to load in half of the time, and browsers can start rendering pages sooner. In HTTP/1.1 connections, servers didn't have any choice about the order in which resources were sent to
gRPC Unary RPC で HTTP/2 の通信を追ってみる - 理系学生日記
gRPC でいろいろとトラブルが起きており、そのトラブルシュートをしようと思っています。 しかし、gRPC は HTTP/2 の上で動作するプロトコルであり、HTTP/2 の RFC を見ても、イマイチ HTTP/2 が見えてこない。HTTP/2 のプロトコルが見えないと、gRPC の挙動が正しいのかどうかもわからない。 というわけで、gRPC を通して HTTP/2 の挙動を知ろうというコーナーです。 HTTP/2 の特徴 Stream 多重化 Stream は状態を持っている 通信の流れを追ってみる netstat wireshark Connection Preface SETTINGS フレーム リクエスト送信 レスポンス受信 この他 HTTP/2 の特徴 HTTP/2 の RFC 他を読み、ぼくの理解している HTTP/2 の特徴をいくつか挙げてみます。 Stream 多重化 H
Wireshark で gRPC・HTTP/2 通信をキャプチャしても TCP としか判定されない - 理系学生日記
gRPC､および､その下で使われている HTTP/2 について､パケットキャプチャして解析しようとしていました。 パケットキャプチャといえば､wireshark ですが､gRPC の通信をキャプチャしても､gRPC でも HTTP/2 でもなく､TCP としか判定されないということになってしまいました。なお､ Wireshark の Version は 3.0.1 です。 どうしたものかと思っていたら､wiki の方にヒントがしれっと書かれておりまして。 need to use Decode as HTTP2 とのこと。これを実現するために､右クリックして Decode As ... を選択します。 そうすると､ダイアログが開くので､ Current カラムの値を HTTP2 にしましょう。 キャプチャ結果の画面に切り替わり､ HTTP2 や GRPC がプロトコルとして認識されるようにな
Why Turning on HTTP/2 Was a Mistake - Lucidchart
Why Turning on HTTP/2 Was a Mistake. HTTP/2 is a great leap forward for HTTP. It increases bandwidth efficiency by using a binary compressed format for headers, decreases latency by multiplexing requests on the same TCP connection, and allows the client to specify priorities for requests. In many cases moving to HTTP/2 is the right thing to do, but for some applications, HTTP/2 can cause significa
これからドンドン使われていくSNIについて
SNIとは元々SSL通信は1つのIPアドレスに対して、1つの証明書が前提になっていました。というのもSSLでは暗号化されているため、1つのIPアドレスに対して複数の証明書を持っていた場合、リクエストが来たときにどの証明書を使えばいいか判断できないからです。 しかしこれだとどう考えてもつらいことが分かります。昨今の流れとして常時SSL通信が当たり前の世界になりつつあります。すべてのドメインに対して全てのIPアドレスを用意するのは特にIPv4では現実的ではありません。 そもそもHTTPではVirtual Hostを使って、1つのIPアドレスで複数のドメインのサイトを扱うことがとても一般的です。 そこで有用なのがSNIです。SNIは最初の通信時に今から通信したいサーバーネームをサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。 SNIを使うことでHTTPのVirtual Host
Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowat
Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowat10/12/2018 Getting the best end-user performance from HTTP/2 requires good support for resource prioritization. While most web servers support HTTP/2 prioritization, getting it to work well all the way to the browser requires a fair bit of coordination across the networking stack. This article will expose some of the interactions betwe
pixivのHTTP/2有効化の軌跡 - pixiv inside
@catatsuyです。普段はpixivの技術的な改善や広告周りを見ています。今回はHTTP/2の話を紹介します。 HTTPS化とHTTP/2について 以前紹介したようにpixivは2017/4/18にHTTPS化を完了していました。 pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside pixivを常時HTTPS化するまでの道のり（後編） - pixiv inside 昨今ブラウザで使える新しい技術はHTTPSが必須要件とされることが多くなりました。その中の代表格がHTTP/2です。HTTP/2自体はHTTPSを要求していませんが、実際にはHTTPSでなければブラウザ側で有効にならないため必須です。 HTTP/2に対応するメリットは他の詳しい記事を参照して欲しいですが、ざっくり以下のメリットがあります。 HPACKという仕様でハフマン符号を使ったHTTPヘッ
カオステストでHTTP/2の問題を見つけ出す | POSTD
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
NginxがHTTP2サーバプッシュに対応したので試す - ASnoKaze blog
追記 [nginx-announce] nginx-1.13.9 http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html 1.13.9でサーバプッシュがサポートされました 先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。 HTTP/2: server push. http://hg.nginx.org/nginx/rev/641306096f5b ビルド $ git clone https://github.com/nginx/nginx.git $ cd ./nginx $ ./auto/configure --with-http_ssl_module --with-http_v2_module $ make $ sudo make install #一旦インストールしてしまう 設定 一
HTTP/2が速いという幻想 - Webパフォーマンスについて
難しい話じゃないです。 皆さん、ご自分でChrome Developer Toolで簡単に確認できますから、やってみて下さい。 このブログでも、過去に統計分析をした結果は掲載したんですが、「盲信」はそうそう簡単には消えないようでして… takehora.hatenadiary.jp takehora.hatenadiary.jp 以下の図は、Chrome 63.0.3239.108での結果です。 CDNにFastlyでもAWS CloudFrontでも、どのCDNを使って実験して頂いても結構です。 CDNを使わずに、Webサーバ単体でも結構です。 同様の結果になります。 どちらもHTTPS通信です。 どちらも同じオリジン、同じファイル構成です。 HTTP/1.1は、Keep-Alive設定が入っています。 HTTP/1.1での配信 … Load Event 70ms HTTP/2での配信
HTTP/2 のコネクション再利用について確認してみる - ブログ・ア・ラ・クレーム
はじめに 本記事は http2 Advent Calendar 2015 の 12 日目の記事となります。 本記事では HTTP/2 における TCP コネクション再利用とその周辺仕様を確認してみようと思います。コネクション再利用の挙動を理解することは、実際の Web サイトにおける HTTP/2 のデプロイの助けになると思われます。 HTTP/1.1, HTTP/2 での TCP コネクション管理 よく訓練された方々には既知のことかとは思いますが、 HTTP/2 において HTTP/1.1 の頃にあった性能向上の為のハックであるドメインシャーディングは好ましくないテクニックになってしまいます。 HTTP/1.1 において今日のブラウザは 1 ドメインあたり概ね 6 TCP コネクションほど張って、並列にリクエストを送るような振る舞いをします。このため Web サイトなどで参照するドメイン
HTTP/2の特徴 HTTP/1.1との違いについて | REDBOX Labo
今回は高速化手段の一つとして注目されているHTTP/2に関して、主な特徴HTTP/1.1との違いなどを紹介したいと思います。HTTP/2はHTTP/1.1と比べ様々な最適化がされています。 HTTP/2とはSPDYというプロトコルをご存じでしょうか。SPDYは2009年頃米GoogleによるWeb高速化の取り組みの一環から誕生しました。SPDYは従来から利用されているHTTPと互換性を保ちながらセッション層を効率化するプロトコルで、既にTwitterやFacebook、一部大手サイトなどが取り入れるようになりました。 HTTP/2はこのSPDYの進化版という位置づけで２０１５年５月にIETF（Internet Engineering Task Force）によって仕様の策定が進められ、RFC化を果たしました。そのためHTTP/2は従来のHTTPと互換性を保ちながら内部的な効率化がされていま
DNS Queries over HTTPS の標準化 （RFC8484） - ASnoKaze blog
20181020更新 RFC8484として標準化されました 「DNS Queries over HTTPS」の仕様の標準化が始まっている。 今までもこのテーマはIETFにおいて何度か議論になってきましたが、今回 DNS Over HTTPS (doh) WGの設立に合わせて(まだProposed)、この「DNS Queries over HTTPS」の標準化がマイルストーンとなっている。 今回の「DNS Queries over HTTPS」は、Googleの提供しているDNS over HTTPSとは全然違う仕様である点は注意が必要です。GoogleのものはクエリとレスポンスをJson形式で構造化するが、今回は比較的素のDNSクエリをHTTPSで送り合う仕様である(今後JSON形式をサポートする可能性はあります)。 このプロトコルではHTTP/2を使う必要があります(MUST)。HTTP
A Comprehensive Guide To HTTP/2 Server Push — Smashing Magazine
In this article, Jeremy Wagner will teach you everything about server push, from how it works to the problems it solves. Server push allows you to send site assets to the user before they’ve even asked for them. It’s an elegant way to achieve the performance benefits of HTTP/1 optimization practices such as inlining, but without the drawbacks that come with that practice. Jeremy will also show you
HTTP/2 is now in General Availability
HTTP/2 is now in General AvailabilityWe’re pleased to announce that HTTP/2 is now in General Availability (GA). Our team has been working diligently to tightly integrate HTTP/2 support into our existing environment. We’ve taken measures to ensure that our design and testing of this component adheres to the HTTP/2 protocol standards and can be seamlessly deployed across our entire network. Enabling
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - google/node-h2-auto-push: HTTP/2 automatic server push
