Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SSL で守られる生活

15,385 views

Published on

パラノイアの妄言

Published in: Self Improvement
  • Google Docs 版 https://docs.google.com/presentation/d/17VHV-79Vv5rc3uMZUDHeDSxyBc6vo20sshDPyYGCrRM/edit?usp=sharing
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

SSL で守られる生活

  1. 1. 2015年春合宿 SSLで守られる生 活
  2. 2. 自己紹介 ID: nona7 KMC二回生 KMCでの主な活動: ● サーバの管理とか ● こたつでだらだら ● Slack の全チャンネルに入ったりとか
  3. 3. このスライドの目的 ● いつも身を守ってくれている物のうち、おそ らく一番身近であるSSLについて紹介します。 ● また、その恩恵をきちんと受ける為注意し ないといけない事を notify します。
  4. 4. 注意 ● このスライド中に間違いが存在するかもし れません。 o 自分のセキュリティは自分で確保するしかありませ ん。 o クリティカルなことは自分で確認して下さい。 ● 常に悪意のある攻撃者を想定するのはコス トが高くつきます。 o 扱っている情報のたいせつさによって適切な判断を
  5. 5. はじまるよ
  6. 6. 私達は 監視されている!!
  7. 7. 私達は監視されている
  8. 8. 私達は監視されている ● NSA
  9. 9. 私達は監視されている ● NSA ● プロバイダ
  10. 10. 私達は監視されている ● NSA ● プロバイダ ● 公衆無線LANに偽装した攻撃者
  11. 11. 私達は監視されている ● NSA ● プロバイダ ● 公衆無線LANに偽装した攻撃者 ● あなたの家族
  12. 12. 私達は監視されている ● NSA ● プロバイダ ● 公衆無線LANに偽装した攻撃者 ● あなたの家族 ● あなたのサークルの管理者
  13. 13. NSA ● アメリカ国家安全保障局 ● “エシュロン” などを運用し、アメリカの外 の通信を傍受しているとされる。 ● 電子メール、データ通信、音声通話等、 様々な通信を傍受しているとされる。 ● 私達一般市民の通信に興味はない? o が、大量の一般市民の通信から何か意味を見出しているかもしれない。
  14. 14. プロバイダ 通信がここを通るので、おさえられた時のダメ ージは大きい。
  15. 15. 公衆無線LANに偽装した攻撃者 それっぽい SSID にして電波を飛ばしていたら つないでくる人がいるでしょう。 その通信を監視しておけば何か意味のある情報 がそこを通るかもしれません。
  16. 16. あなたの家族 あなたの家族があなたより十分詳しければ、あ なたがどのようなサイトにアクセスしているか 等の情報を監視しているかもしれません。 家族であれば、あなたが十分な知識を持ってい なければ、あなたの認証情報を盗むことも可能 かもしれません。
  17. 17. あなたのサークルの計算機管理者
  18. 18. あなたのサークルの計算機管理者 ● あなたが自分の認証情報を送信したりする ときに、全く注意を払っていないのなら、 技術的にはそれを盗むことは可能でしょう。 ● ある日突然宇宙からの意思を受信し、攻撃 しようと思っても、あなたが十分注意を払 っていれば、攻撃することは困難となるで しょう。
  19. 19. そもそもつらい。 ● プロバイダ、家族やサークルの管理人が信 頼できないモデルを考えるの辛すぎる。 ● 攻撃の可能性と扱う情報の価値によってど こまで考えるかちゃんと選びましょう!! o 身近な人にパスワード漏れたほうがすぐに表われる ダメージ大きいですよ。 ● ある日突然攻撃されても安全なようにして おきたい。
  20. 20. たとえばありそうなケース
  21. 21. たとえばありそうなケース
  22. 22. ログインしたい。
  23. 23. ログインしたい。
  24. 24. 飛ぶリクエスト
  25. 25. 飛ぶリクエスト
  26. 26. SSLは私達を救う ● 様々な攻撃者がいろいろなところに存在す る インターネットの中で私達を守る技術の 一つ。 ● 気づかないうちにお世話になっている。
  27. 27. SSLとは? ● Secure Sockets Layer の略。 ● 主として TCP 上で安全な通信経路を確保す るプロトコル。 ● 通信相手の認証、通信内容の暗号化、改ざ んの検出などの機能が提供されている。
  28. 28. 証明書 ● X.509 証明書 ● 「私はこの人から信用されています!」を 表す。 ● 信頼してる人を上に辿っていって、自分が信 頼している人が見つかれば、その人は信頼で きるとする。 ● SSLクライアント(ブラウザとか) は信頼でき る人リストを持っている。
  29. 29. 証明書 ● 証明書を発行できるのは特殊な証明書を持 った人のみ。(この証明書を発行できる人、機 関を CA と呼ぶ。) ● CAは全幅の信頼が置け、決して攻撃者でない ことを SSL では仮定している。 ● ⇒ 正しい証明書を持っているなら正しい相 手である ということになっている。
  30. 30. SSL? HTTPS? ● HTTPS は SSL の上で HTTP 通信を行う。 ● SSL は上で HTTP 以外のプロトコルも通す ことができる。 o FTPS(SFTP) o SMTPS o IMAPS o POP over SSL o 等、様々なものが SSL の上を通っている。
  31. 31. SSL の歴史 ● SSL 1.0 o 作成段階で致命的な脆弱性が見つかり実装されず。 ● SSL 2.0 o 攻撃を回避不能な脆弱性が発見され、既に廃止。 ● SSL 3.0 o 1995年に仕様が策定。 o IE 6 で HTTPS の通信ができる最新のSSL
  32. 32. SSL の歴史 ● TLS 1.0 o SSL 3.0 のマイナーチェンジ的立ち位置とされる。 o 4.3 までの Android はここまで。 ● TLS 1.1 o 1.1 に対応しているようなものは大抵 1.2 まで対応 している。 ● TLS 1.2 o 現在の最新版
  33. 33. SSL was dead. ● 2014年10月 ● Google によって発見された CVE-2014- 3566 ● POODLE attack ● SSL 3.0 の仕様に存在する中間者攻撃に対す る脆弱性。 ● SSL 3.0 を無効にするよう勧告が出る。 o SSL 3.0 までした対応していない IE 6 は死んだ。
  34. 34. あたらしい TLS の話 今までこのスライドでも SSL、SSL と言って 来ましたが、SSL は死にました。 これからはきちんと TLS と呼んでいきましょ う。
  35. 35. How it works? TLS がどのように安全な通信経路を確保してい るか、簡単に説明していきます。
  36. 36. TLS の通信の進み方 Client Server
  37. 37. TLS の通信の進み方 Client Server ClientHello
  38. 38. TLS の通信の進み方 Client Server ClientHello ServerHello
  39. 39. TLS の通信の進み方 Client Server ClientHello ServerHello Certificate
  40. 40. TLS の通信の進み方 Client Server ClientHello ServerHello Certificate SrvHelDone
  41. 41. TLS の通信の進み方 Client Server ClientHello ServerHello Certificate ClientKeyEx SrvHelDone
  42. 42. TLS の通信の進み方 Client Server ClientHello ServerHello Certificate ClientKeyEx CCS/Finishd SrvHelDone
  43. 43. TLS の通信の進み方 Client Server ClientHello ServerHello Certificate ClientKeyEx CCS/Finishd CCS/Finishd SrvHelDone
  44. 44. めでたしめでたし これによりクライアントとサーバの間に安全な 通信経路ができたことになった気がします。
  45. 45. めでたしめでたし これによりクライアントとサーバの間に安全な 通信経路ができたことになった気がします。 本当でしょうか。
  46. 46. 私達は 監視されている!!
  47. 47. はい Client Hello, Server Hello, Client KeyExchange で交わされた3つの乱数がもれない限りはさっ きの手順に問題は無いです。
  48. 48. はい Client Hello, Server Hello, Client KeyExchange で交わされた3つの乱数がもれない限りはさっ きの手順に問題は無いです。 2つのHello によって交わされた乱数は特に暗号 化されて送信しているわけではなかったので、 監視者には筒抜けです。
  49. 49. はい 頼みの綱は実質 Client KeyExchange で渡され た乱数だけです。
  50. 50. はい 頼みの綱は実質 Client KeyExchange で渡され た乱数だけです。 この乱数は48バイトの長さを持ちます。
  51. 51. はい 頼みの綱は実質 Client KeyExchange で渡され た乱数だけです。 この乱数は48バイトの長さを持ちます。 全探索とかで頑張るには辛いです。
  52. 52. はい 頼みの綱は実質 Client KeyExchange で渡され た乱数だけです。 この乱数は48バイトの長さを持ちます。 全探索とかで頑張るには辛いです。 じゃあ安全では。
  53. 53. はい サーバの公開鍵で暗号化して送信してるので、 サーバの秘密鍵が安全なうちは安全です。
  54. 54. はい サーバの公開鍵で暗号化して送信してるので、 サーバの秘密鍵が安全なうちは安全です。
  55. 55. はい サーバの公開鍵で暗号化して送信してるので、 サーバの秘密鍵が安全なうちは安全です。 サーバの秘密鍵は時々漏れる。
  56. 56. はい サーバの公開鍵で暗号化して送信してるので、 サーバの秘密鍵が安全なうちは安全です。 サーバの秘密鍵は時々漏れる。 クライアントとサーバの間の通信を全部保存し ておけば、秘密鍵が手に入ったら復号化すれば いい。
  57. 57. 秘密鍵の漏れるとき。 ● 不適切な設定
  58. 58. 秘密鍵の漏れるとき。 ● 不適切な設定 ● 不適切なサーバの廃棄
  59. 59. 秘密鍵の漏れるとき。 ● 不適切な設定 ● 不適切なサーバの廃棄 ● サーバの脆弱性とか
  60. 60. 秘密鍵の漏れるとき。 ● 不適切な設定 ● 不適切なサーバの廃棄 ● サーバの脆弱性とか o Heartbleed !!
  61. 61. heartbleed ● 2014年4月 ● 世界で一番使われている暗号化ライブラリ である OpenSSL に秘密鍵が漏れたりするバ グが二年ほど前からあったことが発表され る。 ● 全然使われていない、SSL ハートビート拡 張なる所にメモリの境界チェック漏れが存 在していた。
  62. 62. heartbleed ● サーバからは正常なリクエストに見えるが、 一回あたり最大65535バイトづつメモリの内 容が漏れる。 ● NSA はこの脆弱性を知っていたが、公表せ ずに、諜報に利用していたとされている。
  63. 63. つらすぎる 秘密鍵が漏れても、過去の通信が復元されたり しなくて、新しい秘密鍵と証明書に変える必要 があるだけにならないものか。
  64. 64. つらすぎる 秘密鍵が漏れても、過去の通信が復元されたり しなくて、新しい秘密鍵と証明書に変える必要 があるだけにならないものか。 ⇒ FS
  65. 65. Forward Secrecy 秘密鍵が漏れても過去の通信を復元できないよ うな性質のこと。 TLS の範囲では以下の二つが該当する。 ● DHE ● ECDHE
  66. 66. ● ディフィー・ヘルマンの頭文字。 ● DHE の E はエフェメラルのEで、永続的な鍵 を持たないとこを表す。 ● お互い何も共通の秘密を持たなくても、暗号 鍵の共有を可能とするアルゴリズム。 DH
  67. 67. 簡単な 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を考えると、どちら
  68. 68. 簡単な DH の説明 ネットワークを通る数は A(= g^a)%p、 B(=g^b)%pのみで、この二つのみから g^ab%p を求めたり、A から a を求めようとすることは、 離散対数問題となり、多項式時間で解く方法は 見つかっていない。
  69. 69. DHE DH をさらに、公開鍵をセッションごとに生成 し、秘密鍵が漏れても、そのセッション以外は 危険とならないようにしたもの。
  70. 70. ECDH ● 楕円曲線ディフィー・ヘルマンの頭文字。 ● ECDHE の E はエフェメラルのEで(ry ● DH と同じようなことを楕円曲線上の演算で やってるらしい。 ● 楕円曲線とか言われてもよくわからない。 ● DH よりも更に解くのが難しい?(DH より優 先して使われる設定となってることが多い)
  71. 71. TLSの通信の進み方(再掲) Client Server ClientHello ServerHello Certificate ClientKeyEx CCS/Finishd CCS/Finishd SrvHelDone
  72. 72. TLSの通信の進み方(DH使用) Client Server ClientHello ServerHello Certificate ClientKeyEx CCS/Finishd CCS/Finishd SrvHelDone SrvKeyEx
  73. 73. めでたしめでたし 最近はどこと TLS で通信しても ECDHE 使っ てる感じですね。
  74. 74. めでたしめでたし こうして我々は監視から逃れて平穏なインター ネットを手に入れたのでした。
  75. 75. で、誰が攻撃してくるの? utxu……。
  76. 76. で、誰が攻撃してくるの? utxu……。 いたずらに脅威の存在を煽るのはよくない。
  77. 77. で、誰が攻撃してくるの? utxu……。 いたずらに脅威の存在を煽るのはよくない。 誰かが攻撃しようと思っても、簡単にできない のはまぁ大切……。
  78. 78. 気をつけよう ● 実は証明書発行局の秘密鍵が漏れていて、 "有効な" 証明書がばんばん刷られている。 ● 未知の脆弱性により秘密鍵が漏れている。 ⇒正直どうしようもない。
  79. 79. 気をつけよう ● そもそも TLS を使っていない。 ⇒ パスワードを入力する時に確認する。 意外と「SSL はこちら」を押さないと HTTP で通信しているサイトがまだある……。
  80. 80. SSLはこちら さすがに最近もうだいぶ減ってきた。
  81. 81. 気をつけよう ● 変な証明書を信頼しない。 ⇒ 証明書をインストールするように言われて も、それがどういう意味を持つのかわからずに するのは大変危険です。
  82. 82. 証明書 証明書をインストールさせようとする怪しいサ イト http://www.e-tax.nta.go.jp/
  83. 83. Superfish 今年2月にレノボのPCに変な証明書がプリイン ストールされた状態で売られていることが発覚。 しかも全てのマシンで同じ秘密鍵を使っており、 解析によりその鍵は既に漏れていて、任意の"信 頼できる証明書"が誰にでも発行できる状態に なっていた。 購入時に変な証明書を入れられるのつらすぎる。
  84. 84. 気をつけよう ● TLS を処理するライブラリとかがバグって る。 ⇒ セキュリティアップデートが来たらすぐか けよう。
  85. 85. goto fail ● iOS 7.0.6 以前に存在したバグ。 ● 証明書の検証するところにバグがあって、不 正な証明書でも受け入れるようになってい た。
  86. 86. 気をつけよう ● そもそも変なホストにアクセスしていた。 ⇒ tvvitter.com の有効な証明書を提示されても、 それは Twitter とは関係ないですよ。
  87. 87. まとまらない ざっと TLS のしくみについて喋ってきました。 とりあえず「SSL はこちら」があればそっち を使う ってことだけでも覚えてってください。
  88. 88. ありがとうございました。
  89. 89. 未使用領域
  90. 90. HTTP2 で日和見暗号…… 日和見暗号(サーバ認証をせずにとりあえず暗 号化して通信)
  91. 91. 俺たちの戦いはこれからだ! ● PGP/GPG ● Tor ● I2P ● VPN Gate

×