ssl で守られる生活

2015年春合宿

SSLで守られる生活

自己紹介

ID: nona7

KMC二回生KMCでの主な活動:

● サーバの管理とか● こたつでだらだら● Slack の全チャンネルに入ったりとか

このスライドの目的

● いつも身を守ってくれている物のうち､おそ

らく一番身近であるSSLについて紹介します。

● また、その恩恵をきちんと受ける為注意し

ないといけない事を notify します。

注意

● このスライド中に間違いが存在するかもしれません。o 自分のセキュリティは自分で確保するしかありません。

o クリティカルなことは自分で確認して下さい。

● 常に悪意のある攻撃者を想定するのはコストが高くつきます。o 扱っている情報のたいせつさによって適切な判断をしましょう。

はじまるよ

私達は監視されている！！

私達は監視されている

私達は監視されている

● NSA

私達は監視されている

● NSA

● プロバイダ

私達は監視されている

● NSA

● プロバイダ● 公衆無線LANに偽装した攻撃者

私達は監視されている

● NSA

● プロバイダ● 公衆無線LANに偽装した攻撃者● あなたの家族

私達は監視されている

● NSA

● プロバイダ● 公衆無線LANに偽装した攻撃者● あなたの家族● あなたのサークルの管理者

NSA

● アメリカ国家安全保障局● “エシュロン”などを運用し、アメリカの外の通信を傍受しているとされる。

● 電子メール、データ通信、音声通話等、様々な通信を傍受しているとされる。

● 私達一般市民の通信に興味はない？o が、大量の一般市民の通信から何か意味を見出しているかもしれない。

プロバイダ

通信がここを通るので、おさえられた時のダメージは大きい。

公衆無線LANに偽装した攻撃者

それっぽい SSID にして電波を飛ばしていたらつないでくる人がいるでしょう。その通信を監視しておけば何か意味のある情報がそこを通るかもしれません。

あなたの家族

あなたの家族があなたより十分詳しければ、あなたがどのようなサイトにアクセスしているか等の情報を監視しているかもしれません。家族であれば、あなたが十分な知識を持っていなければ、あなたの認証情報を盗むことも可能かもしれません。

あなたのサークルの計算機管理者

あなたのサークルの計算機管理者

● あなたが自分の認証情報を送信したりするときに、全く注意を払っていないのなら、技術的にはそれを盗むことは可能でしょう。

● ある日突然宇宙からの意思を受信し、攻撃しようと思っても、あなたが十分注意を払っていれば、攻撃することは困難となるでしょう。

そもそもつらい。

● プロバイダ、家族やサークルの管理人が信頼できないモデルを考えるの辛すぎる。

● 攻撃の可能性と扱う情報の価値によってどこまで考えるかちゃんと選びましょう！！o 身近な人にパスワード漏れたほうがすぐに表われるダメージ大きいですよ。

● ある日突然攻撃されても安全なようにしておきたい。

たとえばありそうなケース

たとえばありそうなケース

ログインしたい。

ログインしたい。

飛ぶリクエスト

飛ぶリクエスト

SSLは私達を救う

● 様々な攻撃者がいろいろなところに存在する インターネットの中で私達を守る技術の一つ。

● 気づかないうちにお世話になっている｡

SSLとは？

● Secure Sockets Layer の略。● 主として TCP 上で安全な通信経路を確保するプロトコル。

● 通信相手の認証、通信内容の暗号化、改ざんの検出などの機能が提供されている。

証明書

● X.509 証明書● 「私はこの人から信用されています！」を表す｡

● 信頼してる人を上に辿っていって､自分が信頼している人が見つかれば､その人は信頼できるとする｡

● SSLクライアント(ブラウザとか) は信頼できる人リストを持っている｡

証明書

● 証明書を発行できるのは特殊な証明書を持

った人のみ｡(この証明書を発行できる人、機

関を CA と呼ぶ。)

● CAは全幅の信頼が置け､決して攻撃者でないことを SSL では仮定している｡

● ⇒正しい証明書を持っているなら正しい相手であるということになっている｡

SSL？ HTTPS？

● HTTPS は SSL の上で HTTP 通信を行う。● SSL は上で HTTP 以外のプロトコルも通すことができる。o FTPS(SFTP)

o SMTPS

o IMAPS

o POP over SSL

o 等、様々なものが SSL の上を通っている。

SSL の歴史

● SSL 1.0 o 作成段階で致命的な脆弱性が見つかり実装されず。

● SSL 2.0o 攻撃を回避不能な脆弱性が発見され、既に廃止。

