POODLE攻撃の検知とJavaによる検証コード
はじめに SSLv3のパディングに注目した攻撃手法であるPOODLEは、以前こちらのブログのエントリで取り上げたことがあるBEASTとCRIMEに非常によく似た攻撃です。今回はこのPOODLEについて、一般的な視点とはやや異なる、筆者独自の意見を述べてみたいと思います。 必ずしもSSLv3を無効にする必要はない POODLEの対策として書かれている情報はそのほぼ全てが「SSLv3を無効にする」というものですが、個人的には技術的にもう少し踏み込んで考えてみても良いのではないかと感じます。私は以前のエントリで次のように指摘しています。 BEASTもCRIMEも、意図しないリクエストが飛ばされ、そこにCookieが自動的に含まれてしまう点を攻撃するという意味で、CSRF攻撃の一種だと言えるでしょう。BEASTが発表されたらBEAST対策（RC4にする/TLSをバージョンアップする）を行い、CRI
シマンテック、SSL 3.0の脆弱性「Poodle」のリスクと対処法を解説
シマンテックは10月20日、同社のブログに、SSL 3.0の脆弱性「Poodle」のリスクに関する解説記事を掲載した。SSL 3.0は古いプロトコルながら、多くの WebブラウザとWeb サーバでサポートされているため、脆弱性は現在でも悪用される恐れがあるという。 現在、SSLの代わりに後継のプロトコルであるTLSが広く利用されているが、多くのTLSクライアントは、レガシーサーバと通信する必要がある場合に、使用するプロトコルをSSL 3.0にダウングレードするという。したがって、新たなプロトコルがサポートされている場合でも、攻撃者がサーバで使用可能なプロトコルを検証するハンドシェイクプロセスを侵害すると、 SSL 3.0の使用を強制できてしまうため、脆弱性が存在することになる。 脆弱性を発表したGoogleによると、攻撃者がその悪用に成功すると、中間者（MITM）攻撃を実行してセキュアHT
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
