HTTP/2: Faster and better than HTTP 1.1, but is it more secure? | ImpervaImperva named a security leader in the SecureIQlab CyberRisk ReportGet featured report
JVNVU#97485903: Apache HTTPD の HTTP/2 通信における X.509 クライアント証明書の認証処理の問題
Apache HTTPD では、HTTP/2 に対応するモジュール mod_http2 が、バージョン 2.4.17 から提供されています。mod_http2 は実験的なものであり、デフォルトではコンパイルされず、また、設定ファイルの初期設定では HTTP/1.1 のみが有効になっています。 Apache HTTPD は、HTTP/2 経由でリソースへのアクセスを提供する際に、クライアント証明書の検証結果を考慮していません。
HTTP/2時代のバックエンド通信検討メモ - ぼちぼち日記
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
「Firefox 37」の深刻な脆弱性を修正--HTTP/2 Alt-Svcを無効化
Mozilla Foundationの「Firefox」にウェブの暗号化実装に絡む脆弱性が発見され、米国時間4月3日のアップデートで修正された。この脆弱性を悪用すれば、悪意のあるウェブサイトが証明書の認証処理を迂回（うかい）することが可能になっていた。 Mozillaは3月31日に「Firefox 37.0」をリリースしていた。同バージョンではHTTP/2というインターネット標準がサポートされており、HTTPSがサポートされていない場合であっても、ウェブ接続時の暗号化通信が可能になっていた。その機能を実現するために、リダイレクションプロトコルを通じてページ間のエンドツーエンドの暗号化を強制するHTTP Alternative Services（Alt-Svcという名前でも知られている）という機能が実装されていた。 Alt-SvcはPCやモバイル機器とやり取りすることで、ウェブページへの代替
TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説) - ぼちぼち日記
1. はじめに、 Googleがハマったシリーズ第3弾。今度は Chrome の脆弱性がテーマです。 先日(8月12日頃）突然Google ChromeでSPDYの機能が一旦停止されました。CloudFareの人が気づいてspdy-devへのMLの問い合わせし、すぐGoogleのaglさんからの返事で計画的で一時的なものであることがわかりました。 twitterやfacebookもSPDYが全て使えなくなり非常に驚いたのですが、直後に Chrome の Stable/Beta/Dev チャンネルがアップデートされ、ほどなくして問題なくSPDYが使えるようになりました。 この理由は公式には明らかにされていませんが、Chromeのリリースアナウンスにヒントがありました。そこには、 High CVE-2014-3166: Information disclosure in SPDY. Credi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NVD - CVE-2015-8659
