TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
SSLv3脆弱性「POODLE」、TLSにも影響--グーグルの専門家が指摘
Googleに所属するSSL専門家のAdam Langley氏は米国時間12月8日、自身のブログで多くのTLS実装に対して警告を出した。以前明らかになった、SSLバージョン3（SSLv3）に影響する「POODLE（Padding Oracle On Downgraded Legacy Encryption）」攻撃と同じような攻撃につながる脆弱性を含んでいるという。 SSLv3は、CBCモードの暗号でデータのパディングを効果的に特定しない。そのため、ブロック暗号の整合性をきちんと確認できず、「パディングオラクル攻撃」を可能にしてしまう。SSLv3の後、仕様はTLSと改名され、バージョン1になった。TLSv1の変更点の1つとして、パディングオラクル攻撃を防ぐためのパディング処理を改善した。 だが、TLS実装でもパディングバイトのチェックは完全ではないという。多くのTLS実装がSSLv3ソフトウ
SSL3.0 徹底解剖！！！ 〜 なぜ POODLE に殺されたのか 〜 - もろず blog
©Copyright Yasuhiko Ito 10月の中旬ころに、google のセキュリティチームから POODLE という SSL3.0 の脆弱性が報告されたというニュースを見ました POODLE によって SSL3.0 の暗号通信が解読できることが実証されたので、今後 SSL3.0 は使わずに完全に捨てましょうという流れになっています 今回改めて調べてみると、SSL は過去にも CBC 暗号を使用した場合の脆弱性がいくつか報告されていました Padding Oracle 攻撃 (2002年) BEAST 攻撃 (2011年) Lucky Thirteen 攻撃 (2013年) これらの攻撃をなんとかしのいで生き残ってきた SSL3.0 でしたが、今回の POODLE が致命傷となってついに死んでしましました SSL3.0 の何がマズかったのか、どんな弱点があったのかを見ていきましょ
SSLv3で問題になるフィーチャーフォンの対応 - Qiita
docomoのiモードブラウザ1.0の機種を除き、殆どの場合TLSv1.0に対応しているようです。ただしコメント欄にもありますが、docomoに関しては、らくらくホンがiモードブラウザ1.0との記載がありますので、継続して注意が必要です。 TLSv1.0もそれほど使いたい規格ではないため「TLSv1.1以降にも対応しているよ！」みたいな情報引き続きお待ちしております。 更新履歴 2014/10/31: コメント欄にてauのすべての機種がTLSv1.0に対応している(ただしTLS拡張にはアップデートにより対応)ことを教えてもらったので修正しました。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back
自堕落な技術者の日記 : 様々なサーバーのPOODLE SSLv3脆弱性(CVE-2014-3566)対策のまとめ(更新3) - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 もくじ 1. はじめに 2. SSLv3を無効化できる場合のサーバー対策 2.1. Apache HTTPD Server + mod_ssl 2.2. Apache HTTPD Server + mod_nss 2.3. nginx 2.4. lighttpd 2.5. Microsoft IIS 2.6. (訂正)Apache Tomcat (Java JSSE) 2.7. Node.js 2.8. IBM HTTP Server 2.9. Amazon Web Services 2.10. その他のサーバー 2.11. SSLv3 を無効化するリスク 2.12. OpenLDAP 3. 諸般の事情で SSLv3 を有効にせざるを得ない場
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