● SSL 3.0o 1995年に仕様が策定。o IE 6 で HTTPS の通信ができる最新のSSL

SSL の歴史

● TLS 1.0o SSL 3.0 のマイナーチェンジ的立ち位置とされる。o 4.3 までの Android はここまで。

● TLS 1.1o 1.1 に対応しているようなものは大抵 1.2 まで対応している。

● TLS 1.2o 現在の最新版

SSL was dead.

● 2014年10月● Google によって発見された CVE-2014-

3566

● POODLE attack

● SSL 3.0 の仕様に存在する中間者攻撃に対する脆弱性。

● SSL 3.0 を無効にするよう勧告が出る。o SSL 3.0 までした対応していない IE 6 は死んだ。

あたらしい TLS の話

今までこのスライドでも SSL、SSL と言って来ましたが、SSL は死にました。これからはきちんと TLS と呼んでいきましょう。

How it works?

TLS がどのように安全な通信経路を確保しているか、簡単に説明していきます。

TLS の通信の進み方Client Server

TLS の通信の進み方Client Server

ClientHello

TLS の通信の進み方Client Server

ClientHello

ServerHello

TLS の通信の進み方Client Server

ClientHello

ServerHello

Certificate

TLS の通信の進み方Client Server

ClientHello

ServerHello

Certificate

SrvHelDone

TLS の通信の進み方Client Server

ClientHello

ServerHello

Certificate

ClientKeyEx

SrvHelDone

TLS の通信の進み方Client Server

ClientHello

ServerHello

Certificate

ClientKeyEx

CCS/Finishd

SrvHelDone

TLS の通信の進み方Client Server

ClientHello

ServerHello

Certificate

ClientKeyEx

CCS/Finishd

CCS/Finishd

SrvHelDone

めでたしめでたし

これによりクライアントとサーバの間に安全な通信経路ができたことになった気がします｡

めでたしめでたし

これによりクライアントとサーバの間に安全な通信経路ができたことになった気がします｡

本当でしょうか｡

私達は監視されている！！

はい

Client Hello, Server Hello, Client KeyExchange

で交わされた3つの乱数がもれない限りはさっきの手順に問題は無いです｡

はい

Client Hello, Server Hello, Client KeyExchange

で交わされた3つの乱数がもれない限りはさっきの手順に問題は無いです｡

2つのHello によって交わされた乱数は特に暗号化されて送信しているわけではなかったので､監視者には筒抜けです｡

はい

頼みの綱は実質 Client KeyExchange で渡された乱数だけです｡

はい

頼みの綱は実質 Client KeyExchange で渡された乱数だけです｡この乱数は48バイトの長さを持ちます｡

はい

頼みの綱は実質 Client KeyExchange で渡された乱数だけです｡この乱数は48バイトの長さを持ちます｡全探索とかで頑張るには辛いです｡

はい

頼みの綱は実質 Client KeyExchange で渡された乱数だけです｡この乱数は48バイトの長さを持ちます｡全探索とかで頑張るには辛いです｡じゃあ安全では｡

はい

サーバの公開鍵で暗号化して送信してるので､サーバの秘密鍵が安全なうちは安全です｡

はい

サーバの公開鍵で暗号化して送信してるので､サーバの秘密鍵が安全なうちは安全です｡

はい

サーバの公開鍵で暗号化して送信してるので､サーバの秘密鍵が安全なうちは安全です｡

サーバの秘密鍵は時々漏れる｡

はい

サーバの公開鍵で暗号化して送信してるので､サーバの秘密鍵が安全なうちは安全です｡

サーバの秘密鍵は時々漏れる｡クライアントとサーバの間の通信を全部保存しておけば､秘密鍵が手に入ったら復号化すればいい｡

秘密鍵の漏れるとき｡

● 不適切な設定

秘密鍵の漏れるとき｡

● 不適切な設定● 不適切なサーバの廃棄

秘密鍵の漏れるとき｡

● 不適切な設定● 不適切なサーバの廃棄● サーバの脆弱性とか

秘密鍵の漏れるとき｡

● 不適切な設定● 不適切なサーバの廃棄● サーバの脆弱性とか

o Heartbleed ！！

heartbleed

● 2014年4月● 世界で一番使われている暗号化ライブラリである OpenSSL に秘密鍵が漏れたりするバグが二年ほど前からあったことが発表される｡

● 全然使われていない、SSL ハートビート拡張なる所にメモリの境界チェック漏れが存在していた。

heartbleed

● サーバからは正常なリクエストに見えるが、一回あたり最大65535バイトづつメモリの内容が漏れる。

● NSA はこの脆弱性を知っていたが、公表せずに、諜報に利用していたとされている。

