SSL で守られる生活

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

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 1.0
o 作成段階で致命的な脆弱性が見つかり実装されず。
● SSL 2.0
o 攻撃を回避不能な脆弱性が発見され、既に廃止。
● SSL 3.0
o 1995年に仕様が策定。
o IE 6 で HTTPS の通信...

SSL の歴史
● TLS 1.0
o SSL 3.0 のマイナーチェンジ的立ち位置とされる。
o 4.3 までの Android はここまで。
● TLS 1.1
o 1.1 に対応しているようなものは大抵 1.2 まで対応
している。
● ...

SSL was dead.
● 2014年10月
● Google によって発見された CVE-2014-
3566
● POODLE attack
● SSL 3.0 の仕様に存在する中間者攻撃に対す
る脆弱性。
● SSL 3.0 を無効に...

あたらしい 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 %...

簡単な DH の説明
ネットワークを通る数は A(= g^a)%p､
B(=g^b)%pのみで､この二つのみから g^ab%p
を求めたり､A から a を求めようとすることは､
離散対数問題となり､多項式時間で解く方法は
見つかっていない｡

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

ECDH
● 楕円曲線ディフィー・ヘルマンの頭文字｡
● ECDHE の E はエフェメラルのEで(ry
● 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

Share Slideshare

LinkedIn
Facebook
Twitter

Embed

Size (px)

Show related Slideshows at end

WordPress Shortcode

Link

Share
Email

Firefox Add-on SDK 入門 by Shoot Morii 17732 views
ECMAScript没proposal追悼式 by 京大マイコンクラブ 17265 views
Pietのエディタを作った話 by 京大マイコンクラブ 16774 views
Topological data analysis by 京大マイコンクラブ 9993 views
プログラムを高速化する話 by 京大マイコンクラブ 267717 views
Gaucheでマクロを書こう by Hideaki Nagamine 6067 views

View on Slideshare

1 of 96 Ad

View on Slideshare

1 of 96 Ad