5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
CRYPTREC 運用ガイドラインWG活動報告
運用ガイドラインWG活動報告 1 主査 菊池 浩明 明治大学 背景1: スノーデン事件とフォワードセキュリティ Edward Joseph Snowden 元米中央情報局CIA職員、米国家安全保障局NSAへ出向 していた 2013年6月13日、香港英文紙に、米国政府が世界中の数 万の標的を対象に電話記録やインターネット利用を極秘裏 に監視していたことを暴露 Perfect Forward Secrecy (PFS)の重要性が再認識 PFS: ある時刻に長期鍵が漏洩しても、それ以前の暗号通 信の解読に影響を与えないこと RSA: PFSでない DH: PFSでない DHE (DH Ephemeral): PFSを満たす ECDHE (楕円版DHE): PFSを満たす 2 背景2: BEAST, POODLE攻撃 BEAST攻撃 CBCモードの脆弱性。ブロックの一部
Chromeで「接続は古い暗号化技術により暗号化されています」の表示条件 - ASnoKaze blog
最新のchromeでは表現が変わったようです。 「"このサイトへの接続では安全性の高いプロトコル バージョンと暗号スイートが使用されています。"」 security_info->is_secure_protocol_and_ciphersuite = (net::SSLConnectionStatusToVersion(security_info->connection_status) >= net::SSL_CONNECTION_VERSION_TLS1_2 && net::IsSecureTLSCipherSuite(net::SSLConnectionStatusToCipherSuite( security_info->connection_status)));https://code.google.com/p/chromium/codesearch#chromium/src/co
華麗なる因数分解:FREAK攻撃の仕組み - ぼちぼち日記
1. はじめに ちょうど今朝 OpenSSLをはじめとした様々なTLS実装の脆弱性の詳細が公表されました。 この InriaとMSRのグループは以前からTLSのセキュリティに関して非常にアクティブに調査・検証をしているグループで、今回も驚きの内容でした。 このグループは、TLSのハンドシェイク時の状態遷移を厳密にチェックするツールを開発し、様々なTLS実装の脆弱性を発見・報告を行っていたようです。 特にFREAKと呼ばれるOpenSSLの脆弱性(CVE-2015-0204)に関しては、ちょうど修正直後の1月初めに Only allow ephemeral RSA keys in export ciphersuites で見ていましたが、具体的にどのように攻撃するのかさっぱりイメージできず、あのグループだからまた超絶変態な手法だろうが、まぁそれほど深刻じゃないだろうと見込んでいました。 今回
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 の何がマズかったのか、どんな弱点があったのかを見ていきましょ
自堕落な技術者の日記 : 様々なサーバーの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 を有効にせざるを得ない場
TLSのダウングレード攻撃を防ぐSCSVとは
2018/01/09追記 TLS1.3の仕様ではダウングレード攻撃対策が異なっています。 TLS1.3もしくはTLS1.2に対応したサーバは、それ以下のTLSバージョンをねごシーエションする際はServerHelloのランダムの下位ビットに規定の文字列を挿入する決まりになりました。 クライアントはランダムの下位ビットを見てダウングレードしていないか確認します 2015/04/26追記 rfc7507としてTLSのSCSVはRFCとなりました。 draft-00よりIANA Considerationsの追加や、DTLSに関する記述が追加されています。 2015/08/04追記 中間者攻撃と言う表現は盗聴行為を含む攻撃であるが、今回は盗聴行為については必要が無いため表現を変更いたしました。 以上 ダウングレード攻撃 TLS通信を行う際、ハンドシェイクに失敗した場合にプロトコルのバージョンを下
IIS で SSL 3.0 を無効にする方法 - しばやん雑記
今朝は SSL 3.0 の脆弱性が話題になっていますね。ちなみに私も影響を受けました（死 SSL 3.0に深刻な脆弱性「POODLE」見つかる Googleが対策を説明 - ITmedia ニュース 困らされて悔しいので、SSL 3.0 を IIS で無効化する方法を調べました。相変わらずレジストリ弄らないと変更できないのはどうかと思いつつ試します。 How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services How to Disable SSL 2.0 and SSL 3.0 in IIS 7 てか、何も考えずに Windows Server に IIS を追加すると、SSL 2.0 が有効になった状態になるのはいい加減にやめた方が良いのではないかと。 折角なので SSL 2.
This POODLE bites: exploiting the SSL 3.0 fallback
The latest news and insights from Google on security and safety on the Internet Anonymous said... Does this apply to SSLv2 as well? October 14, 2014 at 7:39 PM Scott Ruebush said... I can't wait to see POODLE take over the internet! Thank goodness we have heroes to save us from the evils of SSL 3.0 and such and such, etc. October 14, 2014 at 8:52 PM Paul said... Not sure how to enable TLS_FALLBACK
BlackHat2014USA_Prompt_20140808_J - 暗号プロトコル評価技術コンソーシアム CELLOS
Cryptographic protocol Evaluation toward Long-Lived Outstanding Security Consortium [2014/8/08] Black Hat 2014 USAで発表されたSSL/TLSへの複数の新たな攻撃手法について 2014年8月6日（日本時間8月7日早朝）、Black Hat 2014 USA において Antoine Delignat-Lavaud 氏により SSL/TLS に対する複数の攻撃手法が発表されました [1]。公開された事後資料とデモ [2] では以下の3つのトピックが扱われています。 (1) Cookie Cutter attack : IEEE S&P2014 [3] で発表済み (2) Virtual Host Confusion (3) Triple Handshake : IEEE S&P20
Heartbleed検知スクリプトのバグについて
以下の記事を読みました。 Bugs in Heartbleed detection scripts. ちょうど昨日、Heartbleedの検知スクリプトをいくつか読んでブログまで書いたので非常に興味深い内容でした。 この記事の内容を簡単に箇条書きします。 Nessus、Metasploit、NmapなどいろいろなところからHeartbleedを検知する手段(スクリプト)がリリースされているが、そのほとんどにバグがある。実際は脆弱性がある(脆弱性が存在する可能性がある)のに、ないと判定してしまう。実際にいろいろなスクリプトを使って検証していた時に、スクリプトによって判定結果が違うことに気付いた。そこでスクリプトの処理を見たところバグを見つけた。Jared Staffordさんが書いたPoCには、“quick and dirty demonstration” と書いてある。このPoCが他の検知
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
Security/Server Side TLS - MozillaWiki
The ordering of cipher suites in the Old configuration is very important, as it determines the priority with which algorithms are selected. OpenSSL will ignore cipher suites it doesn't understand, so always use the full set of cipher suites below, in their recommended order. The use of the Old configuration with modern versions of OpenSSL may require custom builds with support for deprecated ciphe
Pythonでストリーム暗号RC4を実装し、脆弱性の一端を垣間見る - ももいろテクノロジー
この頃、SSLの暗号化などにストリーム暗号RC4を使わないほうがいいといった話がよく聞かれるようになった。 2013年版のCRYPTREC暗号リストでも128bitのRC4が「運用監視暗号リスト」に入っているし、先日には、Microsoftからストリーム暗号RC4を使わないようにというセキュリティアドバイザリが出ている。 CVEとしては今年の3月に出ているようだ。 NVD: Vulnerability Summary for CVE-2013-2566 JVNDB-2013-001910 そこで、ここでは実際にPythonでRC4を実装し、RC4の脆弱性に関する簡単な例を再現してみる。 ストリーム暗号とは何か 暗号には大きく分けて公開鍵暗号と共通鍵暗号がある。 公開鍵暗号は、他人に見られても大丈夫な鍵（公開鍵）と自分だけが知っている鍵（秘密鍵）のペアを使って暗号化するもので、代表的なものに
SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTPS設定ファイル生成ツール0.3(ベータ版)
DeNA Engineering - DeNAエンジニアのポータルサイト
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
How to fix SSL 2.0 and BEAST on IIS
クロスルート証明書に潜む危険性 | ScanNetSecurity