つらすぎる

秘密鍵が漏れても､過去の通信が復元されたりしなくて､新しい秘密鍵と証明書に変える必要があるだけにならないものか｡

つらすぎる

秘密鍵が漏れても､過去の通信が復元されたりしなくて､新しい秘密鍵と証明書に変える必要があるだけにならないものか｡

⇒ FS

Forward Secrecy

秘密鍵が漏れても過去の通信を復元できないような性質のこと｡

TLS の範囲では以下の二つが該当する｡● DHE

● ECDHE

● ディフィー・ヘルマンの頭文字｡● DHE の E はエフェメラルのEで､永続的な鍵を持たないとこを表す｡

● お互い何も共通の秘密を持たなくても､暗号鍵の共有を可能とするアルゴリズム｡

DH

簡単な 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を考えると､どちらもg^ab % p となっている｡

簡単な DH の説明

ネットワークを通る数は A(= g^a)%p､B(=g^b)%pのみで､この二つのみから g^ab%p

を求めたり､A から a を求めようとすることは､離散対数問題となり､多項式時間で解く方法は見つかっていない｡

DHE

DH をさらに、公開鍵をセッションごとに生成し、秘密鍵が漏れても、そのセッション以外は危険とならないようにしたもの。

ECDH

● 楕円曲線ディフィー・ヘルマンの頭文字｡● ECDHE の E はエフェメラルのEで(ry

● DH と同じようなことを楕円曲線上の演算でやってるらしい｡

● 楕円曲線とか言われてもよくわからない｡● DH よりも更に解くのが難しい？(DH より優先して使われる設定となってることが多い)

TLSの通信の進み方(再掲)Client Server

ClientHello

ServerHello

Certificate

ClientKeyEx

CCS/Finishd

CCS/Finishd

SrvHelDone

TLSの通信の進み方(DH使用)Client Server

ClientHello

ServerHello

Certificate

ClientKeyEx

CCS/Finishd

CCS/Finishd

SrvHelDone

SrvKeyEx

めでたしめでたし

最近はどこと TLS で通信しても ECDHE 使ってる感じですね｡

めでたしめでたし

こうして我々は監視から逃れて平穏なインターネットを手に入れたのでした｡

で、誰が攻撃してくるの？

utxu……。

で、誰が攻撃してくるの？

utxu……。

いたずらに脅威の存在を煽るのはよくない。

で、誰が攻撃してくるの？

utxu……。

いたずらに脅威の存在を煽るのはよくない。

誰かが攻撃しようと思っても、簡単にできない

のはまぁ大切……。

気をつけよう

● 実は証明書発行局の秘密鍵が漏れていて､"有効な" 証明書がばんばん刷られている｡

● 未知の脆弱性により秘密鍵が漏れている｡⇒正直どうしようもない｡

気をつけよう

● そもそも TLS を使っていない｡⇒パスワードを入力する時に確認する｡

意外と「SSL はこちら」を押さないと HTTP

で通信しているサイトがまだある……｡

SSLはこちら

さすがに最近もうだいぶ減ってきた｡

気をつけよう

● 変な証明書を信頼しない｡

⇒証明書をインストールするように言われても､それがどういう意味を持つのかわからずにするのは大変危険です｡

証明書

証明書をインストールさせようとする怪しいサイト

http://www.e-tax.nta.go.jp/

Superfish

今年2月にレノボのPCに変な証明書がプリインストールされた状態で売られていることが発覚｡しかも全てのマシンで同じ秘密鍵を使っており､解析によりその鍵は既に漏れていて､任意の"信頼できる証明書"が誰にでも発行できる状態になっていた｡購入時に変な証明書を入れられるのつらすぎる｡

気をつけよう

● TLS を処理するライブラリとかがバグってる｡

⇒セキュリティアップデートが来たらすぐかけよう｡

goto fail

● iOS 7.0.6 以前に存在したバグ｡● 証明書の検証するところにバグがあって､不正な証明書でも受け入れるようになっていた｡

気をつけよう

● そもそも変なホストにアクセスしていた｡

⇒ tvvitter.com の有効な証明書を提示されても､それは Twitter とは関係ないですよ｡

まとまらない

ざっと TLS のしくみについて喋ってきました｡

とりあえず「SSL はこちら」があればそっちを使うってことだけでも覚えてってください｡

ありがとうございました｡

未使用領域

HTTP2 で日和見暗号……

日和見暗号(サーバ認証をせずにとりあえず暗号化して通信)

俺たちの戦いはこれからだ！

● PGP/GPG

● Tor

● I2P

● VPN Gate