List of Ssl - text.Baldanders.info
tag:text.Baldanders.info,2017-03-21:/tags
2017-03-21T20:32:28+09:00
帰ってきた「しっぽのさきっちょ」
https://text.baldanders.info/images/avatar.jpg
https://text.baldanders.info/images/avatar.jpg
HTTPS 通信監視機器のリスク
tag:text.Baldanders.info,2017-03-21:/remark/2017/03/security-risk-of-https-interception/
2017-03-21T11:32:28+00:00
2020-01-05T11:59:50+00:00
2015年の CERT/CC ブログ記事「The Risks of SSL Inspection」に関する注意喚起が今更ながら出ている。
Spiegel
https://baldanders.info/profile/
<p>2015年の CERT/CC ブログ記事 “<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” に関する注意喚起が今更ながら出ている。</p>
<ul>
<li><a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>
<ul>
<li><span><a href="https://jhalderm.com/pub/papers/interception-ndss17.pdf">The Security Impact of HTTPS Interception <sup><i class="far fa-file-pdf"></i></sup></a></span></li>
<li><a href="https://www.us-cert.gov/ncas/alerts/TA17-075A">HTTPS Interception Weakens TLS Security | US-CERT</a></li>
<li><a href="http://jvn.jp/ta/JVNTA96603741/">JVNTA#96603741: HTTPS 通信監視機器によるセキュリティ強度低下の問題</a></li>
</ul>
</li>
</ul>
<p>「HTTPS 通信監視機器」というのは,ぶっちゃけていうと, HTTPS 暗号通信<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> に「中間者攻撃(man-in-the-middle attack)」を仕掛けて通信を傍受し malware 等を検出・排除する「セキュリティ製品」である。</p>
<p>HTTPS 通信監視機器のいくつかにはセキュリティ上の問題が存在する。
“<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” から抜き出してみよう。</p>
<ol>
<li>Incomplete validation of upstream certificate validity</li>
<li>Not conveying validation of upstream certificate to the client</li>
<li>Overloading of certificate Canonical Name (CN) field</li>
<li>Use of the application layer to convey certificate validity</li>
<li>Use of a User-Agent HTTP header to determine when to validate a certificate</li>
<li>Communication before warning</li>
<li>Same root CA certificate</li>
</ol>
<p>これらの問題があると推測される製品のリストが “<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” に挙がっているので該当者は確認してみるとよいだろう。
また以下のサイトからも確認できる。</p>
<ul>
<li><a href="https://badssl.com/">badssl.com</a></li>
</ul>
<p>“<a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a>” では以下のように結論付けている。</p>
<figure lang="en">
<blockquote>
<q>SSL and TLS do not provide the level of end-to-end security that users may expect. Even in absence of SSL inspection, there are problems with how well browsers are conveying SSL information to users. The fact that "SSL inspection" is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is fundamentally broken.</q>
</blockquote>
<figcaption><div>via <q><a href="http://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html">The Risks of SSL Inspection</a></q></div></figcaption>
</figure>
<p><a href="https://baldanders.info/blog/000812/" title="HTTPS Deep Inspection — Baldanders.info">以前も書いた</a>が,HTTPS 通信監視機器(あるいは HTTPS Deep Inspection)の存在自体がインターネットの “End to End” 原則を崩すものであり,ひいては「ネットの中立性」に楔を入れるものである。
しかし「<a href="https://text.baldanders.info/remark/2016/03/vulnerability-cross-protocol-attack-on-tls-using-sslv2/" title="SSLv2 を有効にしている TLS 実装の脆弱性 ― 馬も鹿も暗号化する時代のセキュリティ">馬も鹿も暗号化する時代</a>」にこの原則は風前の灯である。
たとえば <a href="https://text.baldanders.info/remark/2016/07/cms/" title="「自分で面倒見られる子」だけが CMS を導入しなさい">CMS の面倒すらろくすっぽ見られない</a>ユーザが「うちも <a href="https://letsencrypt.org/" title="Let's Encrypt - Free SSL/TLS Certificates">Let’s la Encrypt</a>」とか言い出して脆弱性だらけのサイトを暗号化したらどうなるのか。</p>
<p>ネットワーク・セキュリティ専門家から企業あるいは私たち個人に至るまで,場当たりな対処に満足するのではなく,この「現実」にきちんと向き合うべきだと思うのだが,どうだろう。</p>
<h2>【おまけの追記】公開鍵基盤が担保するもの</h2>
<p>他の事象だが同じ公開鍵基盤(Public Key Infrastructure; PKI)に関連している事柄なので,おまけの追記ということで。</p>
<ul>
<li><a href="http://www.computerworld.com/article/3184573/security/to-punish-symantec-google-may-distrust-a-third-of-the-webs-ssl-certificates.html">To punish Symantec, Google may distrust a third of the web’s SSL certificates | Computerworld</a></li>
<li><a href="http://notchained.hatenablog.com/entry/2017/03/27/090554">Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.</a></li>
<li><a href="https://japan.cnet.com/article/35098759/">グーグル、シマンテックが発行したTLS証明書に不信感 - CNET Japan</a></li>
</ul>
<p>「<a href="http://notchained.hatenablog.com/entry/2017/03/27/090554" title="Symantecが再びGoogleの信頼を失った件についてのメモ - Technically, technophobic.">Symantecが再びGoogleの信頼を失った件についてのメモ</a>」にもあるように Symantec (傘下の Thawte)は既に前科持ちなので「またか(sigh)」って感じなのだが…</p>
<p>X.509 型の公開鍵基盤は認証局(Certification Authority; CA)が信頼できることが絶対条件で,これが崩れると機能しなくなる。</p>
<p>喩えるならお金と銀行の関係と似ている。
銀行はお金の価値を担保するが銀行が信用できないのならお金の価値を担保するものがなくなる。
同じく認証局が管理する証明書は認証局が安全性を担保できているからこそ意味がある。
そうでなければオレオレ証明書またはそれ以下の価値しかない。</p>
<p>この問題は Symantec と Google の2者間の喧嘩だと思ったら物事を見誤る。
現在 Web を支配している公開鍵基盤の根幹に関わる問題なのである。</p>
<p>それにしても,昔「<a href="https://baldanders.info/blog/000277/" title="Extended Validation SSL — Baldanders.info">EV SSL は『屋上屋を架す』ようにしか見えない</a>」と書いたが,まったくもってその通りだったな(笑)</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://baldanders.info/blog/000809/">Malware Spoofing HTTPS(3月2日,追記あり) — Baldanders.info</a></li>
<li><a href="https://baldanders.info/blog/000812/">HTTPS Deep Inspection — Baldanders.info</a></li>
<li><a href="https://japan.zdnet.com/article/35098402/">HTTPS監視装置にセキュリティ低下の危険性–日米機関で注意喚起 - ZDNet Japan</a></li>
<li><a href="https://www.schneier.com/blog/archives/2017/03/new_paper_on_en.html">New Paper on Encryption Workarounds - Schneier on Security</a>
<ul>
<li><a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2938033">Encryption Workarounds by Orin S. Kerr, Bruce Schneier :: SSRN</a></li>
</ul>
</li>
</ul>
<h2>参考図書</h2>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>念のため簡単に説明しておくと, HTTPS (Hypertext Transfer Protocol Secure) 暗号通信は WWW (World Wide Web) におけるクライアント-サーバ間の通信経路を暗号化する仕組みである。具体的には TLS (Transport Layer Security) 等のプロトコルを用い公開鍵暗号方式を使ってセッション鍵を生成する。また公開鍵暗号方式の公開鍵は X.509 方式の公開鍵基盤によって管理される。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>
SSLv2 を有効にしている TLS 実装の脆弱性 ― 馬も鹿も暗号化する時代のセキュリティ
tag:text.Baldanders.info,2016-03-03:/remark/2016/03/vulnerability-cross-protocol-attack-on-tls-using-sslv2/
2016-03-02T15:30:52+00:00
2020-01-05T11:59:50+00:00
OpenSSL をはじめとする SSL/TLS 暗号通信の実装に複数のセキュリティ脆弱性あり。
Spiegel
https://baldanders.info/profile/
<h2>脆弱性の内容</h2>
<p>いい加減 SSL 周りの脆弱性にはうんざりなのだが, <a href="https://www.openssl.org/" title="OpenSSL">OpenSSL</a> をはじめとする SSL/TLS 暗号通信の実装に複数のセキュリティ脆弱性あり。</p>
<table>
<thead>
<tr>
<th style="text-align:left">CVE</th>
<th style="text-align:left">脆弱性内容</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left">CVE-2016-0800</td>
<td style="text-align:left">Cross-protocol attack on TLS using SSLv2 (DROWN)</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0705</td>
<td style="text-align:left">Double-free in DSA code</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0798</td>
<td style="text-align:left">Memory leak in SRP database lookups</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0797</td>
<td style="text-align:left">BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0799</td>
<td style="text-align:left">Fix memory issues in BIO_*printf functions</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0702</td>
<td style="text-align:left">Side channel attack on modular exponentiation</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0703</td>
<td style="text-align:left">Divide-and-conquer session key recovery in SSLv2</td>
</tr>
<tr>
<td style="text-align:left">CVE-2016-0704</td>
<td style="text-align:left">Bleichenbacher oracle in SSLv2</td>
</tr>
</tbody>
</table>
<p>このうち特に CVE-2016-0800 のリスクが高いので紹介する。</p>
<h3>CVE-2016-0800 : Cross-protocol attack on TLS using SSLv2 (DROWN)</h3>
<p>通称 <a href="https://drownattack.com/">DROWN (Decrypting RSA with Obsolete and Weakened eNcryption)</a> 攻撃。</p>
<figure lang="en">
<blockquote>
<q>A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800).</q>
</blockquote>
<figcaption><div>via <q><a href="https://www.openssl.org/news/secadv/20160301.txt">OpenSSL Security Advisory [1st March 2016]</a></q></div></figcaption>
</figure>
<p><a href="https://www.openssl.org/" title="OpenSSL">OpenSSL</a> などで SSLv2 を有効にしている場合, SSL を使用していなくても TLS 暗号通信を中間者攻撃で攻略することができるらしい<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>。
ポイントは SSL サーバのみでなくサーバとネットで繋がっている他のマシンにも影響をおよぼす可能性があることだ。</p>
<h3>CVE-2016-0702 : Side channel attack on modular exponentiation</h3>
<p>リスクは低いが, CVE-2016-0702 についても一応紹介しておく。
通称 <a href="http://ssrg.nicta.com.au/projects/TS/cachebleed/" title="CacheBleed: A Timing Attack on OpenSSL Constant Time RSA">CacheBleed</a> と呼ばれる side-channel 攻撃の一種である。</p>
<figure lang="en">
<blockquote>
<q>A side-channel attack was found which makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA keys. The ability to exploit this issue is limited as it relies on an attacker who has control of code in a thread running on the same hyper-threaded core as the victim thread which is performing decryptions.</q>
</blockquote>
<figcaption><div>via <q><a href="https://www.openssl.org/news/secadv/20160301.txt">OpenSSL Security Advisory [1st March 2016]</a></q></div></figcaption>
</figure>
<p>どうもこれ,2013年の GnuPG の脆弱性のバリエーションらしい。</p>
<ul>
<li><span><a href="http://eprint.iacr.org/2013/448.pdf">Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack <sup><i class="far fa-file-pdf"></i></sup></a></span> (<a href="https://baldanders.info/blog/000648/" title="Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack — Baldanders.info">当時書いた拙文</a>)</li>
</ul>
<p>Side-channel 攻撃は成立条件が特殊なので,一般的にリスクは高くない。
CVSSv2 基本評価値は 2.6 (AV:L/AC:H/Au:N/C:P/I:P/A:N) なので,こういう攻略法もあるといった程度に覚えておくといいだろう。</p>
<h2>影響度(CVSS)</h2>
<p><strong>CVSSv2 基本評価値 7.1 (AV:N/AC:H/Au:N/C:C/I:C/A:N)</strong></p>
<p>“<a href="https://www.kb.cert.org/vuls/id/583776">Vulnerability Note VU#583776 - Network traffic encrypted using RSA-based SSL certificates over SSLv2 may be decrypted by the DROWN attack</a>” より</p>
<table>
<thead>
<tr>
<th style="text-align:right">基本評価基準</th>
<th style="text-align:left">評価値</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:right">攻撃元区分(AV)</td>
<td style="text-align:left">ネットワーク(N)</td>
</tr>
<tr>
<td style="text-align:right">攻撃条件の複雑さ(AC)</td>
<td style="text-align:left">高(H)</td>
</tr>
<tr>
<td style="text-align:right">攻撃前の認証要否(Au)</td>
<td style="text-align:left">不要(N)</td>
</tr>
<tr>
<td style="text-align:right">情報漏えいの可能性(機密性への影響, C)</td>
<td style="text-align:left">全面的(C)</td>
</tr>
<tr>
<td style="text-align:right">情報改ざんの可能性(完全性への影響, I)</td>
<td style="text-align:left">全面的(C)</td>
</tr>
<tr>
<td style="text-align:right">業務停止の可能性(可用性への影響, A)</td>
<td style="text-align:left">なし(N)</td>
</tr>
</tbody>
</table>
<p><strong>CVSSv3 基本評価値 7.4 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)</strong></p>
<p>「<a href="http://jvn.jp/vu/JVNVU90617353/">JVNVU#90617353: SSLv2 の暗号通信を解読可能な脆弱性 (DROWN 攻撃)</a>」より</p>
<table>
<thead>
<tr>
<th style="text-align:right">基本評価基準</th>
<th style="text-align:left">評価値</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:right">攻撃元区分(AV)</td>
<td style="text-align:left">ネットワーク(N)</td>
</tr>
<tr>
<td style="text-align:right">攻撃条件の複雑さ(AC)</td>
<td style="text-align:left">高(H)</td>
</tr>
<tr>
<td style="text-align:right">必要な特権レベル(PR)</td>
<td style="text-align:left">不要(N)</td>
</tr>
<tr>
<td style="text-align:right">ユーザ関与レベル(UI)</td>
<td style="text-align:left">不要(N)</td>
</tr>
<tr>
<td style="text-align:right">スコープ(S)</td>
<td style="text-align:left">変更なし(U)</td>
</tr>
<tr>
<td style="text-align:right">情報漏えいの可能性(機密性への影響, C)</td>
<td style="text-align:left">高(H)</td>
</tr>
<tr>
<td style="text-align:right">情報改ざんの可能性(完全性への影響, I)</td>
<td style="text-align:left">高(H)</td>
</tr>
<tr>
<td style="text-align:right">業務停止の可能性(可用性への影響, A)</td>
<td style="text-align:left">なし(N)</td>
</tr>
</tbody>
</table>
<p>CVSS については<a href="https://text.baldanders.info/remark/2015/cvss-v3-metrics-in-jvn/">解説ページ</a>を参照のこと。</p>
<h2>影響を受ける製品</h2>
<ul>
<li>OpenSSL 1.0.1r およびそれ以前の 1.0.1 系列</li>
<li>OpenSSL 1.0.2f およびそれ以前の 1.0.2 系列</li>
</ul>
<p>また,このバージョンの <a href="https://www.openssl.org/" title="OpenSSL">OpenSSL</a> を利用している製品(Apache, Postfix, Nginx 等)も影響を受ける。
なお,公開されているサーバが <a href="https://drownattack.com/" title="DROWN Attack">DROWN</a> の影響を受けているかどうかテストするサイトがある。</p>
<ul>
<li><a href="https://test.drownattack.com/">test.drownattack.com</a></li>
</ul>
<p><a href="https://www.openssl.org/" title="OpenSSL">OpenSSL</a> 以外にも SSLv2 が有効になっている場合は今回の脆弱性の影響を受ける可能性があり,以下の製品・バージョンについて警告されている。</p>
<ul>
<li>Microsoft IIS (Windows Server) : バージョン 7 以降は既定で SSLv2 が無効化されている</li>
<li>MNetwork Security Services (NSS) : バージョン 3.13 以降は既定で SSLv2 が無効化されている</li>
</ul>
<p>LibreSSL は <a href="https://drownattack.com/" title="DROWN Attack">DROWN</a> の影響を受けないそうだ。</p>
<ul>
<li><a href="http://undeadly.org/cgi?action=article&sid=20160301141941&mode=expanded">LibreSSL not affected by DROWN attack</a></li>
</ul>
<h2>対策・回避策</h2>
<p><a href="https://www.openssl.org/" title="OpenSSL">OpenSSL</a> に関しては最新バージョンで対策されている。</p>
<ul>
<li>OpenSSL 1.0.1s</li>
<li>OpenSSL 1.0.2g</li>
</ul>
<p>SSL は既に仕様上の脆弱性を抱えており,可能な限り無効にすることをお薦めする。</p>
<ul>
<li><a href="http://www.ipa.go.jp/security/vuln/ssl_crypt_config.html">SSL/TLS暗号設定ガイドライン~安全なウェブサイトのために(暗号設定対策編)~:IPA 独立行政法人 情報処理推進機構</a></li>
</ul>
<p>どうしても SSLv2 を有効にしなければならない場合,証明書を分けて,他のプロトコルと共用しないようにすること。</p>
<h2>ブックマーク</h2>
<ul>
<li><a href="https://drownattack.com/">DROWN (Decrypting RSA with Obsolete and Weakened eNcryption)</a></li>
<li><a href="https://www.openssl.org/news/secadv/20160301.txt">OpenSSL Security Advisory [1st March 2016]</a></li>
<li><a href="https://www.kb.cert.org/vuls/id/583776">Vulnerability Note VU#583776 - Network traffic encrypted using RSA-based SSL certificates over SSLv2 may be decrypted by the DROWN attack</a></li>
<li><a href="http://jvn.jp/vu/JVNVU90617353/">JVNVU#90617353: SSLv2 の暗号通信を解読可能な脆弱性 (DROWN 攻撃)</a></li>
<li><a href="https://www.jpcert.or.jp/at/2016/at160010.html">OpenSSL の複数の脆弱性に関する注意喚起</a></li>
<li><a href="http://d.hatena.ne.jp/Kango/20160301/1456849603">OpenSSLの脆弱性CVE-2016-800(DROWN)やCVE-2016-0702(CacheBleed)についてまとめてみた - piyolog</a></li>
<li><a href="http://gigazine.net/news/20160302-drown-attack/">SSLの脆弱性で日本の大手サイトを含む全世界1100万以上のHTTPSサイトが攻撃を受け得ると判明 - GIGAZINE</a></li>
<li><a href="http://japan.zdnet.com/article/35078777/">HTTPSサイトの3割に影響する「DROWN」脆弱性見つかる–OpenSSLはパッチ公開 - ZDNet Japan</a></li>
<li><a href="http://www.itmedia.co.jp/enterprise/articles/1603/02/news065.html">「DROWN攻撃」の脆弱性が発覚,HTTPSサイトの33%に影響 - ITmedia エンタープライズ</a></li>
<li><a href="https://nodejs.org/en/blog/vulnerability/february-2016-security-releases/">February 2016 Security Release Summary | Node.js</a></li>
<li><a href="http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html">A Few Thoughts on Cryptographic Engineering: Attack of the week: DROWN</a></li>
<li><a href="http://arstechnica.com/security/2016/03/more-than-13-million-https-websites-imperiled-by-new-decryption-attack/">More than 11 million HTTPS websites imperiled by new decryption attack | Ars Technica</a></li>
<li><a href="http://qiita.com/tsukamoto/items/9a5242e39e255fdc194b">VMware製品へのDROWN脆弱性の影響情報 - Qiita</a> : VMware 製品には影響はないそうだ</li>
</ul>
<h2>【余談】 馬も鹿も暗号化する時代のセキュリティ</h2>
<p>一千万規模か。
意外と少ないな。
まぁ2014年に大騒ぎになった SSL 関連の脆弱性のおかげで SSL を無効にしたところも多かろう。</p>
<ul>
<li><a href="https://www.ipa.go.jp/security/announce/20141017-ssl.html">更新:SSL 3.0 の脆弱性対策について(CVE-2014-3566):IPA 独立行政法人 情報処理推進機構</a></li>
</ul>
<p>SSL を無効に出来ないサイトの多くは古い PC やケータイを考慮しているのだろうけど,もう考慮の余地はないと思う。
セキュリティを気にせざるを得ない他のユーザに迷惑をかけるからだ。</p>
<p>Web サイトを全て暗号化すべきという意見があって,セキュリティ専門家でも賛同者が多いが,私は懐疑的だ。
現在はセキュリティ要件が2,3年単位で変化し追従できないサービスやユーザも多い。
問題なのは,サイトが乗っ取らるなどして,暗号通信下で malware の活動を許してしまうことで,セキュリティ管理のいい加減なサービスが暗号通信を行うのはむしろ有害とさえ言える。</p>
<ul>
<li><a href="http://news.mynavi.jp/news/2016/03/01/106/">SSL VPNの9割がセキュリティ対策が不十分な状況 | マイナビニュース</a></li>
<li><a href="http://internet.watch.impress.co.jp/docs/news/20160229_745799.html">総SSL通信化時代のセキュリティ死角、F5ネットワークスが解説 -INTERNET Watch</a></li>
<li><a href="http://japan.zdnet.com/article/35078634/">サイバー攻撃を認識するまで平均2カ月かかる–CIO意識調査 - ZDNet Japan</a></li>
</ul>
<p>今だに SSLv2 や SSLv3 を有効にしているサイトがあるというのなら,そのサイトはセキュリティ上は全く信用できないと断言していいと思う。
脆弱な暗号通信を使うくらいなら,いっそ暗号化していない限定機能の HTTP サイトを用意して古いマシンのユーザは(安全でないことを警告したうえで)そちらに誘導する方がよい。
個人的な感覚では Web サービス全体の 2/3 程度が暗号化できていれば充分だと思う。</p>
<p>馬も鹿も暗号化するこの時代。
国家や企業の戯れ言に耳を貸す気はないが,それが本当は何を守ってるのか,そろそろ真面目に考えないといけないのではないのだろうか。</p>
<div class="hreview">
<div class="photo"><a href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1"><img src="https://m.media-amazon.com/images/I/51t6yHHVwEL._SL160_.jpg" width="113" alt="photo"></a></div>
<dl>
<dt class="item"><a class="fn url" href="https://www.amazon.co.jp/dp/B015643CPE?tag=baldandersinf-22&linkCode=ogi&th=1&psc=1">暗号技術入門 第3版 秘密の国のアリス</a></dt>
<dd>結城 浩 (著)</dd>
<dd>SBクリエイティブ 2015-08-25 (Release 2015-09-17)</dd>
<dd>Kindle版</dd>
<dd>B015643CPE (ASIN)</dd>
<dd>評価<abbr class="rating fa-sm" title="5"> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i> <i class="fas fa-star"></i></abbr></dd>
</dl>
<p class="description">SHA-3 や Bitcoin/Blockchain など新しい知見や技術要素を大幅追加。暗号技術を使うだけならこれ1冊でとりあえず無問題。</p>
<p class="powered-by">reviewed by <a href='#maker' class='reviewer'>Spiegel</a> on <abbr class="dtreviewed" title="2015-09-20">2015-09-20</abbr> (powered by <a href="https://affiliate.amazon.co.jp/assoc_credentials/home">PA-APIv5</a>)</p>
</div> <!-- 暗号技術入門 第3版 -->
<div class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1">
<p>TLS と SSLv3 で同じ証明書を使用している場合。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p>
</li>
</ol>
</div>