Downloaded 73 times
![タイ文字と若干情報科学[修正版]](https://cdn.slidesharecdn.com/ss_thumbnails/random-170324064855-thumbnail.jpg?width=640&height=640&fit=bounds)
SSL で守られる生活
- 1.
- 2. 自己紹介 ID: nona7 KMC二回生 KMCでの主な活動: ● サーバの管理とか ●こたつでだらだら ● Slack の全チャンネルに入ったりとか
- 3.
- 4. 注意 ● このスライド中に間違いが存在するかもし れません。 o 自分のセキュリティは自分で確保するしかありませ ん。 oクリティカルなことは自分で確認して下さい。 ● 常に悪意のある攻撃者を想定するのはコス トが高くつきます。 o 扱っている情報のたいせつさによって適切な判断を
- 5.
- 6.
- 8.
- 9.
- 10.
- 11. 私達は監視されている ● NSA ● プロバイダ ●公衆無線LANに偽装した攻撃者
- 12. 私達は監視されている ● NSA ● プロバイダ ●公衆無線LANに偽装した攻撃者 ● あなたの家族
- 13. 私達は監視されている ● NSA ● プロバイダ ●公衆無線LANに偽装した攻撃者 ● あなたの家族 ● あなたのサークルの管理者
- 14. NSA ● アメリカ国家安全保障局 ● “エシュロン”などを運用し、アメリカの外 の通信を傍受しているとされる。 ● 電子メール、データ通信、音声通話等、 様々な通信を傍受しているとされる。 ● 私達一般市民の通信に興味はない？ o が、大量の一般市民の通信から何か意味を見出しているかもしれない。
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. そもそもつらい。 ● プロバイダ、家族やサークルの管理人が信 頼できないモデルを考えるの辛すぎる。 ● 攻撃の可能性と扱う情報の価値によってど こまで考えるかちゃんと選びましょう！！ o身近な人にパスワード漏れたほうがすぐに表われる ダメージ大きいですよ。 ● ある日突然攻撃されても安全なようにして おきたい。
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27. SSLは私達を救う ● 様々な攻撃者がいろいろなところに存在す る インターネットの中で私達を守る技術の 一つ。 ●気づかないうちにお世話になっている｡
- 28. SSLとは？ ● Secure SocketsLayer の略。 ● 主として TCP 上で安全な通信経路を確保す るプロトコル。 ● 通信相手の認証、通信内容の暗号化、改ざ んの検出などの機能が提供されている。
- 31. 証明書 ● X.509 証明書 ●「私はこの人から信用されています！」を 表す｡ ● 信頼してる人を上に辿っていって､自分が信 頼している人が見つかれば､その人は信頼で きるとする｡ ● SSLクライアント(ブラウザとか) は信頼でき る人リストを持っている｡
- 32. 証明書 ● 証明書を発行できるのは特殊な証明書を持 った人のみ｡(この証明書を発行できる人、機 関を CAと呼ぶ。) ● CAは全幅の信頼が置け､決して攻撃者でない ことを SSL では仮定している｡ ● ⇒ 正しい証明書を持っているなら正しい相 手である ということになっている｡
- 33. SSL？ HTTPS？ ● HTTPSは SSL の上で HTTP 通信を行う。 ● SSL は上で HTTP 以外のプロトコルも通す ことができる。 o FTPS(SFTP) o SMTPS o IMAPS o POP over SSL o 等、様々なものが SSL の上を通っている。
- 34. SSL の歴史 ● SSL1.0 o 作成段階で致命的な脆弱性が見つかり実装されず。 ● SSL 2.0 o 攻撃を回避不能な脆弱性が発見され、既に廃止。 ● SSL 3.0 o 1995年に仕様が策定。 o IE 6 で HTTPS の通信ができる最新のSSL
- 35. SSL の歴史 ● TLS1.0 o SSL 3.0 のマイナーチェンジ的立ち位置とされる。 o 4.3 までの Android はここまで。 ● TLS 1.1 o 1.1 に対応しているようなものは大抵 1.2 まで対応 している。 ● TLS 1.2 o 現在の最新版
- 36. SSL was dead. ●2014年10月 ● Google によって発見された CVE-2014- 3566 ● POODLE attack ● SSL 3.0 の仕様に存在する中間者攻撃に対す る脆弱性。 ● SSL 3.0 を無効にするよう勧告が出る。 o SSL 3.0 までした対応していない IE 6 は死んだ。
- 37. あたらしい TLS の話 今までこのスライドでもSSL、SSL と言って 来ましたが、SSL は死にました。 これからはきちんと TLS と呼んでいきましょ う。
- 38. How it works? TLSがどのように安全な通信経路を確保してい るか、簡単に説明していきます。
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 50.
- 51. はい Client Hello, ServerHello, Client KeyExchange で交わされた3つの乱数がもれない限りはさっ きの手順に問題は無いです｡
- 52. はい Client Hello, ServerHello, Client KeyExchange で交わされた3つの乱数がもれない限りはさっ きの手順に問題は無いです｡ 2つのHello によって交わされた乱数は特に暗号 化されて送信しているわけではなかったので､ 監視者には筒抜けです｡
- 53. はい 頼みの綱は実質 Client KeyExchangeで渡され た乱数だけです｡
- 54. はい 頼みの綱は実質 Client KeyExchangeで渡され た乱数だけです｡ この乱数は48バイトの長さを持ちます｡
- 55. はい 頼みの綱は実質 Client KeyExchangeで渡され た乱数だけです｡ この乱数は48バイトの長さを持ちます｡ 全探索とかで頑張るには辛いです｡
- 56. はい 頼みの綱は実質 Client KeyExchangeで渡され た乱数だけです｡ この乱数は48バイトの長さを持ちます｡ 全探索とかで頑張るには辛いです｡ じゃあ安全では｡
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. 秘密鍵の漏れるとき｡ ● 不適切な設定 ● 不適切なサーバの廃棄 ●サーバの脆弱性とか
- 64. 秘密鍵の漏れるとき｡ ● 不適切な設定 ● 不適切なサーバの廃棄 ●サーバの脆弱性とか o Heartbleed ！！
- 65. heartbleed ● 2014年4月 ● 世界で一番使われている暗号化ライブラリ であるOpenSSL に秘密鍵が漏れたりするバ グが二年ほど前からあったことが発表され る｡ ● 全然使われていない、SSL ハートビート拡 張なる所にメモリの境界チェック漏れが存 在していた。
- 66. heartbleed ● サーバからは正常なリクエストに見えるが、 一回あたり最大65535バイトづつメモリの内 容が漏れる。 ● NSAはこの脆弱性を知っていたが、公表せ ずに、諜報に利用していたとされている。
- 67.
- 68.
- 69.
- 70. ● ディフィー・ヘルマンの頭文字｡ ● DHEの E はエフェメラルのEで､永続的な鍵 を持たないとこを表す｡ ● お互い何も共通の秘密を持たなくても､暗号 鍵の共有を可能とするアルゴリズム｡ DH
- 71. 簡単な DH の説明 ●大きな素数p と､2以上p-1以下の数gを共有し､ クライアントとサーバはそれぞれ0以上p-2 以下の数をランダムに選ぶ(それぞれa,bとす る)｡ ● クライアントは A=g^a % p を､サーバは B=g^b % p をそれぞれ相手に送る(% は剰余 関数)(これが公開鍵)｡ ● それぞれB^a%p, A^b%pを考えると､どちら
- 72. 簡単な DH の説明 ネットワークを通る数はA(= g^a)%p､ B(=g^b)%pのみで､この二つのみから g^ab%p を求めたり､A から a を求めようとすることは､ 離散対数問題となり､多項式時間で解く方法は 見つかっていない｡
- 73.
- 74. ECDH ● 楕円曲線ディフィー・ヘルマンの頭文字｡ ● ECDHEの E はエフェメラルのEで(ry ● DH と同じようなことを楕円曲線上の演算で やってるらしい｡ ● 楕円曲線とか言われてもよくわからない｡ ● DH よりも更に解くのが難しい？(DH より優 先して使われる設定となってることが多い)
- 75.
- 76.
- 77. めでたしめでたし 最近はどこと TLS で通信してもECDHE 使っ てる感じですね｡
- 78.
- 79.
- 80.
- 81.
- 82. 気をつけよう ● 実は証明書発行局の秘密鍵が漏れていて､ "有効な" 証明書がばんばん刷られている｡ ●未知の脆弱性により秘密鍵が漏れている｡ ⇒正直どうしようもない｡
- 83. 気をつけよう ● そもそも TLSを使っていない｡ ⇒ パスワードを入力する時に確認する｡ 意外と「SSL はこちら」を押さないと HTTP で通信しているサイトがまだある……｡
- 84.
- 85.
- 86.
- 87.
- 88. 気をつけよう ● TLS を処理するライブラリとかがバグって る｡ ⇒セキュリティアップデートが来たらすぐか けよう｡
- 89. goto fail ● iOS7.0.6 以前に存在したバグ｡ ● 証明書の検証するところにバグがあって､不 正な証明書でも受け入れるようになってい た｡
- 90. 気をつけよう ● そもそも変なホストにアクセスしていた｡ ⇒ tvvitter.comの有効な証明書を提示されても､ それは Twitter とは関係ないですよ｡
- 91. まとまらない ざっと TLS のしくみについて喋ってきました｡ とりあえず「SSLはこちら」があればそっち を使う ってことだけでも覚えてってください｡
- 92.
- 94.
- 95.
- 96. 俺たちの戦いはこれからだ！ ● PGP/GPG ● Tor ●I2P ● VPN Gate
Editor's Notes
- #3 ring に入れてほしいパッケージがあったりしたら言ってね｡ 変なイベントがあったら顔をつっこんだり。
- #4 魑魅魍魎の跋扈するインターネットにおいて、少しでも安全な生活を送っていくことを目指しましょう｡
- #5 何でもかんでも最大のセキュリティを確保しようとするのは、コストが高すぎます。 ……ことはわかっているのですが、なかなかそれも難しくて、どうしても Wikipedia の記事ページに HTTP で接続してしまうと、やってしまった と思ったりしてしまいます。私は、HTTP と HTTPS で同じコンテンツを配信しているサイトには HTTPS で接続しないと気がすまないです。 少し前までは Twitter や Google 検索, youtube や flickr はデフォルトでは SSL で通信しないようになっていましたが、現在はそれらはもう SSL を強制するようになっています。 Wikipedia もログインしていればログイン中ずっと SSL を設定で強制できるので、だいぶマシです。 Amazon はひどくて、商品ページには名前が載っているのに、HTTP を使って送信してくる。
- #8 image: http://commons.wikimedia.org/wiki/File:1984-Big-Brother.jpg Copyleft: This work of art is free; you can redistribute it and/or modify it according to terms of the Free Art License.
- #9 私たちは、様々なところから監視を受けています。 例えば
- #10 アメリカ国家安全保障局
- #14 他にもいろいろな攻撃者が存在していると思います。
- #15 image: PD https://commons.wikimedia.org/wiki/File:National_Security_Agency.svg
- #17 CG_guest とか､001Softbank とかそういう名前にして鍵開けておけばだれかがまぁつないでくるでしょう｡ #大学内で鍵のかかっていない MIAKO という SSID の電波が飛んでいれば、接続してしまうでしょう。 #最も、MIAKO の場合は VPN を通さないと通信できない設定になっているので、あまり問題にはならないでしょうが。
- #21 監視されてる監視されてる って言うけれど､具体的にどういうふうに攻撃を受ける可能性があるのかを適当な例として上げてみます｡
- #22 某イラスト投稿サイトP のトップページに普通にアクセス
- #23 あなたのアドレスバーには http://www.pixiv.net と書かれていそう。 とかいいつつ chrome では http の時は省略されるので、 www.pixiv.net としか出ない。
- #24 ここからログインする。
- #25 ログインボタンを押す。 このログインボタンは /login.php へのPOST を投げるものになっているので
- #26 よく見る
- #27 今の URI は http://www.pixiv.net だったので、/login.php は http://www.pixiv.net/login.php となり、そこに生の HTTP でPOST リクエストを投げる。 その際通信は暗号化されないので、途中の経路にいる人には pixiv_id と pass がわかる。 さっきの例だと、悪意ある無線AP 提供者や、あなたの家族、あなたのサークルの管理者はあなたの通信の経路に入り込むことは容易である。 DNS を偽装して(例の三者はこれもまた容易にできる)、中間者攻撃したり、DHCP で配るデフォルトルートを変なところに向かせたりすることによって実現できる。 私がこっそり DNS に変なフィールドを挿入しても、一月ぐらいなら他の管理者に気づかれないような気がする。多分。
- #29 さっきの例で、DNS に変なレコードを入れたりして中間者攻撃を試みても、有効な証明書を用意できないので、攻撃は失敗する。 証明書が何なのかは後述｡ ブラウザが怒ってくれる。
- #30 Chrome
- #31 firefox
- #32 大抵のクライアントはデフォルトでベリサイン等を信頼できる人リストに入れているが､ユーザが自分で追加することもできる｡ RSA を使って署名されている｡ 証明書には､RSA の公開鍵が入っています｡ 証明をした側の秘密鍵により署名されており､署名した側の秘密鍵が安全に保管されているなら改ざん､偽造は不可能です｡ RSA による暗号化は自己同型で､暗号化と復号化は逆関数となっているので､平文を秘密鍵で復号したものを公開鍵で暗号化すれば元の文と一致し､この性質から署名として使える｡
- #34 ircs...
- #36 TLS 1.3 が現在策定中。
- #40 下向きに通信が､時間が進んでいく｡ クライアントをブラウザで､サーバを HTTPS で Web ページを配信してるサーバだと考えてもいいです｡ お互い相手のことを何も知らないので､最初は全く暗号化されていない通信を行います｡
- #41 クライアントがサーバに接続を開始する際に､まず Client Hello メッセージを送信します｡ このメッセージには､暗号通信を行うための暗号化キーを作るためのハッシュに通すためのシードとして使う乱数と､ クライアントが受け入れられる鍵交換アルゴリズム､暗号化アルゴリズムとハッシュアルゴリズムの組み合わせの一覧､セッション再開が有効になっていれば、セッションID、SNI拡張が有効になっていれば(最近のまともなTLS対応ソフトなら有効になっています)､クライアント側がアクセスしているHost名などが入っています｡ この SNI 拡張は HTTP/1.1 の Host ヘッダと同じような役目で､一つのIPアドレスで複数のTLSの通信をホストしたりできるようになっています｡ この後にサーバ側から証明書が送られてくるのですが､そこに Host 名の情報が埋め込まれており､適切な証明書をサーバが返すことがこれによってできます｡
- #42 クライアントからのメッセージに対して､サーバ側は server hello メッセージを返します｡ client hello と同じように､暗号化通信を行うキーを作るシードとしてサーバ側で生成した乱数と､ クライアントが提示してきたアルゴリズムの組からサーバが一番いいと思うようなものを一つ選び､これをつかうとクライアント側に提示します｡ まだ暗号化通信は開始されていないので､さっきクライアントから送られてきたシードと､サーバが今返したものは､共に途中に通信を覗き見る人がいる場合筒抜けなことに注意してください｡ ここでは鍵交換のアルゴリズムで RSA を使うものが選ばれたと仮定して話をススメます｡
- #43 サーバは証明書を提示します｡ クライアントは､受け取った証明書を信頼できるかどうかを証明書の発行者をさかのぼってゆき､自分の信頼できるとしている証明書が出てくるか確認します｡ それと同時に､証明書埋め込まれている名前(完全修飾ドメイン名､URI のホスト名と思って良いです)と､通信相手の名乗る名前が同じかどうか確認します｡ 証明書が信頼できなかった場合､または通信相手の名乗る名前と証明書に書いてある名前が一致しなかった場合､ここでクライアントは接続を破棄します｡ 正しい証明書を持てるのは本人だけであるということになっているので､証明書が問題なかった場合､通信相手は正しい相手である事がわかります｡ これにより､中間者攻撃などのおそれは無いということが確認できます(中間者は正規の証明書を手に入れることができないため)｡
- #44 Server Hello Done メッセージをサーバは送信します｡ 後述する他の鍵交換アルゴリズムを使う場合や､クライアント証明書を使う場合､サーバの証明書を提示してからこのメッセージを送るまでの間に他のメッセージが入ります｡ クライアント証明書とは､SSH での公開鍵認証のようなもので､パスワードでクライアントを認証する代わりに､クライアントにも証明書を提示してもらい､それによって認証を行ったりするためのものです｡ KMC の内部ページもパスワードでログインするの面倒だし､クライアント証明書で入れるようにしたいなぁとは思ってるのですが､設定がめんどくさいのでなかなかそうなっていません｡
- #45 今クライアントとサーバは RSA を使い鍵交換をしていると仮定していました｡ クライアント側は､更に乱数を生成し､それをサーバの証明書に入っているサーバの公開鍵で暗号化し､ サーバに送信します｡ これは RSA による暗号化が施されているので､ClientHello と ServerHello で交換された乱数と異なり､ クライアントとサーバのみが知っている情報となります｡ この乱数と､Hello メッセージで交換された2つの乱数を合わせて(今までの手順より､この3つの乱数は､クライアント側とサーバ側で共有されています)､MD5 と SHA-1 を合わせたようなハッシュ関数に通し､そこからハッシュ関数を繰り返し用いることで任意有限長のビット列を作り､それと目的の通信内容との XOR をとることにより共通鍵暗号を行います｡
- #46 以上で暗号化の準備は整ったので､クライアントは､ Change Cipher Spec メッセージを送信し､これ以降の通信は暗号化通信に切り替えることを宣言し､ Finished メッセージを送信し､きちんと鍵交換が成功しているかどうかの確認を行います｡
- #47 サーバ側もChange Cipher Specメッセージと､Finishedメッセージを送信し､お互いに鍵交換が成功しているかを確認できたら､ 合意した暗号化方式での暗号通信を開始します。(正確には、Finished メッセージは、合意した形式で暗号化されている。) これが HTTPS の通信であれば､普通の HTTP の通信にさっき作った任意有限長のビット列との XOR をかけたものがやりとりされることになります｡ Cl hello で有効なセッションID があるときは、サーバはServer Hello に適切な返答を入れ、即座に ChangeCipherSpec メッセージを送信する。 これにより、RSA とかの重い処理を省略できるので、大分楽になる。
- #49 何が問題でしょうか？
- #50 image: http://commons.wikimedia.org/wiki/File:1984-Big-Brother.jpg Copyleft: This work of art is free; you can redistribute it and/or modify it according to terms of the Free Art License.
- #55 48 以上 のまちがい
- #62 間違えて Web サーバから見えるようになっちゃうとか
- #63 捨てられたサーバからTLSの秘密鍵を盗む とかを NSA は行っているとされているらしい｡
- #66 image: CC0 https://commons.wikimedia.org/wiki/File:Heartbleed.svg
- #70 TLS において､ FS の性質を持つものはすべて PFS だから､パーフェクトである性質の説明は飛ばします｡ # FS + # 鍵合意のために公開可能な、ランダムな値を使う。 # 鍵合意の過程で決定的なアルゴリズムを一切使わない。 # でPFSになる｡
- #75 E RSA 暗号強度の低い、輸出用暗号で選べる鍵交換方式の一つ。 DH は高速に鍵を作れるが、RSA は辛い。
- #77 Certificate とServer Hello Done の間にServer Key Exchange のプロセスが入る｡ DH や ECDH はそのままでは中間者攻撃に脆弱だが､Certificate メッセージを送ったあとなので､クライアントは鍵交換している相手が正しいサーバであるとわかる｡ Server Key Ex とCli Key Ex で DH の鍵交換を行い､それによって共有されたさっきの表示でいう g ^ab mod p と､Cli Hello, Srv Hello で渡した乱数の3つを使い､あとは RSA で鍵交換したときと同様に暗号通信する｡
- #82 以下、適当に安全性が崩れたりしそうな感じの注意をするべきなこととかです。
- #83 きちんとさっきの仮定がすべて成り立っていれば､一応安心できるように思うけれども､そうでない時はそうでない｡
- #85 どうでもいいようなサイトだったらまぁいいんだけど､Pixiv とか Booth に連携ログインできるしクレジットカード登録してるしどうなんだ……｡ って感じする｡ まともなサイトだとさすがにもう