security:sslは暗号化のためのものではありません [TenForward]

この文書は読取専用です。文書のソースを閲覧することは可能ですが、変更はできません。もし変更したい場合は管理者に連絡してください。
====== SSL is not about encryption 翻訳 ======
 
**<fs 150%>このページは Troy Hunt 氏による [[http://www.troyhunt.com/2011/01/ssl-is-not-about-encryption.html|SSL is not about encryption]] の翻訳です</fs>**．\\ 

  * <fs 150%><color red>**@kfujieda さんによるもっと良い翻訳が登場しました．勉強になります．このページのものよりそちらをご参照ください．**</color>→ [[https://github.com/fujieda/fujieda/wiki/SSL%20is%20not%20about%20encryption|SSL is not about encryption]]</fs>
    * <color red>言い訳になりますが，もちろん藤枝さんのおっしゃるような「SSLの主目的は暗号化ではない」というのは理解しています．そこをあえて今回のようなタイトルに訳したのは私なりの考えがあってのことです．ただ，「翻訳」というものが期待されるものからすると不適当だったかも知れません．</color>
    * <color red>自分が通信をしたい相手であることがきちんと確認が取れた相手と暗号化通信を行わないと意味がないと思いますが，「暗号化されてるからいいでしょ」というような事を今まで何度か聞いた事があり，それは違うだろうと思った事があります．この原文についても同じような事が言いたいのかなというのを感じましたので，相手の確認が取れないまま暗号化通信しても意味ないでしょう，という意味でこのような少し刺激的なタイトルを付けたというわけです．**タイトルだけでなく本文を読めば「SSLの主目的は暗号化じゃない」というのは判りますので (翻訳のマズさは別にしても)．**</color>
    * 本文についてはもちろん藤枝さんの翻訳の方が私のような者がやった翻訳より分かりやすいのは言うまでもありません．私も勉強になります．

  * 翻訳の間違い等を見つけられたらご連絡いただければありがたいです．(-> [[https://twitter.com/ten_forward|@ten_forward]])
  * twitter 上での [[https://twitter.com/matsuu/status/232154112651837440|@matsuu さんの tweet]] をきっかけに訳してみました．@matsuu さんにも一部翻訳にご協力いただいています．(_o_)
  * 最後の section と各 section のタイトルの訳も自分ではいまいちしっくり来ていないので間違いの指摘や，もっと良い訳の提示は歓迎です．
====== SSL は暗号化のためのものではありません ======

それは保証に関する事なのです．それはサイトの正当性についてある程度の信頼を確立するためのものなのです．正当性とはあなたが充分に確信を持って情報を送受信できることです．プロセスの途中で改竄されたり盗聴されたりすることなく，目指す宛先に到達することです．

先週，私は [[http://www.troyhunt.com/2011/01/whos-who-of-bad-password-practices.html|「悪いパスワード習慣の紳士録」(Who’s who of bad password practices)]] という(少し)皮肉っぽい投稿をしました．私は SSL を使っていない事をブラウザ内に表示しないまま SSL を使っていない多数のサイトについて批判的でした．"しかし待て！" と何人かがコメントで叫びました．"それでも HTTPS でポストが可能で，そのデータは暗号化されます" と彼らは叫びました．"恐怖と正しくない理解を広めるのを止めろ" と彼らは警告しました．(訳注: フォームページが http で submit が https でなされるようなページについて話してる?)

私は注意深くこれらの反応について考え，投稿の最後で少し更新を行いました．しかし，HTTP のページから HTTPS でデータをポストする話は単なる脚注以上に価値のある話題です．この話の本当の誤解は，認証情報が暗号化されて届くというだけで SSL が適切に適用されていると信じられている事です．この信仰の何が間違っていて，SSL にただ暗号化するだけ以上の何があるのかを良く見てみましょう．
===== 明確なフィードバックなしのみせかけの保証 (Assumed assurance without positive feedback) =====

では，暗号化についての話題を始めましょう．そして親しみのあるサイトをいくつか見てみましょう．あなたの認証情報が通信路上で保護されるのは以下のどのサイトだと思いますか？

{{:security:image3.png|}}

{{:security:image7.png|}}

{{:security:image11.png|}}

これらのうちのどれですか？実際には，これらのサイトは認証情報を送る際に SSL を使用します．しかしもちろん，前述のどの画像からもそれを知る方法がないですよね？もしあなたに少しでも技術的な知識があれば，ページのソースコードを検査してフォームのポスト先が HTTPS アドレスであることを発見したり，Fiddler で観察してリクエストを観察して，HTTP から HTTPS にプロトコルが変わっているのを発見できるでしょう．

しかし，問題はたくさんの人達はあなたではないということです．彼らがサイトの相対的なセキュリティを判断するために使えるものは，色々な所で目にする SSL のインジケータ経由でブラウザが与えてくれる情報だけなのです．この情報がないと，おそらくこれらのサイトの注目度から，このサイトの正当性と彼らの認証情報が適切に保護されていると**推測する**のでしょう．

===== 明確なフィードバックがあったりなかったりする暗黙の保証 (Implicit assurance either with or without positive feedback) =====

ちょっと違った角度から他のサイトを見てみましょう

{{:security:image27.png|}} {{:security:image36.png|}}

{{:security:image42.png|}} {{:security:image45.png|}}

これらのサイトが作ろうとしている保証は暗黙のものです．彼らはこういいます．「ヘイ，オレ達のログインフォームには南京錠の画像があるだろ!? だからオレ達はセキュアだぜ．」 もちろん，これは何の保証にもなりませんし，こんなどこにでもある (殆どのブラウザがリクエストが HTTPS で行われる場合に表示する画像と気持ち悪いくらい似ている) 南京錠の画像は，正当性とセキュリティをそれとなく示そうとする試みにしか過ぎません．

ここで言いたいポイントは，ブラウザが SSL の存在を積極的にはっきりと見せ，証明書を検査出来るようにしていなければ，これらのアイコンには全く意味がないということです．事実，これらは非常に誤解を招きやすいですし，SSL が存在しているかどうかに関わらず，単純ではない何かをほのめかすことにより，セキュリティについての間違った考えを作り出しています．

===== 明確なフィードバックと保証をするということ (Creating positive feedback and explicit assurance) =====

メジャーなブラウザは全て，明確な保証を与える事により，サイトの真偽と正当性を積極的にアドバイスする機能を持っています．この機能は通常，URL バーに表示され，実装によって表示に個性がありますが，そのコンセプトは一貫性のあるものです．

{{:security:image18.png|}}

{{:security:image9.png|}}

{{:security:image12.png|}}

{{:security:image15.png|}}

{{:security:image6.png|}}

{{:security:image21.png|}}

iPhone 版 Safari を除く (ついでに言うと iPhone 版 Opera も) これらのブラウザそれぞれには，SSL 証明書の詳細を簡単に表示するという更に保証を与えてくれる機能があります．

{{:security:image24.png|}}

この課題の核心は，ユーザが簡単にサイトの正当性を確認でき，データが確実に通信中に暗号化されるという確信を明確にあたえてくれるということです．そして，このことは問題の核心を示してくれます．**つまり HTTPS 上でログインフォームを表示させないことは，あなたの認証情報を送信する前に，サイトの正当性を全く保証してくれないということなのです**．

===== HTTP から HTTPS へ移行するパターンでの攻撃 (Exploiting the HTTP to HTTPS pattern) =====
 
このリスクを説明する一番簡単な方法は，典型的な [[http://ja.wikipedia.org/wiki/%E4%B8%AD%E9%96%93%E8%80%85%E6%94%BB%E6%92%83|中間者攻撃]] ([[http://en.wikipedia.org/wiki/Man-in-the-middle_attack|man-in-the-middle attack]]) を見る事です．

> 攻撃者は攻撃の標的との間でそれぞれと独立したコネクションを張り，標的間のメッセージをリレーします．このことにより，標的の双方がプライベートなコネクションをお互い直接行っていると信じさせます．実際は全ての会話は攻撃者のコントロール下にあります．

MITM のシナリオでは，PC とサーバ間のある点に攻撃者がいる必要があります．インターネットの性質上，データが通る中継地点は非常に多数存在します．

クライアントが無線 LAN ルータと接続して，インターネットへのゲートウェイを通り，ISP を通り，目的とするサーバに到達するまでに多数のインターネットノードを経由する可能性のあるような，典型的な無線 LAN が使えるカフェのシナリオを思い浮かべてみてください．

HTTP 上でログオンフォームをリクエストすることの問題は，前述のような多数のポイントのどこででも操作が可能ということです．全く賢明ではないことでしょう．最近の[[http://www.thetechherald.com/article.php/201101/6651|ユーザ名，パスワードが搾取していたチュニジア政府(Tunisian government harvesting usernames and passwords)]]の例を見てみましょう．

> The Tunisian Internet Agency は，ユーザ名とパスワードをキャプチャする JavaScript の注入 (inject) の存在が明らかになり非難を受けています．このコードは Gmail, Yahoo, Facebook のログインページで発見されました．これは，チュニジアの抗議団体が報告したアカウントハイジャックの頻発の理由といわれています．

これらのサイトのログオンページにスクリプトを埋め込んだ ISP のこのケースでは何が起こっていたのでしょう? 万が一に備えて，この問題が引き起こした問題は全て明らかにはなっていませんでした．

> The Tech Herald が相談した 4 人のエキスパートがそれぞれ，埋め込まれたコードがログインの認証情報を吸い上げていたという我々の考えを確認しました．

しかし，本当の話はもう少し小さいものでした．

> 埋め込まれた JavaScript は，これらのサイトの一つに HTTPS の代わりに HTTP でアクセスした時だけ出現していました．それぞれのテストケースで，Gmail と Yahoo は HTTP が使われたときだけ情報漏洩が起こっていた事が確認できました．一方，Facebook についてはデフォルトのアクセスは HTTP ですので，チュニジアのユーザは手動で HTTPS のアドレスを訪れる必要がありました．

これらのサイトが (認証情報を) HTTPS でポストしていたことは関係ありませんでした．ログオンフォームをセキュアではない方法で表示できていたという事実だけで，ISP がコンテンツを改ざんし，HTTPS でポストされる**前に** JavaScript 経由で認証情報をキャプチャするのに十分だったのです．単純に HTTPS 上でセキュアにログオンフォームが提供されるだけで (Facebook の例で示されたように)，この exploit は起こりませんでした．

独裁政権下の悪徳 ISP は一つの例です．しかし，あなたが公衆無線 LAN に接続するたびに起こる事が考えられます．[[https://blogs.oracle.com/ksplice/entry/coffee_shop_internet_access|コーヒーショップのインターネットアクセス(Coffee shop Internet access)]]のシナリオを例に挙げましょう．

> インターネットの設計方法は驚くべきです．ゲートウェイルータは HTTP リクエストをハイジャックできますし，それを防止する方法はありません．このケースでは，リダイレクトの後にブラウザで URL が変わるのを見る事が出来ます．しかし，悪意のあるゲートウェイが，悪意のあるマルウェアを含んでいる www.google.com のクローンへ HTTP リクエストを透過プロキシしていたら，URL は変わらないのでそれに気づく方法はありません．

これはちょっと面倒な事であり，公衆無線 LAN につなげるたびにこのリスクにさらされるわけです．もちろん，認証情報を渡す前にサイトの正当性への明確な保証にアクセス出来ない場合は単純に，この問題に対する事態は悪化します．

しかし，HTTP から HTTPS への移行パターンの exploit の他の方法も存在します．例えば [[http://en.wikipedia.org/wiki/DNS_cache_poisoning|DNS poisoning]] です．完全に異なるホストに正当なアドレスへのリクエストを送らせる事ができれば，悪意あるホスト上のコンテンツ (Facebook ログオンページに似せたページとか) を作成する機会が持てます．これは明らかに関連する悪い問題です．しかし，もちろんこの方法では正当な SSL 証明書を出せないので，正当な証明書がない事を何か間違っている事を判断するのには使えるかもしれません．しかし，この判断は**ログオン前に証明書の提示を要求する場合**にのみ適用できることであり，HTTP ページから HTTPS ページへのポストを行うパターンでは使えません．
===== OWASP の見解 (The OWASP position) =====

もちろん，これらの事に対する異なった角度からの見方は常に存在します．なので私は [[http://security.stackexchange.com/questions/1692/is-posting-from-http-to-https-a-bad-practice|HTTP から HTTPS へポストする事は悪い習慣ですか?]] という質問を Security Stack Exchange で行いフィードバックをいくつか探してみました．納得のいく回答として[[https://www.owasp.org/index.php/SSL_Best_Practices|OWASP SSL Best Practices]] を引用します (訳注: 今は以下の引用はこのページからは消えているようです．更新履歴をたどれば見えます)．

> ログインページでは SSL を使わなければならない
> ユーザがフォームに入力する実際のページは HTTPS ページでなければいけません．もし違えば，攻撃者がページを改ざんして，フォームを送信するロケーションを変えたり JavaScript を挿入したりしたものがユーザに送られ，そこで入力したユーザ名・パスワードが盗まれます．

分かりやすいでしょう? これは先の議論を通して既に確立したポイントへ私たちを連れて行ってくれます．もしログオンページが SSL 上でリクエストされなければ，**あなたはサイトの真偽について保証を得ることが出来ません**．
===== セキュリティは SSL で始まるわけでも終わるわけでもない (Security doesn’t start and end at SSL) =====

(訳注: ここのセクションはかなり訳に自信がありません)

誰かに言われる前に言っておきますが，適切に実装された SSL でもトランスポート層より上位のセキュリティに関しては保証してくれません．ウェブサーバより先からは全くめちゃくちゃになり得ます (訳注: この一文は良く分かりません．ウェブサーバまでのトランスポート層の通信が暗号化されていても，それ以外の部分で攻撃を受ける可能性はいくらでもあるんだよという意味かな? と)

SSL も絶対確実ではありません．多かれ少なかれ，弱点を突くたくさんの例が存在しています (例えば，[[http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/|200台のPS3でMD5を破った]]例など)．簡単ではありませんが，行う事は可能です．

しかし，見たところ SSL が唯一我々が持つ保証になっています．我々がサイトと処理を行うときの保証とデータの整合性に信頼を与えてくれるのに使われるものは SSL ぐらいしかありません．

認証情報をポストする所で SSL を実装する努力はするけれども，意識的にログオンページの表示から SSL を除外する事は，SSL の潜在能力を除外して，セキュリティの本質的なレイヤーを売り渡すようなものです．Facebook や twitter や Dropbox さえもが取るこの方法は非常に奇妙なものなのです．