List of ssl/tls - Baldanders.info
tag:Baldanders.info,0001-01-01:/tags
0001-01-01T00:00:00+00:00
バルトアンデルスは連続的な怪物,時間の怪物である。(ホルヘ・ルイス・ボルヘス 『幻獣辞典』より)
https://baldanders.info/images/avatar.jpg
https://baldanders.info/images/avatar.jpg
GnuPG 2.1.4 リリース,他
tag:Baldanders.info,2015-05-24:/blog/000847/
2015-05-24T09:00:00+00:00
2015-05-24T09:00:00+00:00
GnuPG 2.1.4 リリース / VENOM 脆弱性および Logjam 攻撃について
Spiegel
/profile/
<section> <h3>GnuPG 2.1.4 リリース</h3> <p> 2週間前の話ですみません。 </p><ul> <li><a href="https://lists.gnupg.org/pipermail/gnupg-announce/2015q2/000366.html">[Announce] GnuPG 2.1.4 released</a></li> </ul><p> 今回もセキュリティ・アップデートはなし。 まぁ modern バージョンは試行錯誤が多いのでこういうのも致し方ない。 </p><ul> <li>gpg: Add command --quick-adduid to non-interactively add a new user id to an existing key.</li> <li>gpg: Do no enable honor-keyserver-url by default. Make it work if enabled.</li> <li>gpg: Display the serial number in the --card-status output again.</li> <li>agent: Support for external password managers. Add option --no-allow-external-cache.</li> <li>scdaemon: Improved handling of extended APDUs.</li> <li>Make HTTP proxies work again.</li> <li>All network access including DNS as been moved to Dirmngr.</li> <li>Allow building without LDAP support.</li> </ul><p> Windows 用のバイナリも出ている。 </p> <pre class="brush:bash gutter:false" title="GnuPG 2.1.4">C:>gpg --version
gpg (GnuPG) 2.1.4
libgcrypt 1.6.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
<p>Home: ********
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2</pre></p>
</section>
<section>
<h3>VENOM 脆弱性および Logjam 攻撃について</h3>
<p>
VENOM 脆弱性および Logjam 攻撃について, Qiita にメモ書きしておいた。
</p><ul>
<li><a href="http://qiita.com/spiegel-im-spiegel/items/a6e149b41115bee6b41c">セキュリティ - VENOM 脆弱性について - Qiita</a></li>
<li><a href="http://qiita.com/spiegel-im-spiegel/items/af0cdb620ad79c4d0f36">セキュリティ - TLS における Diffie-Hellman 鍵交換の脆弱性 - Qiita</a></li>
</ul><p>
最近は脆弱性情報を収集する際に markdown 形式でメモをとっているのだが,特に公開してなかった(<a href="https://gist.github.com/spiegel-im-spiegel/47f340122c895ccc8bb8">FREAK 情報は Gist</a> に貼ってある)。
<a href="https://medium.com/@tsukamoto">Makio Tsukamoto</a> さんの「<a href="https://medium.com/@tsukamoto/-43a810cfe980">ググれるメモの勧め</a>」や「<a href="http://qiita.com/tsukamoto/items/d5dee47ecea2f42b3dbd">VMware製品へのVENOM脆弱性の影響情報</a>」を見て「公開できる情報なら公開すればいいやん」と思い立った。
</p><p>
Movable Type のような「ブログ」はいったん記事を書くと更新するのが結構面倒くさかったりするが, Qiita の場合は本当にメモ書きに近い感覚でいくらでも書き直せるので便利だったりする。
いずれこれはこのサイトでも取り入れたい。
もう日記やブログのような時系列の logging は私の中であまり意味をなさなくなりつつある。
</p><p>
気をつけるポイントは
</p>
<figure>
<blockquote>
<q>メモをインターネット上に残すときには、特に「インターネット上にある情報だけで構成されていること」を確認する</q>
</blockquote>
<figcaption><q><a href="https://medium.com/@tsukamoto/-43a810cfe980">ググれるメモの勧め</a></q>より</figcaption>
</figure>
<p>
ことだろう。インターネット上の情報が1次情報とは限らないが,公開されている情報だけで公開情報を構成するというのは結構重要かもしれない。
</p><p>
ところで Logjam って Log Jam と関係ある?
</p>
<figure style="margin:0 auto;text-align:center;" lang="en">
<iframe width="500" height="281" src="https://www.youtube.com/embed/txiucVjW0lA" frameborder="0" allowfullscreen=""></iframe>
<figcaption>via <q><a href="https://www.youtube.com/watch?v=txiucVjW0lA">Log Jam - The Log - YouTube</a></q></figcaption>
</figure>
</section>
IPA による「SSL/TLS暗号設定ガイドライン」
tag:Baldanders.info,2015-05-14:/blog/000843/
2015-05-14T09:00:00+00:00
2015-05-14T09:00:00+00:00
とりあえずエンジニアは全員目を通しておくことをお勧めする。IPA の示すセキュリティ要件を怠ったせいで多額の賠償金を払わされた例もあるのでお気をつけあれ。
Spiegel
/profile/
<p> (<a href="http://qiita.com/spiegel-im-spiegel/items/6a3e9ecb82f596bea0ff">同じものを Qiita に投稿</a>しています) </p><p> IPA から「<a href="http://www.ipa.go.jp/security/vuln/ssl_crypt_config.html">SSL/TLS暗号設定ガイドライン</a>」が公開されている。 一般ユーザ向けの軽いもの(ルータやブラウザの設定とか)と思ったらさにあらずで, <a href="http://www.cryptrec.go.jp/">CRYPTREC</a> の手によるかなり詳細な内容だった。 </p><p> とりあえずエンジニアとネットワーク管理者は全員目を通しておくことをお勧めする。 <a href="https://baldanders.info/blog/000797/">IPA の示すセキュリティ要件を怠ったせいで多額の賠償金を命じられた例</a>もあるのでお気をつけあれ。 </p><p> 内容はこんな感じ。 </p> <figure> <blockquote> <ul> <li>第1章と第2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識をまとめています。</li> <li>第3章ではSSL/TLSサーバに要求される設定基準の概要について説明しています。</li> <li>第4章から第6章では、第3章で定めた設定基準に基づき、プロトコルバージョン、サーバ証明書、暗号スイートについての具体的なSSL/TLSサーバの要求設定項目について示しています。ここでの要求設定項目は別紙のチェックリストで確認が求められる項目となります。</li> <li>第7章では、チェックリストの対象には含めていませんが、SSL/TLSを安全に使うために考慮すべきことをまとめています。</li> <li>第8章は、クライアントの一つであるブラウザの設定に関する事項を説明しており、ブラウザの利用者に対して啓発するべき事項を取り上げています。</li> <li>第9章は、そのほかのトピックとして、SSL/TLSを用いたリモートアクセス技術(“SSL-VPN”とも言われる)について記載しています。</li> <li>Appendixには、4章から6章までの設定状況を確認するためのチェックリストや、個別製品での具体的な設定方法例を記載しています。</li> </ul> </blockquote> <figcaption><q><a href="http://www.ipa.go.jp/security/vuln/ssl_crypt_config.html">SSL/TLS暗号設定ガイドライン~安全なウェブサイトのために(暗号設定対策編)~</a></q>より</figcaption> </figure> <p> チェックリストは PDF および Excel で提供されている。 参考にされるとよいと思う。 </p>
FREAK の CVSS 基本値は 7.8
tag:Baldanders.info,2015-03-09:/blog/000818/
2015-03-09T09:00:00+00:00
2015-03-09T09:00:00+00:00
先週から世間を騒がせている FREAK(Factoring attack on RSA-EXPORT Keys)だが, CERT/CC から具体的なレポートが出ている。
Spiegel
/profile/
<p> 先週から世間を騒がせている FREAK(Factoring attack on RSA-EXPORT Keys)だが, CERT/CC から具体的なレポートが出ている。 </p><ul> <li><a href="http://www.kb.cert.org/vuls/id/243585">Vulnerability Note VU#243585 - SSL/TLS implementations accept export-grade RSA keys (FREAK attack)</a></li> <li><a href="https://jvn.jp/vu/JVNVU99125992/index.html">JVNVU#99125992: SSL/TLS の実装が輸出グレードの RSA 鍵を受け入れる問題 (FREAK 攻撃)</a></li> </ul><p> 注目すべきは CVSS 評価値。 <a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0204">CVE-2015-0204</a> では 5.0 だったが, <a href="http://www.kb.cert.org/vuls/id/243585">VU#243585</a> では 7.8 に跳ね上がっている(一般的には CVSS 基本値が 7 以上で「危険」とみなされる)。 </p><p> 具体的には <a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0204">CVE-2015-0204</a> では </p> <figure class="center"> <table> <tbody> <tr><td class="right">攻撃元区分(AV)</td> <td class="left">ネットワーク(N)</td></tr> <tr><td class="right">攻撃条件の複雑さ(AC)</td> <td class="left">低(L)</td></tr> <tr><td class="right">攻撃前の認証要否(Au)</td> <td class="left">不要(N)</td></tr> <tr><td class="right">情報漏えいの可能性(機密性への影響, C)</td><td class="left">なし(N)</td></tr> <tr><td class="right">情報改ざんの可能性(完全性への影響, I)</td><td class="left">部分的(P)</td></tr> <tr><td class="right">業務停止の可能性(可用性への影響, A)</td> <td class="left">なし(N)</td></tr> </tbody> </table> <figcaption><a href="http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0204">CVE-2015-0204</a>: CVSS 基本評価</figcaption> </figure> <p> だったのが,<a href="http://www.kb.cert.org/vuls/id/243585">VU#243585</a> では </p> <figure class="center"> <table> <tbody> <tr><td class="right">攻撃元区分(AV)</td> <td class="left">ネットワーク(N)</td></tr> <tr><td class="right">攻撃条件の複雑さ(AC)</td> <td class="left">低(L)</td></tr> <tr><td class="right">攻撃前の認証要否(Au)</td> <td class="left">不要(N)</td></tr> <tr><td class="right">情報漏えいの可能性(機密性への影響, C)</td><td class="left">全面的(C)</td></tr> <tr><td class="right">情報改ざんの可能性(完全性への影響, I)</td><td class="left">なし(N)</td></tr> <tr><td class="right">業務停止の可能性(可用性への影響, A)</td> <td class="left">なし(N)</td></tr> </tbody> </table> <figcaption><a href="http://www.kb.cert.org/vuls/id/243585">VU#243585</a>: CVSS 基本評価</figcaption> </figure> <p> となった。 具体的な攻撃手法が明らかになったことで,機密性への影響が「なし」から「全面的」になっているようだ(その代わり完全性への影響は「なし」になった。改ざんの可能性はないと見ているということだろうか)。 もっとも <a href="http://www.kb.cert.org/vuls/id/243585">VU#243585</a> の評価でも CVSS の現状評価(3月9日時点)では </p> <figure class="center"> <table> <tbody> <tr><td class="right">攻撃される可能性(E)</td> <td class="left">攻撃可能(F)</td></tr> <tr><td class="right">利用可能な対策のレベル(RL)</td><td class="left">正式(OF)</td></tr> <tr><td class="right">脆弱性情報の信頼性(RC)</td> <td class="left">確認済(C)</td></tr> </tbody> </table> <figcaption><a href="http://www.kb.cert.org/vuls/id/243585">VU#243585</a>: CVSS 現状評価(3/11 更新)</figcaption> </figure> <p> ということで,現状値は 6.4。 「容易に攻撃可能」とまではいかないので,今のうちにしっかり対策しておくことが肝心である。 </p><p> (余談だが,随分昔に <a href="https://baldanders.info/spiegel/archive/cvss/cvss2j.html">CVSS のデモページ</a>を作っている。よかったらこれで遊んでみてください) </p><p> あるサーバが危険かどうかは “<a href="https://www.ssllabs.com/ssltest/">SSL Server Test</a>” でチェックすることで確認できる。 たとえば hatena.ne.jp は最初 FREAK の影響を受けていたが,その後対策していることがこれで確認できる。 ただし hatena.ne.jp はいまだに POODLE を放置(つまり SSL 3.0 を許可)したままだけどね。 RC4 も有効にしたままだし(まぁ国内の Web サーバは大概そうみたいだけど。いい加減 XP/IE6 は捨てなさいよ。ちなみに <a href="https://baldanders.info/blog/000810/">TLS で RC4 を使うのは禁止になった</a>)。 </p><p class="offrec"> (そういえば「TLS にまた脆弱性」みたいな馬鹿タイトルを付けてるメディアを見たが,近年 SSL/TLS などの暗号周りのセキュリティ研究は急速に進んでいる。 今回の FREAK にしたって,まさか「そんな奴おれへんやろ」と思ってたのがかなりの数いてビックリした,ってのが真相らしい。 おそらく今年も暗号周りの脆弱性はたくさん出てくると思われる。 それはそれだけセキュリティ評価が進んでいるということなのである) </p><p> FREAK については <a href="https://gist.github.com/spiegel-im-spiegel/47f340122c895ccc8bb8">Gist にまとめている</a>ので,よろしかったらどうぞ。 再利用(fork)歓迎! </p> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4314009071/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51ZRZ62WKCL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4314009071/baldandersinf-22/">暗号化 プライバシーを救った反乱者たち</a></dt><dd>スティーブン・レビー 斉藤 隆央 </dd><dd>紀伊國屋書店 2002-02-16</dd><dd>評価<abbr class="rating" title="5"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-5-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/487593100X/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/487593100X.09._SCTHUMBZZZ_.jpg" alt="ハッカーズ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4105393022/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4105393022.09._SCTHUMBZZZ_.jpg" alt="暗号解読―ロゼッタストーンから量子暗号まで"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4484111160/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4484111160.09._SCTHUMBZZZ_.jpg" alt="グーグル ネット覇者の真実 追われる立場から追う立場へ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/410215972X/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/410215972X.09._SCTHUMBZZZ_.jpg" alt="暗号解読〈上〉 (新潮文庫)"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4102159738/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4102159738.09._SCTHUMBZZZ_.jpg" alt="暗号解読 下巻 (新潮文庫 シ 37-3)"/></a> </p> <p class="description">20世紀末,暗号技術の世界で何があったのか。知りたかったらこちらを読むべし!</p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2015-03-09">2015/03/09</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51njmeGhpKL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/">新版暗号技術入門 秘密の国のアリス</a></dt><dd>結城 浩 </dd><dd>SBクリエイティブ株式会社 2013-12-04</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H40/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00H372H40.09._SCTHUMBZZZ_.jpg" alt="プログラマの数学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMJ0/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMJ0.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/整数で遊ぼう"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00IP549AE/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00IP549AE.09._SCTHUMBZZZ_.jpg" alt="インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMIQ/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMIQ.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/式とグラフ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMK4/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMK4.09._SCTHUMBZZZ_.jpg" alt="数学ガール/ガロア理論"/></a> </p> <p class="description">まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。</p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-09-18">2014/09/18</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div>
HTTPS Deep Inspection
tag:Baldanders.info,2015-02-27:/blog/000812/
2015-02-27T09:00:00+00:00
2015-02-27T09:00:00+00:00
銀行や病院,あるいは政府組織などのミッション・クリティカルな環境では,かなり高めにリスクが見積もられる。こういった環境では通信統制は比較的やりやすい。
Spiegel
/profile/
<p> Facebook で指摘されたのだが,確かに世に出ているセキュリティ製品には HTTPS セッションを横取りし復号化(ここでは仮に HTTPS Deep Inspection と呼んでおく)してしまうものがある。 セキュリティ企業の老舗である McAfee や Symantic にもそういった製品がある(ただし既定では無効になっている)。 最近ではこんな記事があった。 </p><ul> <li><a href="http://ascii.jp/elem/000/000/978/978693/">ASCII.jp:「SSL暗号化通信に隠れた攻撃をあぶり出す」ブルーコート</a></li> </ul> <figure> <blockquote> <q>コールソン氏によれば、「すでに企業トラフィックの30~40%はSSLトラフィックが占めている」という。そして今後、その割合はさらに増えていくはずだ。だが同時に、これがマルウェアの侵入路にもなっていると、コールソン氏は警告する。たとえば標的型攻撃などで、企業内に侵入したマルウェアが外部のC&Cサーバーとやり取りし、企業の機密情報を外部に送信しているとしても、トラフィックが暗号化されてしまえば完全に“見えなく”なってしまう。そして、実際にその悪用が始まっているという。</q> </blockquote> <figcaption><q><a href="http://ascii.jp/elem/000/000/978/978693/">「SSL暗号化通信に隠れた攻撃をあぶり出す」ブルーコート</a></q>より</figcaption> </figure> <p> 暗号化通信の目的は第3者による通信の傍受・改ざんの防止であり,通信の中身は関知しない。 特に近年注目されている APT(Advanced Persistent Threats)は乗っ取った端末機から機密情報を「持ち出す」のだが,この際に HTTPS などの暗号化通信を使われると古いタイプの Firewall では検知できない。 </p><ul> <li><a href="http://www.ipa.go.jp/about/technicalwatch/20101217.html">IPA 独立行政法人 情報処理推進機構:IPAテクニカルウォッチ 『新しいタイプの攻撃』に関するレポート</a></li> </ul><p> HTTPS Deep Inspection はこういった問題に対して需要がある。 </p><p> 銀行や病院,あるいは軍や政府関係などの mission critical な環境では,かなり高めにリスクが見積もられる。 こういった環境では,通信統制は比較的やりやすい(<a href="http://ascii.jp/elem/000/000/978/978693/">上で紹介した記事</a>では「可視化」と呼んでいるが,これは明らかに統制である)。 HTTPS Deep Inspection を導入する企業・組織というのは,恐らくそういうところなんだろう。 セキュリティ製品を提供する側も企業なので対等な立場で partnership を結ぶこともできる。 </p><p> 一方で,たとえば近年流行りの BYOD(Bring Your Own Device)やクラウド型の情報基盤を導入している場合は HTTPS Deep Inspection はあまり役に立たない。 HTTPS Deep Inspection は Web Proxy あるいは Firewall に組み込まれるものだが,これは “Good man IN, Bad man OUT” を前提にしている。 しかし実際には,企業内ネットワークに malware が持ち込まれることもあるし,従業員が外から企業内ネットワークやクラウド上のリソースにアクセスすることもある。 </p><p> そして個人ユーザのレベルでは HTTPS Deep Inspection は到底許容できるものではない。 なぜならこれは,インターネットの “End to End” の原則を崩すものであり,ひいては「<a href="http://wired.jp/2015/02/07/aftermath01/">ネットの中立性</a>」に楔を入れるものだからだ。 私たちは HTTPS Deep Inspection やそれを組み込んだセキュリティ製品を慎重に排除していく必要がある。(<a href="https://baldanders.info/blog/000809/">malware</a> などもっての外) </p> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4757143044/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/413qoSjODUL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4757143044/baldandersinf-22/">信頼と裏切りの社会</a></dt><dd>ブルース・シュナイアー 山形 浩生 </dd><dd>エヌティティ出版 2013-12-24</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4622078007/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4622078007.09._SCTHUMBZZZ_.jpg" alt="殺人ザルはいかにして経済に目覚めたか?―― ヒトの進化からみた経済学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4152094184/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4152094184.09._SCTHUMBZZZ_.jpg" alt="自己が心にやってくる"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4826901763/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4826901763.09._SCTHUMBZZZ_.jpg" alt="モラルの起源―道徳、良心、利他行動はどのように進化したのか"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4492654585/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4492654585.09._SCTHUMBZZZ_.jpg" alt="それでも金融はすばらしい: 人類最強の発明で世界の難問を解く。"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4873117119/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4873117119.09._SCTHUMBZZZ_.jpg" alt="Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)"/></a> </p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2015-02-26">2015/02/26</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div>
Malware Spoofing HTTPS(3月2日,追記あり)
tag:Baldanders.info,2015-02-20:/blog/000809/
2015-02-20T09:00:00+00:00
2015-02-20T09:00:00+00:00
「Lenovo は何をやらかしたのか」から改題し,修正・追記しています。(3月2日)
Spiegel
/profile/
<p> (「Lenovo は何をやらかしたのか」から改題し,修正・追記しています) </p><p> いや,2月19日に <a href="http://jp.techcrunch.com/2015/02/19/20150218lenovo-superfish/">Techcrunch の記事</a>を見た時点ではよく分かってなかったのよ。 ただ,この問題を Lenovo が知ってるかどうかがポイントだなぁ,とは思ってた。 </p><p> で,夕方ネットをチェックしてたら詳しい解説が出てたんだけど </p><ul> <li><a href="http://d.hatena.ne.jp/nekoruri/touch/20150220/superfish">Superfishが危険な理由 - めもおきば</a></li> </ul><p> それによると,どうやらプリインストールの段階で Superfish のルート証明書がインストールされてしまっているらしい。 </p><p class="offrec"> (ちなみに「証明書」とは公開鍵暗号の公開鍵+電子署名と思っていただいて差支えない。 SSL/TLS で使用する公開鍵は必ず信用できる CA(Certification Authority; 認証局)による証明(電子署名)が必要である(自己署名のみは NG)。 CA の総元締めが「ルート CA」で,ルート CA 自身の証明書が「ルート証明書」である。 ルート CA を証明できる上位の CA は存在しないため,ルート証明書は例外として自己署名しかない) </p> <figure> <blockquote> <q>本来ならばSuperfish CAなんて得体の知れないCAは信頼されていないので警告が出るのですが、Microsoftの決めた基準に反して、Lenovoが勝手にこのSuperfish CAを信頼するように設定してPCを販売しています。</q> </blockquote> <figcaption><q><a href="http://d.hatena.ne.jp/nekoruri/touch/20150220/superfish">Superfishが危険な理由</a></q>より</figcaption> </figure> <p> いや,これもう完全に guilty です。 <a href="http://dic.pixiv.net/a/%E8%A3%81%E5%88%A4%E3%83%9E%E3%82%B7%E3%83%BC%E3%83%B3">裁判マシーン</a>にお仕置きされるレベル。 やっちゃいましたねぇ。 </p><p> とりあえず Lenovo マシンの証明書ストアに Superfish CA の証明書がないか確認すること。 よくわからないって方はテスト用のサイトがあるので是非確認を。 </p><ul> <li><a href="https://filippo.io/Badfish/">Check if you trust the Superfish CA</a></li> </ul><p> もし証明書が見つかったら Superfish をアンインストールした上で削除すること。 </p><ul> <li><a href="http://support.lenovo.com/us/en/product_security/superfish_uninstall">Superfish Uninstall Instructions - Lenovo Support (US)</a> (Lenovo によるアンインストール方法の解説ページ)</li> <li><a href="http://japan.zdnet.com/article/35060769/">MS、「Windows Defender」をアップデート--レノボPCに含まれていたSuperfishに対応 - ZDNet Japan</a>: ただし Mozilla Firefox などのサードパーティ製品は対象外 (2/26 追記)</li> </ul><p> で,話はこれで終わらない。 </p> <section> <h3>今回の件の何が拙いのか</h3> <p> Lenovo が仕込んだ Superfish の直接的な問題点は以下のとおり(unsignedint さん, follow ありがとうございます)。 </p><ol> <li>セッションを乗っ取る形で Web コンテンツを改ざんしていること。 途中で Web コンテンツを改ざんする手口は結構古典的だけど,現在ではこうした行為をするソフトウェア自体が「悪意のソフトウェア(malicious software; malware)」として認知さる。 更に今回は SSL/TLS のセッションを乗っ取り,なりすましを行う典型的な「中間者攻撃(Man-in-the-Middle Attack)」であると言える。</li> <li>いわゆる「オレオレ証明書」をプリインストールの段階で仕込んでいること。 しかもこれはルート CA の証明書なのが悪質。</li> <li>Superfish はルート CA を偽装しているが,非常に危険な形で実装されていること。 特に秘密鍵の保護がずさんなため,容易に他の malware も便乗できる。</li> </ol><p> 実はこれ,個々の要素技術(Web プロキシ,CA 機能,公開鍵暗号の鍵生成,証明書の発行 等)自体は難しくもなんともないのだ。 標準的な機能を組み合わせて Web の暗号通信を乗っ取れるということを Lenovo は code で証明してしまったのである。 </p><p> これは Lenovo 1社の信用問題などという矮小な話じゃないの。 SSL/TLS というか X.509 型 PKI(Public Key Infrastructure; 公開鍵基盤)の信用モデルを根底からぶっ壊してしまっている点が画期的なの。 </p> </section> <section> <h3>PKI の信用モデル</h3> <p> SSL/TLS に代表される X.509 型の PKI は CA の権威性で以って信用を託されている。 </p><p> 暗号技術や PKI をちょっとかじった人ならわかると思うけど,相手を「信用」する客観的・論理的な根拠というのは存在しないのだ。 だからどこかで割りきって「信用を託す」かたちで PKI は回っている。 </p><p> 例えば OpenPGP は「信用の輪(web of trust)」と呼ばれる信用モデルを採用していて,基本的にはユーザ間の直接のやりとりで以って信用を担保している。 こうして担保された信用を繋いでいって網(web)を構成するのである。 この場合,ユーザ間の信用に客観的・論理的な根拠はない。 直接やり取りしてるし,相手も正しく秘密鍵を取り扱ってくれるだろうという推定で以って信用している。 </p><p> 一方の X.509 はピラミッド型の構成になっていて,頂点となるルートCA をその権威性(曰く「私を信用しなさい」)で以って信用することにより下層の CA なり証明書なりを信用する仕組みになっている。 これを hierarchical PKI と呼ぶ。 この場合,ルート CA およびその証明書を信用する客観的・論理的な根拠はない。 ルート CA を管理している企業・組織が信用できることが絶対の前提条件である。 また Web ブラウザの場合はブラウザ・ベンダによってあらかじめインストールされているルート証明書をユーザは無条件で信用している(というよりそのような信用の構造になっていることすら知らないユーザも多いかもしれない)。 この前提条件が崩れると hierarchical PKI は瓦解する。 </p><p> 今回の Lenovo の行為は,この前提条件をぶっ壊してしまったのだ。 曰く「ルート CA に権威なんかねーんだよ」ってことだ。 これは昔あった特定のルート CA を乗っ取って偽の証明書を発行する,とかいう手口とは根本的に異なる(あるいは,個々のユーザが「第3者の証明? 要らんよ,そんなもん」とかいって自己署名のみのオレオレ証明書で運用するのとも違う)。 なんて COOL ! </p> </section> <section> <h3>さて今後は...</h3> <p> 今回のケースはだれにでも真似できる。 できることを証明してしまった。 ルート CA 機能を持った malware やルート証明書を仕込むのは少々難しいと思うが,所謂 social engineering の問題であり,ユーザを騙す方法はいくらでもある。 今回は PC だったけど Android や iOS 等の携帯端末でも可能(iOS は守られてるから無理,という人もいるかもしれないけど,<a href="http://japan.zdnet.com/article/35056364/">その前提は既に崩れている</a>ので悪しからず)。 </p><p> おそらくブラウザ側は何らかの対策を打ってくるだろう。 もうユーザ側で自由に証明書をインストールできなくなるかもしれない。 まぁでもそれも仕方のない事である。 Web の信用を失う訳にはいかないからだ。 </p><p> 問題はそれ以外の X.509 型 PKI を使う,おそらくは SSL/TLS アプリケーション。 一番危ないのは<a href="https://baldanders.info/blog/000773/">オレオレ・ルート CA を運用する OpenVPN サーバ</a>だろう。 これを乗っ取るのは簡単そうである(「オレオレ・ルート CA」なんか立ててる奴はセキュリティなんか気にしてないだろうしw どうせ OpenVPN もファッションだろう?)。 </p><p> まっ,これからが楽しみなことである。 </p> </section> <section> <h3>てなことを言っていたら(2月26日追記)</h3> <p> 驚愕の事実が次々と発覚! </p><p> まず <a href="http://www.komodia.com/ndis/">Komodia</a> 社が提供する Komodia Redirector に含まれる SSL Digestor モジュールが「オレオレ・ルート証明書」およびその秘密鍵をインストールすることが分かってきた。 Lenovo の Superfish もこれを使っているようだ。 Komodia Redirector を使っているベンダとして </p><ul> <li><a href="http://www.kb.cert.org/vuls/id/JLAD-9TWRP3">Atom Security, Inc</a></li> <li><a href="http://www.kb.cert.org/vuls/id/WDON-9TYMSL">Infoweise</a></li> <li><a href="http://www.kb.cert.org/vuls/id/JLAD-9TVS39">KeepMyFamilySecure</a></li> <li><a href="http://www.kb.cert.org/vuls/id/JLAD-9TVR4U">Komodia</a></li> <li><a href="http://www.kb.cert.org/vuls/id/AAMN-9TVVPE">Kurupira</a></li> <li><a href="http://www.kb.cert.org/vuls/id/BLUU-9TWT2Y">Lavasoft</a></li> <li><a href="http://www.kb.cert.org/vuls/id/BLUU-9TVLHL">Lenovo</a></li> <li><a href="http://www.kb.cert.org/vuls/id/JLAD-9TVS9D">Qustodio</a></li> <li><a href="http://www.kb.cert.org/vuls/id/JLAD-9TVR4K">Superfish</a></li> <li><a href="http://www.kb.cert.org/vuls/id/BLUU-9TWQMG">Websecure Ltd</a></li> </ul><p> が挙がっている。 なお,この Komodia Redirector について CERT では <a href="https://baldanders.info/blog/000334/">CVSS</a> 基本値を 8.5 (AV:N/AC:L/Au:N/C:C/I:P/A:N) と評価している。 </p><p> さらにさらに。 Komodia Redirector なんか目じゃない極悪ツールも存在するらしい。 </p><ul> <li><a href="https://blog.hboeck.de/archives/865-Software-Privdog-worse-than-Superfish.html">Software Privdog worse than Superfish - Hanno's blog</a></li> <li><a href="http://gigazine.net/news/20150223-comodo-adware-privdog-worse-superfish/">SSL証明書を発行する企業が証明書を偽造する悪質なアドウェア「Privdog」を販売していたことが判明 - GIGAZINE</a></li> </ul> <figure> <blockquote> <q>しかし、PrivDogは全ての証明書を傍受し、証明書をルート鍵により署名されたものに置き換えます。これは、あらゆる証明書が有効ではなくなることを意味し、さらにブラウザが全ての通信を承認してしまい、SSL通信におけるCAの役割が全く意味のないものになってしまう、ということも意味します。なお、Superfishではホストと同じ証明書と秘密鍵を使用するのですが、PrivDogは全てのインストール先で秘密鍵を再作成してしまう、とのことです。<br/> なお、そんなPrivDogを販売しているのは「Comodo Dragon browser」や「COMODO Internet Security」などの開発元であるComodo。ComodoはSSL認証局として証明書の発行サービスも行っているので、「自社で発行している証明書を自社が販売しているソフトウェアがニセの証明書に書き換えているかもしれない」、ということになります。</q> </blockquote> <figcaption><q><a href="http://gigazine.net/news/20150223-comodo-adware-privdog-worse-superfish/">SSL証明書を発行する企業が証明書を偽造する悪質なアドウェア「Privdog」を販売していたことが判明</a></q>より</figcaption> </figure> <p> なお,追記として </p> <figure> <blockquote> <q>SSLの証明書を傍受するのは「PrivDog 3.0.96.0」で、Comodoはこのバージョンのものを販売していないとのこと。</q> </blockquote> <figcaption><q><a href="http://gigazine.net/news/20150223-comodo-adware-privdog-worse-superfish/">SSL証明書を発行する企業が証明書を偽造する悪質なアドウェア「Privdog」を販売していたことが判明</a></q>より</figcaption> </figure> <p> とあるので,誰かが勝手に改変バージョンをばらまいている可能性もある。 </p><p> セキュリティ企業や組織は「脆弱性(vulnerability)」などと比較的穏当な表現をしているが,オレオレ・ルート証明書をインストールする行為自体が明確な「悪意」である。 なぜなら(上述した通り)これは PKI の信用モデルに対する攻撃(破壊)だからだ。 今回,問題のある Komodia Redirector を使用したベンダ企業(この中にはセキュリティ企業(?)も含まれるが)の名前は覚えておいたほうがよい。 </p> </section> <section> <h3>参考ページ(追記あり)</h3> <ul> <li><a href="https://www.us-cert.gov/ncas/alerts/TA15-051A">Lenovo Superfish Adware Vulnerable to HTTPS Spoofing | US-CERT</a> (2/21 追記)</li> <li><a href="https://www.schneier.com/blog/archives/2015/02/man-in-the-midd_7.html">Schneier on Security: Man-in-the-Middle Attacks on Lenovo Computers</a> (2/21 追記)</li> <li><a href="https://www.st.ryukoku.ac.jp/~kjm/security/memo/2015/02.html#20150223_lenovo">「セキュリティホール memo」の記事</a> (2/26 追記)</li> <li><a href="http://www.kb.cert.org/vuls/id/529496">Vulnerability Note VU#529496 - Komodia Redirector with SSL Digestor fails to properly validate SSL and installs non-unique root CA certificates and private keys</a> (2/26 追記)</li> <li><a href="http://www.kb.cert.org/vuls/id/366544">Vulnerability Note VU#366544 - Adtrustmedia PrivDog fails to validate SSL certificates</a> (2/26 追記)</li> <li><a href="http://jvn.jp/ta/JVNTA91476059/">JVNTA#91476059: Superfish がインストールされた Lenovo 製 PC に HTTPS スプーフィングの脆弱性</a> (2/26 追記)</li> <li><a href="http://jvn.jp/vu/JVNVU92865923/">JVNVU#92865923: Komodia Redirector がルート CA 証明書と秘密鍵をインストールする問題</a> (2/26 追記)</li> <li><a href="http://jvn.jp/vu/JVNVU91326102/">JVNVU#91326102: Adtrustmedia PrivDog に SSL サーバ証明書の検証不備の脆弱性</a> (2/26 追記)</li> <li><a href="http://japan.zdnet.com/article/35060816/">「Superfish」以外にもセキュリティを脅かすソフトが複数--研究者ら - ZDNet Japan</a> (2/26 追記)</li> <li><a href="http://pc.watch.impress.co.jp/docs/column/config/20150227_690371.html">【山田祥平のRe:config.sys】今見ているWebは本物か - PC Watch</a> (3/2 追記)</li> </ul><p> 手前味噌ですみません。 </p><ul> <li><a href="https://baldanders.info/spiegel/openpgp/">わかる! OpenPGP 暗号 — Baldanders.info</a> (「<a href="https://baldanders.info/spiegel/openpgp/#pki2">X.509 と OpenPGP</a>」の節あたりを参考にどうぞ)</li> </ul> </section> <section> <h3>参考図書</h3> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51njmeGhpKL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/">新版暗号技術入門 秘密の国のアリス</a></dt><dd>結城 浩 </dd><dd>SBクリエイティブ株式会社 2013-12-04</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H40/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00H372H40.09._SCTHUMBZZZ_.jpg" alt="プログラマの数学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMJ0/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMJ0.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/整数で遊ぼう"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00IP549AE/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00IP549AE.09._SCTHUMBZZZ_.jpg" alt="インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMIQ/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMIQ.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/式とグラフ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMK4/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMK4.09._SCTHUMBZZZ_.jpg" alt="数学ガール/ガロア理論"/></a> </p> <p class="description">まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。</p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-09-18">2014/09/18</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4757143044/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/413qoSjODUL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4757143044/baldandersinf-22/">信頼と裏切りの社会</a></dt><dd>ブルース・シュナイアー 山形 浩生 </dd><dd>エヌティティ出版 2013-12-24</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4622078007/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4622078007.09._SCTHUMBZZZ_.jpg" alt="殺人ザルはいかにして経済に目覚めたか?―― ヒトの進化からみた経済学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4152094184/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4152094184.09._SCTHUMBZZZ_.jpg" alt="自己が心にやってくる"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4826901763/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4826901763.09._SCTHUMBZZZ_.jpg" alt="モラルの起源―道徳、良心、利他行動はどのように進化したのか"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4492654585/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4492654585.09._SCTHUMBZZZ_.jpg" alt="それでも金融はすばらしい: 人類最強の発明で世界の難問を解く。"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4873117119/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4873117119.09._SCTHUMBZZZ_.jpg" alt="Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)"/></a> </p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2015-02-26">2015/02/26</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H0X4U24/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/41hlK3pm5iL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H0X4U24/baldandersinf-22/">這いよれ!ニャル子さん コスプレ 衣装 ニャルラトホテプ (黒メイド, Mサイズ)</a></dt><dd>香奈山堂 </dd></dl> <p class="description">貴方も今日から這い寄る混沌。</p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2015-02-20">2015/02/20</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div> </section>
Prohibiting RC4 (追記あり)
tag:Baldanders.info,2015-02-20:/blog/000810/
2015-02-20T09:00:00+00:00
2015-02-20T09:00:00+00:00
ついに TLS では RC4 使用禁止になりました。 (追記あり)
Spiegel
/profile/
<p> ついに TLS(RFC <a href="https://tools.ietf.org/html/rfc2246">2246</a>, <a href="https://tools.ietf.org/html/rfc4346">4346</a>, <a href="https://tools.ietf.org/html/rfc5246">5246</a>) では RC4 使用禁止になりました。 </p><ul> <li><a href="https://tools.ietf.org/html/rfc7465">RFC 7465 - Prohibiting RC4 Cipher Suites</a></li> </ul><p> 具体的には </p><ul> <li>TLS clients <strong>MUST NOT</strong> include RC4 cipher suites in the ClientHello message.</li> <li>TLS servers <strong>MUST NOT</strong> select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message.</li> <li>If the TLS client only offers RC4 cipher suites, the TLS server <strong>MUST</strong> terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.</li> </ul><p> とのこと。 また,対象となる暗号スイートは以下のとおり。 </p><ul> <li><code>TLS_RSA_EXPORT_WITH_RC4_40_MD5</code></li> <li><code>TLS_RSA_WITH_RC4_128_MD5</code></li> <li><code>TLS_RSA_WITH_RC4_128_SHA</code></li> <li><code>TLS_DH_anon_EXPORT_WITH_RC4_40_MD5</code></li> <li><code>TLS_DH_anon_WITH_RC4_128_MD5</code></li> <li><code>TLS_KRB5_WITH_RC4_128_SHA</code></li> <li><code>TLS_KRB5_WITH_RC4_128_MD5</code></li> <li><code>TLS_KRB5_EXPORT_WITH_RC4_40_SHA</code></li> <li><code>TLS_KRB5_EXPORT_WITH_RC4_40_MD5</code></li> <li><code>TLS_PSK_WITH_RC4_128_SHA</code></li> <li><code>TLS_DHE_PSK_WITH_RC4_128_SHA</code></li> <li><code>TLS_RSA_PSK_WITH_RC4_128_SHA</code></li> <li><code>TLS_ECDH_ECDSA_WITH_RC4_128_SHA</code></li> <li><code>TLS_ECDHE_ECDSA_WITH_RC4_128_SHA</code></li> <li><code>TLS_ECDH_RSA_WITH_RC4_128_SHA</code></li> <li><code>TLS_ECDHE_RSA_WITH_RC4_128_SHA</code></li> <li><code>TLS_ECDH_anon_WITH_RC4_128_SHA</code></li> <li><code>TLS_ECDHE_PSK_WITH_RC4_128_SHA</code></li> </ul><p> 「<a href="https://baldanders.info/blog/000626/">RC4 終了のお知らせ</a>」を書いたのが2年近く前だが,ようやくここまで来たかぁ,という感じ。 </p><p> <strong>2月21日追記:</strong> </p><p> RC4 を禁止する話, Web 周りでは実質的に実装を終えていて,それほどのインパクトはないと思ってたんだけど,それ以外(VPN 周り?)ではインパクトありそうな感じ。 私の周辺だと電子メール配信の MTA-MTA 間通信では RC4 が使われている場合があるとか。 この辺は面倒くさそうだな。 </p><p> ちなみに日本の CRYPTREC report 2013 では TLS 1.2 へのアップデートと,修正された CBC モードまたは CCM, GCM モードを使うよう勧めている。 </p><ul> <li><a href="https://baldanders.info/blog/000740/">CRYPTREC Report 2013 — Baldanders.info</a></li> </ul> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51njmeGhpKL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/">新版暗号技術入門 秘密の国のアリス</a></dt><dd>結城 浩 </dd><dd>SBクリエイティブ株式会社 2013-12-04</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H40/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00H372H40.09._SCTHUMBZZZ_.jpg" alt="プログラマの数学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMJ0/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMJ0.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/整数で遊ぼう"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00IP549AE/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00IP549AE.09._SCTHUMBZZZ_.jpg" alt="インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMIQ/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMIQ.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/式とグラフ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMK4/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMK4.09._SCTHUMBZZZ_.jpg" alt="数学ガール/ガロア理論"/></a> </p> <p class="description">まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。</p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-09-18">2014/09/18</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div>
VPN に関する基礎学習
tag:Baldanders.info,2014-11-20:/blog/000773/
2014-11-20T09:00:00+00:00
2014-11-20T09:00:00+00:00
前回の続き。もう少しだけまじめに。
Spiegel
/profile/
<p> <a href="https://baldanders.info/blog/000771/">前回</a>の続き。 もう少しだけまじめに。 </p> <section> <h3>VPN に関する基礎学習</h3> <p> 私の知識は SoftEther あるいは SSL-VPN あたりで完全に止まってるので,まずは基本的なおさらい。 </p><p> VPN(Virtual Private Network)は物理的な回線・ネットワークの上に構築された仮想的(virtual を仮想的と訳すのは本来は間違いらしいのだが面倒なのでこのまま)なネットワークである。 なので,たとえば ssh や https を使った仮想ネットワークも VPN である。 ここでは VPN の機能として </p><ol> <li>カプセル化とトンネリング</li> <li>経路の暗号化</li> <li>認証とアクセス制御</li> </ol><p> を挙げ,これらの要件を満たしたものを VPN と呼ぶことにする。 </p><p> VPN は目的によって大きく2つに分かれる。 ひとつは「拠点間 VPN」でもうひとつは「リモートアクセス」だ。 「拠点間 VPN」は昔でいうところの「専用線」の代わりになるものだ。 「リモートアクセス」は企業イントラネットやプライベート・ネットワーク内部に外からアクセスするもので,これは近年の BYOD(Bring Your Own Device)への需要の高まりによって企業による実装が進んでいる。 </p><p> そして最近,3つ目の目的による VPN が台頭してきた。 つまり公衆無線 LAN やホテル・サービス用の LAN など,内部構成が公開されておらず「安全でない」ネットワークをバイパスするための VPN である。 これを仮に「バイパス型 VPN」と呼ぶことにする。 </p><p> 「バイパス型 VPN」と「リモートアクセス」はよく似ているが,「バイパス型 VPN」の出口ノードはイントラネットではなくインターネットになっているのが特徴である。 また「バイパス型 VPN」は「拠点間 VPN」と組み合わせ,国をもまたいで任意の出口ノードを作ることができる。 最近のネットワーク・サービスでは IP アドレスによってリージョンを設定しているものも多いが,「バイパス型 VPN」ではほぼ無意味になる。 また,このことによって IP アドレスベースの行動追跡を困難にする。 </p> </section> <section> <h3>「バイパス型 VPN」のセキュリティ・リスク</h3> <p> 言うまでもないことだが,「バイパス型 VPN」ではアクセスする VPN サーバ(およびその運営[社|者])が信頼できることが絶対条件である。 </p><p> 最近, Tor の出口に malware が仕掛けられているという報告があった。 </p> <figure> <blockquote> <q>悪意のあるTorの出口ノード経由でユーザが実行ファイルをダウンロードしようとすると、実際に受け取るものは実行ファイルの「ラッパー」である。これにはオリジナルの実行ファイルと、もう1つの悪意ある実行ファイルの双方が埋め込まれている。分離したラッパーを用いることで、悪意のある人間がオリジナルのバイナリに含まれ得る完全性チェックを迂回し得る。実行すると、ラッパーはオリジナルの実行ファイルのディスクへの書き込みを開始し、これを実行する。そうしてユーザにすべてがうまくいっているように思い込ませる。しかし、ラッパーはもうひとつの実行ファイルもディスクに書き込んで実行する</q> </blockquote> <figcaption><q><a href="http://blog.f-secure.jp/archives/50738408.html">エフセキュアブログ : OnionDuke:Torネットワーク経由のAPT攻撃</a></q>より</figcaption> </figure> <p> あぁ,この部分を見て「それ見たことか,だから Tor は...」とか言い出す人がいそうなので,続きも引用しておく。 </p> <figure> <blockquote> <q>Torの問題は、使用している出口ノードを誰が保守しているのか、何が彼らの動機なのかがまったく分からない点だ。VPN(Freedome VPNのような)はTorネットワーク上を経由する際にあなたの接続を暗号化するため、Torの出口ノードの保守を行っている人も、あなたのトラフィックを見たり改ざんしたりできない</q> </blockquote> <figcaption><q><a href="http://blog.f-secure.jp/archives/50738408.html">エフセキュアブログ : OnionDuke:Torネットワーク経由のAPT攻撃</a></q>より</figcaption> </figure> <p class="offrec"> (Tor の特徴は経路の暗号化の多層化により通信経路を隠蔽(匿名化)するものだ。 なので End to End では別途暗号化を行う必要がある) </p><p> Tor のような例は極端かと思われるかもしれないが,実際に VPN 製品を見てみるとプロトコルや使用する暗号 suite について明示してないものが多い。 例えばプロトコルは SSL/TLS を使ってると思われるが鍵交換に(DH や ECDH ではなく) RSA を使っているものがあったりする(RSA では PFS(Perfect Forward Secrecy)を達成できない)。 あるいはデータの暗号化にいまだに RC4 や TDES を使ってるものもあるみたいで「なんだかなぁ」という感じである。 </p><p class="offrec"> (最近では SSL 3.0 の仕様上の脆弱性が発覚したけど SSL を使ってる VPN 製品はちゃんと対応してるのかな,とか思うわけですよ。 TLS だってもう 1.2 より前のものはもうダメだよ。 分かってる?) </p><p> セキュリティにおける「信頼」は,「あなたは人として信頼できる」とかいった情緒的な意味での信頼ではなく,ユーザに対して透過的で合理的な運用をしているかどうかが問われる。 その上で第3者の審査を受け瑕疵や脆弱性を修正していくプロセスを通して信頼を積み重ねていくのだ。 </p> </section> <section> <h3>OpenVPN とオレオレ CA</h3> <p> VPN サービスのベンダが信頼できないのなら自分で VPN を構築する手もある。 実際ググってみると,クラウド型サーバと <a href="https://openvpn.net/">OpenVPN</a> を組み合わせてる例をよく見かける。 OpenVPN では経路の暗号化に OpenSSL を使っているようなのだが,驚いたのは「オレオレ証明書」で運用している人の多いこと。 「オレオレ証明書」って絶滅したのかと思ってたけど,まだ現役でのさばってるんだねぇ。 </p><p> はっきり言って自己署名しかない証明書はなりすましを防げない(だからルート証明書の管理って凄く大変なのよ)。 しかも(SSL/TLS が採用している) X.509 型の PKI は権威的 CA による認証がないと全く意味を成さない。 そう,「オレオレ証明書」だけならまだしも(いやダメだけど),「オレオレ証明書」を発行するための「オレオレ・ルート CA」を OpenVPN サーバ上に置いてるのよ。 いやいやいや。 みんな CA(Certification Authority)が何をするのか知らないのか? </p><p> 確かに昔は X.509 型 PKI の証明書を CA に認証してもらうのはコストが高かった(XMPP サーバもオレオレ証明書が多かったし)。 でも今は格安ないし無料で証明書を管理してくれる CA もあるのだ。 </p><ul> <li><a href="http://www.startssl.com/">StartSSL™ Certificates & Public Key Infrastructure - StartSSL™ Home</a></li> </ul><p> しかも今日,凄い発表があった。 </p><ul> <li><a href="https://letsencrypt.org//2014/11/18/announcing-lets-encrypt.html">Let’s Encrypt: Delivering SSL/TLS Everywhere</a></li> <li><a href="https://www.schneier.com/blog/archives/2014/11/a_new_free_ca.html">Schneier on Security: A New Free CA</a></li> <li><a href="http://jp.techcrunch.com/2014/11/19/20141118mozilla-eff-and-others-band-together-to-provide-free-ssl-certificates/">やっと、ついに、誰もが無料でHTTPSを使えるようになる!…MozillaやEFFが共同プロジェクトを立ち上げ - TechCrunch</a></li> <li><a href="http://news.mynavi.jp/news/2014/11/19/082/">SSL/TLSを無料・簡単に、Web全体の暗号化を目指す「Let's Encrypt」発表 | マイナビニュース</a></li> </ul><p> ブラボー! </p><p> 実際のサービスインは2015年夏頃らしいが,本当に素晴らしい。 もしできたら,このサイトも https にしたいものである。 </p><p> というわけで「オレオレ・ルート CA」などもっての外なので今すぐ止めましょう。 </p><p class="offrec"> (本当は GnuTLS が OpenPGP をサポートしてくれたらよかったんだけどねぇ。 あの話,随分前に立ち消えになっちゃったみたいだし。 まぁ OpenPGP の実装である GnuPG が X.509 との共存を目指した時点でしょうがないのかもしれないけど) </p> </section> <section> <h3>とりあえず Freedome と Hotspot Shield を試してみた</h3> <p> いずれも Android 用と iOS 用がある。 ベンダにアカウントを作る必要はなく,すぐ使うことができる。 Freedome は基本有料だが,現在出ているβ版は試用期間が長めに設定されているようだ。 Hotspot Shield は無料版と有料版がある。 有料と言っても月額500円程度(年額なら3,000円くらい?)。 </p><p> 無料版でしか試してないが, VPN 出口ノードは海外のみで日本はない。 Hotspot Shield の出口ノードは米国のみ。 <a href="http://community.f-secure.com/t5/F-Secure/What-are-the-virtual-locations/ta-p/38445">Freedome は複数の国に出口ノードがある</a>。 いきなり海外に飛ばされるのはなぁ。 </p><p> VPN 以外のセキュリティ機能は Freedome のほうが充実している。 </p> </section> <section> <h3>参考にしたページ</h3> <ul> <li><a href="http://fenics.fujitsu.com/products/ipcom/catalog/data/2/1.html">SSL-VPN入門 : 富士通</a></li> <li><a href="http://www.atmarkit.co.jp/ait/articles/0309/13/news001.html">SSL-VPNの導入メリット(前編):リモートアクセスVPNにSSL-VPNを採用する最適なケースは? - @IT</a></li> <li><a href="http://www.atmarkit.co.jp/ait/articles/0310/18/news001.html">SSL-VPNの導入メリット(後編):“SSL-VPN or IPSecVPN”どちらが最適ですか? - @IT</a></li> <li><a href="http://www.net.c.dendai.ac.jp/~baltan/">VPNプロトコルの方式と評価</a></li> <li><a href="https://ja.softether.org/">SoftEther VPN プロジェクト - SoftEther VPN プロジェクト</a></li> <li><a href="http://www.openvpn.jp/">OpenVPN.JP | OpenVPN日本語情報サイト</a></li> <li><a href="https://www.f-secure.com/ja_JP/web/home_jp/freedome">Freedome</a></li> <li><a href="http://hotspotshield.biz/">Hotspot Shield | VPNで個人情報やコンテンツを保護!Wi-Fiネットワークへの接続を安全に</a></li> </ul> </section>
ISP が私たちのデータを守ってくれるなどと期待しない方がいい
tag:Baldanders.info,2014-11-16:/blog/000772/
2014-11-16T09:00:00+00:00
2014-11-16T09:00:00+00:00
メール配信の「経路の暗号化」が解除されている,というお話。まぁ,正直に言って今更な話である。私たちはそこまで ISP を信頼していない。
Spiegel
/profile/
<ul> <li><a href="https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks">ISPs Removing Their Customers' Email Encryption | Electronic Frontier Foundation</a></li> <li><a href="http://gigazine.net/news/20141114-isp-remove-encryption/">インターネットサービスプロバイダはメールの暗号化を勝手に解除していることが判明 - GIGAZINE</a></li> </ul><p> 厳密にはメール配信の「経路の暗号化」が解除されている,というお話。 </p><p> <a href="https://baldanders.info/blog/000319/">2007年に APOP の仕様上の脆弱性が発覚</a>して以来,メールサーバとの認証の際に SS/TLS を通すことが一般的になってきた。 STARTTLS はそういった経路の暗号化のひとつで, MUA(Mail User Agent)とメールサーバの間だけでなくサーバ間の経路もこれで暗号化できる。 今回の EFF の報告は STARTTLS による暗号化が ISP(Internet Servive Provider)によってぶった切られているというものだ。(あくまで一部の ISP だけどね) </p><p> まぁ,正直に言って今更な話である。 私たちはそこまで ISP を信頼していない。 例えば ISP は spam メールをフィルタリングしてくれると言うが,そのためにはメールの内容を「盗聴」しなければならないということを分かってないユーザが存外多い。 Gmail なんてメールの中身を見てユーザに関連広告を配信している。 彼らは利益のためには他人のプライバシーを覗き見ることだって平気でやるのだ(もちろん利益を出すことは営利企業の最大の正義だ)。 そしてそれに警察当局が便乗する。 これが商業主義にまみれた「インターネット」の実体である。 </p><p> そもそも電子メールは安全なメッセージング・システムではない。 「ハガキ」なみに誰にでも丸見えのメッセージを安全でない経路で配信するのだから当たり前である。 だからこそ OpenPGP などの暗号化ツールで「封書」にすることが必要になってくるのである。 </p><p> 電子メールに関して,経路の暗号化解除より深刻なのは,サーバ上に置いてあるメールデータが一切暗号化されていないということだ。 </p><p> 昔のようにパソコンで POP3 でメールをダウンロードしていた頃はそんなこと考えなくてもよかった。 サーバに残ってるメールデータは削除すればよかった(そもそもサーバ上のメールボックスの容量が10MBからせいぜい100MBとかそんな時代である)。 でも今はスマホなどの携帯端末を複数持ってお互いに情報を同期させる必要がある。 そのためにはメールデータもサーバ上に保持しておく必要がある。 そしてサーバ上に保持されているメールデータは(少なくともユーザ以外に復号できないようには)暗号化されてなく,陰に陽にサービスプロバイダに利用され放題な状況になっている。 </p><p> 何が言いたいかというと,メールデータを機密にしたいなら「経路の暗号化」ではダメで「データの暗号化」を行わなければならないということ。 そのためには S/MIME や PGP/MIME といった暗号化手法が必須だということだ。 そしてこれは声を大にして言いたいが </p><p class="center"> <strong class="caution">もはや時代遅れの Web ベースのメールクライアントなんか捨てろ!</strong> </p><p> Google も End-to-End みたいな中途半端なツールの開発をするなら Gmail アプリや Inbox アプリを <a href="http://www.openkeychain.org/">OpenKeychain</a> に対応させるくらいの芸を見せてみろよ。 </p> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4757143044/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/413qoSjODUL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4757143044/baldandersinf-22/">信頼と裏切りの社会</a></dt><dd>ブルース・シュナイアー 山形 浩生 </dd><dd>エヌティティ出版 2013-12-24</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4622078007/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4622078007.09._SCTHUMBZZZ_.jpg" alt="殺人ザルはいかにして経済に目覚めたか?―― ヒトの進化からみた経済学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4622078767/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4622078767.09._SCTHUMBZZZ_.jpg" alt="21世紀の資本"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4152094184/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4152094184.09._SCTHUMBZZZ_.jpg" alt="自己が心にやってくる"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4326503912/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4326503912.09._SCTHUMBZZZ_.jpg" alt="不確実性下の意思決定理論"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4757142366/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4757142366.09._SCTHUMBZZZ_.jpg" alt="ルールに従う―社会科学の規範理論序説 (叢書《制度を考える》)"/></a> </p> <p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-11-16">2014/11/16</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p> </div>
CRYPTREC Report 2013
tag:Baldanders.info,2014-09-18:/blog/000740/
2014-09-18T09:00:00+00:00
2014-09-18T09:00:00+00:00
8月に CRYPTREC Report 2013 が出てたのに気付かず。ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。
Spiegel
/profile/
<p> 8月に CRYPTREC Report 2013 が出てたのに気付かず。 </p><ul> <li><a href="http://www.cryptrec.go.jp/topics/cryptrec_20140811_c13report.html">CRYPTREC Report 2013の公開</a> <ul> <li><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_prom_web_final.pdf">CRYPTREC Report 2013 暗号技術活用委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_tech_guideline_TLSSSL_web.pdf">CRYPTREC 暗号技術ガイドライン (SSL/TLS における近年の攻撃への対応)<sup><i class="far fa-file-pdf"></i></sup></a></li> <li><a href="http://www.cryptrec.go.jp/report/c13_tech_guideline_SHA-1_web.pdf">CRYPTREC 暗号技術ガイドライン (SHA-1)<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul></li> </ul><p> あと CRYPTREC Report じゃないけど,昨年大騒ぎになった </p><ul> <li><a href="http://www.cryptrec.go.jp/topics/cryptrec_20131106_dual_ec_drbg.html">擬似乱数生成アルゴリズム Dual_EC_DRBG について</a></li> </ul><p> も併せてどうぞ。 </p><p> セキュリティ管理に関わっている人は最低でも「暗号技術評価委員会報告書」は読んでおくとよい。 ちなみに SSL/TLS と SHA-1 の暗号技術ガイドラインは「暗号技術評価委員会報告書」にも含まれている。 </p><p> ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。 </p> <ol> <li><a href="#pubkey">公開鍵暗号に関する安全性評価</a></li> <li><a href="#sha3">ハッシュ関数について</a></li> <li><a href="#dsa">FIPS PUB 186-4</a></li> <li><a href="#tls12">SP800-52 revision 1 と TLS 1.2</a></li> <li><a href="#pfs">perfect forward secrecy と forward secrecy</a></li> <li><a href="#key-exch">SSL/TLS における DHE, DH, RSA の安全性評価</a></li> <li><a href="#rnd">擬似乱数生成アルゴリズム Dual_EC_DRBG</a></li> <li><a href="#light-cipher">軽量暗号</a></li> </ol> <section id="pubkey"> <h3>公開鍵暗号に関する安全性評価</h3> <figure> <blockquote> <q>昨年の Crypto 2012 で A.K. Lenstra らは、実社会に公開されている RSA 公開鍵証明書(X.509)に、異なる署名に同じ modulus が使われていたり、modulus が素因数分解できたりといった問題を指摘した。これに続き、 Asiacrypt 2013 において N. Heninger らは、台湾市民向けのスマートカードで利用される公開鍵証明書約300万件について、同じ問題点があることと、Coppersmith 攻撃によって新たな素因数分解が可能となったことを示した。 <br/>楕円曲線暗号に関しては、Asiacrypt 013 のランプセッションにおいて J.W. Bos らが、実際に暗号通信(TLS/SSH)で利用されている証明書を調べ、TLS 公開鍵の 4%(20 万個)、SSH公開鍵の 30%(40 万個)に同じものが使用されている問題点を確認した。また、Bitcoin において、同じ nonce の存在が利用されており、59 BTC が盗難されたとしている。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> ということで,実装上の脆弱性が浮き彫りになった。 スマートカードのようにハードウェアに組み込むタイプのものは,いったん脆弱性や危殆化が発覚すると対処が難しい。 なので,やはり「事後」の対処がとても重要になってくる。(下手に隠蔽したり判断をミスったりすれば被害を拡大させてしまう) </p><p> ちなみに<a href="http://www.converterhub.com/index.php?sum=59&from=BTC&to=JPY">59BTCは290万円くらい</a>らしい。 </p> </section> <section id="sha3"> <h3>ハッシュ関数について</h3> <p> <a href="https://baldanders.info/blog/000702/">以前も述べた</a>が FIPS PUB 202 (SHA-3 Standard) のドラフトが登場している(パブリックコメントは既に終了している)。 </p><ul> <li><a href="http://csrc.nist.gov/publications/drafts/fips-202/fips_202_draft.pdf">DRAFT FIPS PUB 202: SHA-3 Standard<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul><p> 正式リリースは来年以降かな? </p> </section> <section id="dsa"> <h3>FIPS PUB 186-4</h3> <p> FIPS PUB 186-4 が登場している。 </p><ul> <li><a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">FIPS PUB 186-4: Digital Signature Standard (DSS)<sup><i class="far fa-file-pdf"></i></sup></a></li> </ul> <figure> <blockquote> <q>補助関数(ハッシュ関数、KDF、及び、擬似乱数生先の変更を認 成系、素数生成や楕円曲線生成等の基本的なアルゴリズム)を除いた、当該アルゴリズムを実装するための必要最小限の範囲において、パラメータ修正等の簡易な修正である。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> とのこと。 </p> </section> <section id="tls12"> <h3>SP800-52 revision 1 と TLS 1.2</h3> <p> 近年の SSL/TLS への攻撃(BEAST, CRIME, TIME. BREACH, Lucky Thirteen, Renegotiation)や <a href="https://baldanders.info/blog/000626/">RC4 の危殆化</a>を鑑み, TLS 1.2 へのアップデートが推奨されている。 </p> <figure> <blockquote> <q>推奨される設定として、TLS 1.0 より古いバージョンについては、新しいバージョンへアップデートすることが推奨される。TLS 1.0 については、CBC モードを用いた場合の脆弱性に対してパッチが提供されているため、Java 等のソフトウェアを最新版に更新した上で、CBC モードを選択することが推奨される。TLS 1.1 については、CBC モードを用いた場合の脆弱性が解消されていることから、CBC モードを選択することが推奨される。 TLS1.2 については、CBC モード、CCM モード、GCM モードが選択できるため、それらを使うことが推奨される。</q> </blockquote> <figcaption><q><a href="http://www.cryptrec.go.jp/report/c13_eval_web_final.pdf">CRYPTREC Report 2013 暗号技術評価委員会報告書<sup><i class="far fa-file-pdf"></i></sup></a></q>より</figcaption> </figure> <p> NIST では SP800-52 revision 1 を発行し TLS 1.2 への対応を行うことを進めている。 </p><ul> <li><a href="http://www.nist.gov/itl/csd/tls-043014.cfm">NIST Revises Guide to Use of Transport Layer Security (TLS) in Networks</a></li> <li><a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">Publication Citation: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations</a></li> <li><a href="http://threatpost.com/federal-agencies-told-to-support-tls-1-2-by-2015/105906">NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015 | Threatpost | The first stop for security news</a></li> </ul> <figure> <blockquote> <q lang="en">“Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2,” the document says. “These servers shall not support TLS 1.0, SSL 2.0, or SSL 3.0.”</q> </blockquote> <figcaption>via <q lang="en"><a href="http://threatpost.com/federal-agencies-told-to-support-tls-1-2-by-2015/105906">NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015</a></q></figcaption> </figure> <section> <h4>ところでクライアント側はどうなっているだろう</h4> <p> 主要ブラウザは TLS 1.2 のサポートを完了しているようだ。 </p><ul> <li>Google Chrome は 30 から全プラットフォームで正式対応</li> <li>Mozilla Firefox は 27 から全プラットフォームで正式対応</li> <li>Internet Explorer は 11 から既定で有効になっている(Windows Vista および 2008(無印)は非対応)</li> <li>Safari は 7 以降は全プラットフォームで対応</li> <li>その他 <ul> <li><a href="http://www.atmarkit.co.jp/ait/articles/1401/31/news141.html">JDK 8、TLS 1.2がデフォルトに - @IT</a></li> </ul></li> </ul><p> いやぁ, WinXP(および IE6)がなくなってホンマによかったよ。 (<span class="offrec">でもうちのサイトに来るブラウザの UA 見てると IE6 っぽいのがいまだにワンサカ来るんだけど。 IE6 & WinXP ってどのくらい残ってるのかねぇ。ちなみにうちのサイトはもう IE8 以前は見捨ててますので。 IE9 もダメかな,多分。 Safari は確認する手段を持ってないので知らない振りをする</span>) </p><p> ちなみに Firefox で Google のサイトを見ると </p> <pre class="brush:text" title="google.com 接続情報">TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</pre>
<p>
と表示される。
つまり TLS 1.2 下で Perfect Forward Secrecy を満たす ECDHE 鍵交換方式を使い AES 128bit アルゴリズムで GCM モードにより暗号化している(HMAC には SHA256 を使用),ということになる。
</p><p>
あとは古い AOSP(Android Open Source Project)版ブラウザだよね。
AOSP 版ブラウザはもともと WebKit から fork したものだが, Google 自身は2012年以降サポートを打ち切っている(Chromium があるからね)。
ユーザ側としては Chrome 等を導入して AOSP 版ブラウザを使わないようにするしかない。
他にも AOSP 版ブラウザには「同一生成元ポリシー回避の脆弱性」が指摘されている。
</p><ul>
<li><a href="https://community.rapid7.com/community/metasploit/blog/2014/09/15/major-android-bug-is-a-privacy-disaster-cve-2014-6041">Metasploit: Major Android Bug is a Privacy Disa... | SecurityStreet</a></li>
<li><a href="http://www.itmedia.co.jp/enterprise/articles/1409/16/news044.html">AndroidのAOSPブラウザに脆弱性、情報盗聴の恐れ - ITmedia エンタープライズ</a></li>
</ul>
</section>
</section>
<section id="pfs">
<h3>perfect forward secrecy と forward secrecy</h3>
<p>
どうもドキュメントによって表記に揺れがあるらしい。
</p><p>
<a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">SP800-52 revision 1</a> では
</p>
<figure>
<blockquote>
<q lang="en">Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the second mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. While support of these cipher suites is not required by these guidelines, it is strongly recommended.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://dx.doi.org/10.6028/NIST.SP.800-52r1">Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations<sup><i class="far fa-file-pdf"></i></sup></a></q></figcaption>
</figure>
<p>
とあり, <q lang="en">perfect forward secrecy</q> の表記になっている。
一方 RFC3268 では
</p>
<figure>
<blockquote>
<q lang="en">At the same time the DHE ciphersuites are the only ones to offer forward secrecy.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://tools.ietf.org/html/rfc3268">RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)</a></q></figcaption>
</figure>
<p>
とあり,こちらは <q lang="en">forward secrecy</q> の表記になっている。
</p><p>
さらに RFC4949 では
</p>
<figure>
<blockquote>
<q lang="en">Ordinary forward secrecy vs. "perfect" forward secret: Experts disagree about the difference between these two. Some say there is no difference, and some say that the initial naming was unfortunate and suggest dropping the word "perfect". Some suggest using "forward secrecy" for the case where one long-term private key is compromised, and adding "perfect" for when both private keys (or, when the protocol is multi-party, all private keys) are compromised.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://tools.ietf.org/html/rfc4949">RFC4949: Internet Security Glossary, Version 2</a></q></figcaption>
</figure>
<p>
と書かれていて,両者の違いに一致した見解はないそうだ。
ちなみに <a href="http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295">SP800-52 revision 1</a> では <q lang="en">perfect forward secrecy</q> について
</p>
<figure>
<blockquote>
<q lang="en">Perfect forward secrecy is the condition in which the compromise of a long-term private key used in deriving a session key subsequent to the derivation does not cause the compromise of the session key.</q>
</blockquote>
<figcaption>via <q lang="en"><a href="http://dx.doi.org/10.6028/NIST.SP.800-52r1">Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations<sup><i class="far fa-file-pdf"></i></sup></a></q></figcaption>
</figure>
<p>
と定義している。
大雑把に言えば「長期的に使われる秘密鍵が漏洩しても、漏洩前のセッションで交換された鍵の秘密が漏れない」という解釈でいいようだ。
</p>
</section>
<section id="key-exch">
<h3>SSL/TLS における DHE, DH, RSA の安全性評価</h3>
<p>
TLS で使われる鍵交換方式である DH(Diffie-Hellman), DHE(ephemeral DH), RSA(RSAES-PKCS1-v1_5)を比較すると
</p><p>
DHE > DH > RSA
</p><p>
となるらしい。
これは
</p><ul>
<li><strong>DHE</strong>: 安全な認証機能付き鍵交換であり,かつ Perfect Forward Secrecy を満たす</li>
<li><strong>DH</strong>: 安全な認証機能付き鍵交換である</li>
<li><strong>RSA</strong>: 安全な認証機能付き鍵交換ではない(ただし RSA-OAEP を使う場合は安全な認証機能付き鍵交換である)</li>
</ul><p>
ということらしい。
ちなみに CRYPTREC では RSAES-PKCS1-v1_5 は「運用監視暗号」としてリストされ,「利用実績があることから当面の利用を認める」という条件で利用可能である。
</p><p>
参考:
</p><ul>
<li><a href="http://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf">政府機関の情報システムにおいて使用されている暗号アルゴリズム SHA-1 及び RSA1024 に係る移行指針<sup><i class="far fa-file-pdf"></i></sup></a></li>
</ul><p class="offrec">
(CRYPTREC の「電子政府推奨暗号リスト」では,「鍵共有」用途としては DH および ECDH(Elliptic Curve Diffie–Hellman)しかリストアップされていない(推奨候補にも挙がってない)。
CRYPTREC において DHE や ECDHE(ephemeral ECDH)がどのような位置づけになるか,今後の動向が注目される)
</p>
</section>
<section id="rnd">
<h3>擬似乱数生成アルゴリズム Dual_EC_DRBG</h3>
<p>
Dual_EC_DRBG については<q><a href="http://www.cryptrec.go.jp/topics/cryptrec_20131106_dual_ec_drbg.html">擬似乱数生成アルゴリズム Dual_EC_DRBG について</a></q>を参照していただきたいが,最新動向として SP800-90 A Rev. 1 (2nd Draft) が登場している。
</p><ul>
<li><a href="http://csrc.nist.gov/publications/drafts/800-90/sp800_90a_r1_draft.pdf">DRAFT NIST Special Publication 800-90A, Rev. 1<sup><i class="far fa-file-pdf"></i></sup></a></li>
</ul><p>
このドラフトのパブリックコメントは2014年5月に締め切られている。
</p><p>
もともとこの脆弱性は2013年に Dual_EC_DRBG に NSA によるバックドアが仕込まれているという指摘からはじまったものだ。
NIST はこの脆弱性の修正に懸命になっているが,あまり芳しくないようである。
</p>
</section>
<section id="light-cipher">
<h3>軽量暗号</h3>
<p>
軽量暗号についてはまだまだこれからのようだが,いわゆる IoT(Internet of Things)を考える際には外せない要素技術であるといえる。
</p><p>
軽量暗号の特徴は以下のとおり。
</p><ul>
<li>ハードウェア規模が小さい,低消費電力で動作,消費電力が少ない,低コスト</li>
<li>コードサイズが小さい,RAM が少ない</li>
<li>低レイテンシ性,リアルタイム性</li>
</ul><p>
そして「軽量暗号の活用が期待されるアプリケーション」としては
</p><ul>
<li>RFID タグ,センサー,ワイヤレスセンサー</li>
<li>IC カード</li>
<li>医療機器(体内埋め込みや携帯型など),ヘルスケア製品</li>
<li>スマートメータ</li>
<li>モバイル製品</li>
<li>バッテリ</li>
<li>車, ITS システム</li>
</ul><p>
が挙がっている。
バッテリーかぁ。
</p><p>
車への応用は急務だろうね。
いまどきの車は ECU だらけだけどセキュリティに関してはこれからって感じだもんなぁ。
</p>
</section>
<section>
<h3>参考図書</h3>
<div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51njmeGhpKL._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H18/baldandersinf-22/">新版暗号技術入門 秘密の国のアリス</a></dt><dd>結城 浩 </dd><dd>SBクリエイティブ株式会社 2013-12-04</dd><dd>評価<abbr class="rating" title="4"><img src="https://images-fe.ssl-images-amazon.com/images/G/01/detail/stars-4-0.gif" alt=""/></abbr> </dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00H372H40/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00H372H40.09._SCTHUMBZZZ_.jpg" alt="プログラマの数学"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMJ0/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMJ0.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/整数で遊ぼう"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00IP549AE/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00IP549AE.09._SCTHUMBZZZ_.jpg" alt="インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMIQ/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMIQ.09._SCTHUMBZZZ_.jpg" alt="数学ガールの秘密ノート/式とグラフ"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/B00L0PDMK4/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/B00L0PDMK4.09._SCTHUMBZZZ_.jpg" alt="数学ガール/ガロア理論"/></a> </p>
<p class="description">まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。</p>
<p class="gtools">reviewed by <a href="#me" class="reviewer">Spiegel</a> on <abbr class="dtreviewed" title="2014-09-18">2014/09/18</abbr> (powered by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a>)</p>
</div>
</section>
パスワード変更は計画的に
tag:Baldanders.info,2014-04-11:/blog/000682/
2014-04-11T09:00:00+00:00
2014-04-11T09:00:00+00:00
やっちゃいましたねぇ, Heartbleed on OpenSSL。大惨事ですよ。パスワード変更は計画的に
Spiegel
/profile/
<p> やっちゃいましたねぇ。 大惨事ですよ。 </p><ul> <li><a href="http://heartbleed.com/">Heartbleed Bug</a></li> <li><a href="https://www.openssl.org/news/secadv_20140407.txt">OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160)</a></li> <li><a href="http://www.ipa.go.jp/security/ciadr/vul/20140408-openssl.html">OpenSSL の脆弱性対策について(CVE-2014-0160) :IPA 独立行政法人 情報処理推進機構</a></li> <li><a href="http://jp.techcrunch.com/2014/04/08/20140407massive-security-bug-in-openssl-could-effect-a-huge-chunk-of-the-internet/">OpenSSLの重大バグが発覚。インターネットの大部分に影響の可能性 | TechCrunch Japan</a></li> </ul><p> この脆弱性が問題なのは悪用されても痕跡が残らないことだ。 だからはっきり言って被害がどのくらいの規模になるのかは分からない。 分からないので最悪を想定して動くしかない。 </p><p> 海外では既に被害状況をまとめた記事が登場している。 </p><ul> <li><a href="http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/">The Heartbleed Hit List: The Passwords You Need to Change Right Now</a></li> </ul><p> Heartbleed がどんな問題か理解できなくてもいいので,少なくともこの記事は目を通しておくこと。 そして自身が参加しているサービスでパスワード変更が必要と判断されているものについては必ずパスワードを変更すること。 </p><p> 気になるのは,現時点で Twitter や Apple などが Unclear な状態であること。 そして日本のサービスの状況が全くわからないこと。 どーなってんの? IPA でも JVN でも JPCERT でも NICT でもいいから,ちゃんと旗振りして事態の把握と収拾に努めろよ。 くだらない論文のバッシングで遊んでる暇はねーんだよ! </p><p> 幸いなことに今回のこれは,それほど緊急というわけではなさそうだ。 今のところアカウントを乗っ取られて云々という記事は見当たらない。 そこで,この週末は半日くらい当ててパスワード変更作業を一気に進めてしまうことをお薦めする。 </p><p> (携帯端末のセキュリティ設定やパスワードに関する話は IPA の以下のドキュメントが役に立つ。 </p><ul> <li><a href="https://www.ipa.go.jp/security/ipg/documents/dev_setting_crypt.html">IPA 独立行政法人 情報処理推進機構:情報漏えいを防ぐためのモバイルデバイス等設定マニュアル</a></li> </ul><p> 解説編にはパスワード解読にかかるコストなどが紹介されている。 これによると数字だけの8文字以下のパスワードの解読にかかるコストは1円未満だそうだ。 英字小文字を含めても100円以下。 恐ろしいだろう?) </p><p> ところで,いまだにパスワードを頭の中で管理している人はいませんか? セキュリティ上有効と思えるパスワードを頭の中で憶えておくなんてのは,はっきり言って脳味噌の無駄遣いです。 今すぐ止めましょう。 </p><p> 最近はパスワード管理ツールという便利なものがあります。 是非この手のツールを使って効率的にパスワードを管理することをお薦めします。 個人的には KeePass がお勧めです。 </p><ul> <li><a href="http://keepass.info/">KeePass Password Safe</a></li> <li><a href="https://play.google.com/store/apps/details?id=com.android.keepass">KeePassDroid - Google Play</a></li> <li><a href="https://play.google.com/store/apps/details?id=keepass2android.keepass2android">Keepass2Android Password Safe - Google Play</a></li> </ul><blockquote> “Yes, KeePass is really free, and more than that: it is open source (OSI certified). You can have a look at its full source and check whether the encryption algorithms are implemented correctly.” <br/>(via “<a href="http://keepass.info/">KeePass Password Safe</a>”) </blockquote><p> そして Flattr のアカウントを持っている貴方は是非 <a href="https://flattr.com/thing/291318/KeePass">KeePass に micro-donation</a> を! </p><p> KeePass と KeePassDroid/Keepass2Android は Dropbox 等のクラウドストレージを使うことでデータベースファイルの同期をとることができます。 データベースファイルは暗号化すること(<a href="http://www.gizmodo.jp/2014/04/0403_dropbox_5.html">クラウドストレージにプライバシーはない</a>と思った方がいい)。 もちろん鍵ファイルをクラウドに上げてはいけません。 </p><p> パスワード変更は計画的に。 良い週末を。 </p><p> しかし,今回の問題で OpenSSL に全く関係ない Microsoft が被害なしってのが皮肉というか何というか... </p> <div class="hreview"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4274065731/baldandersinf-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/515K64RSM1L._SL160_.jpg" alt="photo" class="photo"/></a><dl><dt class="fn"><a class="item url" href="https://www.amazon.co.jp/exec/obidos/ASIN/4274065731/baldandersinf-22/">OpenSSL―暗号・PKI・SSL/TLSライブラリの詳細―</a></dt><dd>John Viega Matt Messier Pravir Chandra 齋藤 孝道 </dd><dd>オーム社 2004-08</dd></dl><p class="similar"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4274065421/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4274065421.09._SCTHUMBZZZ_.jpg" alt="マスタリングTCP/IP SSL/TLS編"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4774163856/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4774163856.09._SCTHUMBZZZ_.jpg" alt="iOSアプリエンジニア養成読本[クリエイティブな開発のための技術力/デザイン力/マインドを養う! ] (Software Design plus)"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4797350997/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4797350997.09._SCTHUMBZZZ_.jpg" alt="新版暗号技術入門 秘密の国のアリス"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4627847610/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4627847610.09._SCTHUMBZZZ_.jpg" alt="Javaで作って学ぶ暗号技術 - RSA,AES,SHAの基礎からSSLまで"/></a> <a href="https://www.amazon.co.jp/exec/obidos/ASIN/4797375361/baldandersinf-22/" target="_top"><img src="https://images-fe.ssl-images-amazon.com/images/P/4797375361.09._SCTHUMBZZZ_.jpg" alt="Xcode 5 完全攻略"/></a> </p><p class="gtools">by <a href="http://www.goodpic.com/mt/aws/index.html">G-Tools</a> , <abbr class="dtreviewed" title="2014/04/11">2014/04/11</abbr></p></div>