SlideShare a Scribd company logo
2015年春合宿
SSLで守られる生
活
自己紹介
ID: nona7
KMC二回生
KMCでの主な活動:
● サーバの管理とか
● こたつでだらだら
● Slack の全チャンネルに入ったりとか
このスライドの目的
● いつも身を守ってくれている物のうち、おそ
らく一番身近であるSSLについて紹介します。
● また、その恩恵をきちんと受ける為注意し
ないといけない事を notify します。
注意
● このスライド中に間違いが存在するかもし
れません。
o 自分のセキュリティは自分で確保するしかありませ
ん。
o クリティカルなことは自分で確認して下さい。
● 常に悪意のある攻撃者を想定するのはコス
トが高くつきます。
o 扱っている情報のたいせつさによって適切な判断を
はじまるよ
私達は
監視されている!!
SSL で守られる生活
私達は監視されている
私達は監視されている
● NSA
私達は監視されている
● NSA
● プロバイダ
私達は監視されている
● NSA
● プロバイダ
● 公衆無線LANに偽装した攻撃者
私達は監視されている
● NSA
● プロバイダ
● 公衆無線LANに偽装した攻撃者
● あなたの家族
私達は監視されている
● NSA
● プロバイダ
● 公衆無線LANに偽装した攻撃者
● あなたの家族
● あなたのサークルの管理者
NSA
● アメリカ国家安全保障局
● “エシュロン” などを運用し、アメリカの外
の通信を傍受しているとされる。
● 電子メール、データ通信、音声通話等、
様々な通信を傍受しているとされる。
● 私達一般市民の通信に興味はない?
o が、大量の一般市民の通信から何か意味を見出しているかもしれない。
プロバイダ
通信がここを通るので、おさえられた時のダメ
ージは大きい。
公衆無線LANに偽装した攻撃者
それっぽい SSID にして電波を飛ばしていたら
つないでくる人がいるでしょう。
その通信を監視しておけば何か意味のある情報
がそこを通るかもしれません。
あなたの家族
あなたの家族があなたより十分詳しければ、あ
なたがどのようなサイトにアクセスしているか
等の情報を監視しているかもしれません。
家族であれば、あなたが十分な知識を持ってい
なければ、あなたの認証情報を盗むことも可能
かもしれません。
あなたのサークルの計算機管理者
あなたのサークルの計算機管理者
● あなたが自分の認証情報を送信したりする
ときに、全く注意を払っていないのなら、
技術的にはそれを盗むことは可能でしょう。
● ある日突然宇宙からの意思を受信し、攻撃
しようと思っても、あなたが十分注意を払
っていれば、攻撃することは困難となるで
しょう。
そもそもつらい。
● プロバイダ、家族やサークルの管理人が信
頼できないモデルを考えるの辛すぎる。
● 攻撃の可能性と扱う情報の価値によってど
こまで考えるかちゃんと選びましょう!!
o 身近な人にパスワード漏れたほうがすぐに表われる
ダメージ大きいですよ。
● ある日突然攻撃されても安全なようにして
おきたい。
たとえばありそうなケース
たとえばありそうなケース
ログインしたい。
ログインしたい。
飛ぶリクエスト
飛ぶリクエスト
SSLは私達を救う
● 様々な攻撃者がいろいろなところに存在す
る インターネットの中で私達を守る技術の
一つ。
● 気づかないうちにお世話になっている。
SSLとは?
● Secure Sockets Layer の略。
● 主として TCP 上で安全な通信経路を確保す
るプロトコル。
● 通信相手の認証、通信内容の暗号化、改ざ
んの検出などの機能が提供されている。
SSL で守られる生活
SSL で守られる生活
証明書
● 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.0
o 攻撃を回避不能な脆弱性が発見され、既に廃止。
● SSL 3.0
o 1995年に仕様が策定。
o IE 6 で HTTPS の通信ができる最新のSSL
SSL の歴史
● TLS 1.0
o SSL 3.0 のマイナーチェンジ的立ち位置とされる。
o 4.3 までの Android はここまで。
● TLS 1.1
o 1.1 に対応しているようなものは大抵 1.2 まで対応
している。
● TLS 1.2
o 現在の最新版
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
めでたしめでたし
これによりクライアントとサーバの間に安全な
通信経路ができたことになった気がします。
めでたしめでたし
これによりクライアントとサーバの間に安全な
通信経路ができたことになった気がします。
本当でしょうか。
SSL で守られる生活
私達は
監視されている!!
はい
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を考えると、どちら
簡単な 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 はこちら」があればそっち
を使う ってことだけでも覚えてってください。
ありがとうございました。
SSL で守られる生活
未使用領域
HTTP2 で日和見暗号……
日和見暗号(サーバ認証をせずにとりあえず暗
号化して通信)
俺たちの戦いはこれからだ!
● PGP/GPG
● Tor
● I2P
● VPN Gate

More Related Content

Viewers also liked

Altseed
AltseedAltseed
FM音源をいじれるWebサービスを作った
FM音源をいじれるWebサービスを作ったFM音源をいじれるWebサービスを作った
FM音源をいじれるWebサービスを作った
CHY72
 
中の下のエンジニアを脱出するための仕事術
中の下のエンジニアを脱出するための仕事術中の下のエンジニアを脱出するための仕事術
中の下のエンジニアを脱出するための仕事術
Noriaki Kadota
 
数値解析と物理学
数値解析と物理学数値解析と物理学
数値解析と物理学
すずしめ
 
タイ文字と若干情報科学[修正版]
タイ文字と若干情報科学[修正版]タイ文字と若干情報科学[修正版]
タイ文字と若干情報科学[修正版]
. きぷ
 
SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向
shigeki_ohtsu
 
フォントの選び方・使い方
フォントの選び方・使い方フォントの選び方・使い方
フォントの選び方・使い方
k maztani
 
Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.
Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.
Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.
kiki utagawa
 
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
Kenji Urushima
 
【さくらインターネット】簡単解説 SSLサーバ証明書とは?
【さくらインターネット】簡単解説 SSLサーバ証明書とは?【さくらインターネット】簡単解説 SSLサーバ証明書とは?
【さくらインターネット】簡単解説 SSLサーバ証明書とは?
さくらインターネット株式会社
 
御社WEBサイトの訪問者に安全・安心を提供する方法
御社WEBサイトの訪問者に安全・安心を提供する方法御社WEBサイトの訪問者に安全・安心を提供する方法
御社WEBサイトの訪問者に安全・安心を提供する方法
Netforest Inc.
 
sslcompressionの設定方法および性能測定結果
sslcompressionの設定方法および性能測定結果sslcompressionの設定方法および性能測定結果
sslcompressionの設定方法および性能測定結果
kawarasho
 
デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」
デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」
デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」
JPCERT Coordination Center
 
部の紹介_テンプレート
部の紹介_テンプレート部の紹介_テンプレート
部の紹介_テンプレート
_ uruchan1997
 
ソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったこと
ソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったことソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったこと
ソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったこと
Yoshihito Kuranuki
 
これから始めるssl対策
これから始めるssl対策これから始めるssl対策
これから始めるssl対策
Shohei Kobayashi
 
鈴鹿高専ロボコン 部活紹介と技術紹介
鈴鹿高専ロボコン 部活紹介と技術紹介鈴鹿高専ロボコン 部活紹介と技術紹介
鈴鹿高専ロボコン 部活紹介と技術紹介
東海北陸ロボコン 交流会
 
すごいスライド(Lazy K 紹介)
すごいスライド(Lazy K 紹介)すごいスライド(Lazy K 紹介)
すごいスライド(Lazy K 紹介)
京大 マイコンクラブ
 
SSL/TLS
SSL/TLSSSL/TLS
Ultra piet
Ultra pietUltra piet

Viewers also liked (20)

Altseed
AltseedAltseed
Altseed
 
FM音源をいじれるWebサービスを作った
FM音源をいじれるWebサービスを作ったFM音源をいじれるWebサービスを作った
FM音源をいじれるWebサービスを作った
 
中の下のエンジニアを脱出するための仕事術
中の下のエンジニアを脱出するための仕事術中の下のエンジニアを脱出するための仕事術
中の下のエンジニアを脱出するための仕事術
 
数値解析と物理学
数値解析と物理学数値解析と物理学
数値解析と物理学
 
タイ文字と若干情報科学[修正版]
タイ文字と若干情報科学[修正版]タイ文字と若干情報科学[修正版]
タイ文字と若干情報科学[修正版]
 
SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向SSL/TLSの基礎と最新動向
SSL/TLSの基礎と最新動向
 
フォントの選び方・使い方
フォントの選び方・使い方フォントの選び方・使い方
フォントの選び方・使い方
 
Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.
Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.
Pythonの処理系はどのように実装され,どのように動いているのか? 我々はその実態を調査すべくアマゾンへと飛んだ.
 
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
いろいろなSSL/TLS設定ガイドライン (JNSA電子署名WG 実世界の暗号・認証技術勉強会資料)
 
【さくらインターネット】簡単解説 SSLサーバ証明書とは?
【さくらインターネット】簡単解説 SSLサーバ証明書とは?【さくらインターネット】簡単解説 SSLサーバ証明書とは?
【さくらインターネット】簡単解説 SSLサーバ証明書とは?
 
御社WEBサイトの訪問者に安全・安心を提供する方法
御社WEBサイトの訪問者に安全・安心を提供する方法御社WEBサイトの訪問者に安全・安心を提供する方法
御社WEBサイトの訪問者に安全・安心を提供する方法
 
sslcompressionの設定方法および性能測定結果
sslcompressionの設定方法および性能測定結果sslcompressionの設定方法および性能測定結果
sslcompressionの設定方法および性能測定結果
 
デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」
デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」
デブサミ2015 事例から学ぶAndroidアプリのセキュアコーディング「SSL/TLS証明書検証の現状と対策」
 
部の紹介_テンプレート
部の紹介_テンプレート部の紹介_テンプレート
部の紹介_テンプレート
 
ソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったこと
ソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったことソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったこと
ソニックガーデン「部活」制度の紹介 〜 イノベーションを起こすために必要だったこと
 
これから始めるssl対策
これから始めるssl対策これから始めるssl対策
これから始めるssl対策
 
鈴鹿高専ロボコン 部活紹介と技術紹介
鈴鹿高専ロボコン 部活紹介と技術紹介鈴鹿高専ロボコン 部活紹介と技術紹介
鈴鹿高専ロボコン 部活紹介と技術紹介
 
すごいスライド(Lazy K 紹介)
すごいスライド(Lazy K 紹介)すごいスライド(Lazy K 紹介)
すごいスライド(Lazy K 紹介)
 
SSL/TLS
SSL/TLSSSL/TLS
SSL/TLS
 
Ultra piet
Ultra pietUltra piet
Ultra piet
 

More from 京大 マイコンクラブ

テキストファイルを読む💪 第1回
テキストファイルを読む💪  第1回テキストファイルを読む💪  第1回
テキストファイルを読む💪 第1回
京大 マイコンクラブ
 
かわいくなろうとしたら語彙力が下がった話
かわいくなろうとしたら語彙力が下がった話かわいくなろうとしたら語彙力が下がった話
かわいくなろうとしたら語彙力が下がった話
京大 マイコンクラブ
 
Common Lisp入門
Common Lisp入門Common Lisp入門
Common Lisp入門
京大 マイコンクラブ
 
多倍長整数の乗算と高速フーリエ変換
多倍長整数の乗算と高速フーリエ変換多倍長整数の乗算と高速フーリエ変換
多倍長整数の乗算と高速フーリエ変換
京大 マイコンクラブ
 
つくってあそぼ ラムダ計算インタプリタ
つくってあそぼ ラムダ計算インタプリタつくってあそぼ ラムダ計算インタプリタ
つくってあそぼ ラムダ計算インタプリタ
京大 マイコンクラブ
 
Geometry with Unity
Geometry with UnityGeometry with Unity
Geometry with Unity
京大 マイコンクラブ
 
セミコロンレスc++
セミコロンレスc++セミコロンレスc++
セミコロンレスc++
京大 マイコンクラブ
 
エンジニアと健康
エンジニアと健康エンジニアと健康
エンジニアと健康
京大 マイコンクラブ
 
女の子になれなかった人のために
女の子になれなかった人のために女の子になれなかった人のために
女の子になれなかった人のために
京大 マイコンクラブ
 
Pietで競プロしよう
Pietで競プロしようPietで競プロしよう
Pietで競プロしよう
京大 マイコンクラブ
 
もし太陽のコアがIntelCoreだったら
もし太陽のコアがIntelCoreだったらもし太陽のコアがIntelCoreだったら
もし太陽のコアがIntelCoreだったら
京大 マイコンクラブ
 
C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?
C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?
C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?
京大 マイコンクラブ
 
プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜
京大 マイコンクラブ
 
ドット絵でプログラミング!難解言語『Piet』勉強会
ドット絵でプログラミング!難解言語『Piet』勉強会ドット絵でプログラミング!難解言語『Piet』勉強会
ドット絵でプログラミング!難解言語『Piet』勉強会
京大 マイコンクラブ
 
No SSH (@nojima; KMC関東例会)
No SSH (@nojima; KMC関東例会)No SSH (@nojima; KMC関東例会)
No SSH (@nojima; KMC関東例会)
京大 マイコンクラブ
 
DTM練習会2017第1.5回 「伴奏の付け方」
DTM練習会2017第1.5回 「伴奏の付け方」DTM練習会2017第1.5回 「伴奏の付け方」
DTM練習会2017第1.5回 「伴奏の付け方」
京大 マイコンクラブ
 
hideya流 テストプレイ観察術
hideya流 テストプレイ観察術hideya流 テストプレイ観察術
hideya流 テストプレイ観察術
京大 マイコンクラブ
 
C#でゲームを作る2016 第8回
C#でゲームを作る2016 第8回C#でゲームを作る2016 第8回
C#でゲームを作る2016 第8回
京大 マイコンクラブ
 
C#でゲームを作る2016 第7回
C#でゲームを作る2016 第7回C#でゲームを作る2016 第7回
C#でゲームを作る2016 第7回
京大 マイコンクラブ
 
C#でゲームを作る2016 第5回
C#でゲームを作る2016 第5回C#でゲームを作る2016 第5回
C#でゲームを作る2016 第5回
京大 マイコンクラブ
 

More from 京大 マイコンクラブ (20)

テキストファイルを読む💪 第1回
テキストファイルを読む💪  第1回テキストファイルを読む💪  第1回
テキストファイルを読む💪 第1回
 
かわいくなろうとしたら語彙力が下がった話
かわいくなろうとしたら語彙力が下がった話かわいくなろうとしたら語彙力が下がった話
かわいくなろうとしたら語彙力が下がった話
 
Common Lisp入門
Common Lisp入門Common Lisp入門
Common Lisp入門
 
多倍長整数の乗算と高速フーリエ変換
多倍長整数の乗算と高速フーリエ変換多倍長整数の乗算と高速フーリエ変換
多倍長整数の乗算と高速フーリエ変換
 
つくってあそぼ ラムダ計算インタプリタ
つくってあそぼ ラムダ計算インタプリタつくってあそぼ ラムダ計算インタプリタ
つくってあそぼ ラムダ計算インタプリタ
 
Geometry with Unity
Geometry with UnityGeometry with Unity
Geometry with Unity
 
セミコロンレスc++
セミコロンレスc++セミコロンレスc++
セミコロンレスc++
 
エンジニアと健康
エンジニアと健康エンジニアと健康
エンジニアと健康
 
女の子になれなかった人のために
女の子になれなかった人のために女の子になれなかった人のために
女の子になれなかった人のために
 
Pietで競プロしよう
Pietで競プロしようPietで競プロしよう
Pietで競プロしよう
 
もし太陽のコアがIntelCoreだったら
もし太陽のコアがIntelCoreだったらもし太陽のコアがIntelCoreだったら
もし太陽のコアがIntelCoreだったら
 
C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?
C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?
C# ゲームプログラミングはホントにメモリのことに無頓着でいいの?
 
プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜
 
ドット絵でプログラミング!難解言語『Piet』勉強会
ドット絵でプログラミング!難解言語『Piet』勉強会ドット絵でプログラミング!難解言語『Piet』勉強会
ドット絵でプログラミング!難解言語『Piet』勉強会
 
No SSH (@nojima; KMC関東例会)
No SSH (@nojima; KMC関東例会)No SSH (@nojima; KMC関東例会)
No SSH (@nojima; KMC関東例会)
 
DTM練習会2017第1.5回 「伴奏の付け方」
DTM練習会2017第1.5回 「伴奏の付け方」DTM練習会2017第1.5回 「伴奏の付け方」
DTM練習会2017第1.5回 「伴奏の付け方」
 
hideya流 テストプレイ観察術
hideya流 テストプレイ観察術hideya流 テストプレイ観察術
hideya流 テストプレイ観察術
 
C#でゲームを作る2016 第8回
C#でゲームを作る2016 第8回C#でゲームを作る2016 第8回
C#でゲームを作る2016 第8回
 
C#でゲームを作る2016 第7回
C#でゲームを作る2016 第7回C#でゲームを作る2016 第7回
C#でゲームを作る2016 第7回
 
C#でゲームを作る2016 第5回
C#でゲームを作る2016 第5回C#でゲームを作る2016 第5回
C#でゲームを作る2016 第5回
 

SSL で守られる生活

Editor's Notes

  1. ring に入れてほしいパッケージがあったりしたら言ってね。 変なイベントがあったら顔をつっこんだり。
  2. 魑魅魍魎の跋扈するインターネットにおいて、少しでも安全な生活を送っていくことを目指しましょう。
  3. 何でもかんでも最大のセキュリティを確保しようとするのは、コストが高すぎます。 ……ことはわかっているのですが、なかなかそれも難しくて、どうしても Wikipedia の記事ページに HTTP で接続してしまうと、やってしまった と思ったりしてしまいます。私は、HTTP と HTTPS で同じコンテンツを配信しているサイトには HTTPS で接続しないと気がすまないです。 少し前までは Twitter や Google 検索, youtube や flickr はデフォルトでは SSL で通信しないようになっていましたが、現在はそれらはもう SSL を強制するようになっています。 Wikipedia もログインしていればログイン中ずっと SSL を設定で強制できるので、だいぶマシです。 Amazon はひどくて、商品ページには名前が載っているのに、HTTP を使って送信してくる。
  4. 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.
  5. 私たちは、様々なところから監視を受けています。 例えば
  6. アメリカ国家安全保障局
  7. 他にもいろいろな攻撃者が存在していると思います。
  8. image: PD https://commons.wikimedia.org/wiki/File:National_Security_Agency.svg
  9. CG_guest とか、001Softbank とかそういう名前にして鍵開けておけばだれかがまぁつないでくるでしょう。 #大学内で鍵のかかっていない MIAKO という SSID の電波が飛んでいれば、接続してしまうでしょう。 #最も、MIAKO の場合は VPN を通さないと通信できない設定になっているので、あまり問題にはならないでしょうが。
  10. 監視されてる監視されてる って言うけれど、具体的にどういうふうに攻撃を受ける可能性があるのかを適当な例として上げてみます。
  11. 某イラスト投稿サイトP のトップページに普通にアクセス
  12. あなたのアドレスバーには http://www.pixiv.net と書かれていそう。 とかいいつつ chrome では http の時は省略されるので、 www.pixiv.net としか出ない。
  13. ここからログインする。
  14. ログインボタンを押す。 このログインボタンは /login.php へのPOST を投げるものになっているので
  15. よく見る
  16. 今の URI は http://www.pixiv.net だったので、/login.php は http://www.pixiv.net/login.php となり、そこに生の HTTP でPOST リクエストを投げる。 その際通信は暗号化されないので、途中の経路にいる人には pixiv_id と pass がわかる。 さっきの例だと、悪意ある無線AP 提供者や、あなたの家族、あなたのサークルの管理者はあなたの通信の経路に入り込むことは容易である。 DNS を偽装して(例の三者はこれもまた容易にできる)、中間者攻撃したり、DHCP で配るデフォルトルートを変なところに向かせたりすることによって実現できる。 私がこっそり DNS に変なフィールドを挿入しても、一月ぐらいなら他の管理者に気づかれないような気がする。多分。
  17. さっきの例で、DNS に変なレコードを入れたりして中間者攻撃を試みても、有効な証明書を用意できないので、攻撃は失敗する。 証明書が何なのかは後述。 ブラウザが怒ってくれる。
  18. Chrome
  19. firefox
  20. 大抵のクライアントはデフォルトでベリサイン等を信頼できる人リストに入れているが、ユーザが自分で追加することもできる。 RSA を使って署名されている。 証明書には、RSA の公開鍵が入っています。 証明をした側の秘密鍵により署名されており、署名した側の秘密鍵が安全に保管されているなら改ざん、偽造は不可能です。 RSA による暗号化は自己同型で、暗号化と復号化は逆関数となっているので、平文を秘密鍵で復号したものを公開鍵で暗号化すれば元の文と一致し、この性質から署名として使える。
  21. ircs...
  22. TLS 1.3 が現在策定中。
  23. 下向きに通信が、時間が進んでいく。 クライアントをブラウザで、サーバを HTTPS で Web ページを配信してるサーバだと考えてもいいです。 お互い相手のことを何も知らないので、最初は全く暗号化されていない通信を行います。
  24. クライアントがサーバに接続を開始する際に、まず Client Hello メッセージを送信します。 このメッセージには、暗号通信を行うための暗号化キーを作るためのハッシュに通すためのシードとして使う乱数と、 クライアントが受け入れられる鍵交換アルゴリズム、暗号化アルゴリズムとハッシュアルゴリズムの組み合わせの一覧、セッション再開が有効になっていれば、セッションID、SNI拡張が有効になっていれば(最近のまともなTLS対応ソフトなら有効になっています)、クライアント側がアクセスしているHost名などが入っています。 この SNI 拡張は HTTP/1.1 の Host ヘッダと同じような役目で、一つのIPアドレスで複数のTLSの通信をホストしたりできるようになっています。 この後にサーバ側から証明書が送られてくるのですが、そこに Host 名の情報が埋め込まれており、適切な証明書をサーバが返すことがこれによってできます。
  25. クライアントからのメッセージに対して、サーバ側は server hello メッセージを返します。 client hello と同じように、暗号化通信を行うキーを作るシードとしてサーバ側で生成した乱数と、 クライアントが提示してきたアルゴリズムの組からサーバが一番いいと思うようなものを一つ選び、これをつかうとクライアント側に提示します。 まだ暗号化通信は開始されていないので、さっきクライアントから送られてきたシードと、サーバが今返したものは、共に途中に通信を覗き見る人がいる場合筒抜けなことに注意してください。 ここでは鍵交換のアルゴリズムで RSA を使うものが選ばれたと仮定して話をススメます。
  26. サーバは証明書を提示します。 クライアントは、受け取った証明書を信頼できるかどうかを証明書の発行者をさかのぼってゆき、自分の信頼できるとしている証明書が出てくるか確認します。 それと同時に、証明書埋め込まれている名前(完全修飾ドメイン名、URI のホスト名と思って良いです)と、通信相手の名乗る名前が同じかどうか確認します。 証明書が信頼できなかった場合、または通信相手の名乗る名前と証明書に書いてある名前が一致しなかった場合、ここでクライアントは接続を破棄します。 正しい証明書を持てるのは本人だけであるということになっているので、証明書が問題なかった場合、通信相手は正しい相手である事がわかります。 これにより、中間者攻撃などのおそれは無いということが確認できます(中間者は正規の証明書を手に入れることができないため)。
  27. Server Hello Done メッセージをサーバは送信します。 後述する他の鍵交換アルゴリズムを使う場合や、クライアント証明書を使う場合、サーバの証明書を提示してからこのメッセージを送るまでの間に他のメッセージが入ります。 クライアント証明書とは、SSH での公開鍵認証のようなもので、パスワードでクライアントを認証する代わりに、クライアントにも証明書を提示してもらい、それによって認証を行ったりするためのものです。 KMC の内部ページもパスワードでログインするの面倒だし、クライアント証明書で入れるようにしたいなぁとは思ってるのですが、設定がめんどくさいのでなかなかそうなっていません。
  28. 今クライアントとサーバは RSA を使い鍵交換をしていると仮定していました。 クライアント側は、更に乱数を生成し、それをサーバの証明書に入っているサーバの公開鍵で暗号化し、 サーバに送信します。 これは RSA による暗号化が施されているので、ClientHello と ServerHello で交換された乱数と異なり、 クライアントとサーバのみが知っている情報となります。 この乱数と、Hello メッセージで交換された2つの乱数を合わせて(今までの手順より、この3つの乱数は、クライアント側とサーバ側で共有されています)、MD5 と SHA-1 を合わせたようなハッシュ関数に通し、そこからハッシュ関数を繰り返し用いることで任意有限長のビット列を作り、それと目的の通信内容との XOR をとることにより共通鍵暗号を行います。
  29. 以上で暗号化の準備は整ったので、クライアントは、 Change Cipher Spec メッセージを送信し、これ以降の通信は暗号化通信に切り替えることを宣言し、 Finished メッセージを送信し、きちんと鍵交換が成功しているかどうかの確認を行います。
  30. サーバ側もChange Cipher Specメッセージと、Finishedメッセージを送信し、お互いに鍵交換が成功しているかを確認できたら、 合意した暗号化方式での暗号通信を開始します。(正確には、Finished メッセージは、合意した形式で暗号化されている。) これが HTTPS の通信であれば、普通の HTTP の通信にさっき作った任意有限長のビット列との XOR をかけたものがやりとりされることになります。 Cl hello で有効なセッションID があるときは、サーバはServer Hello に適切な返答を入れ、即座に ChangeCipherSpec メッセージを送信する。 これにより、RSA とかの重い処理を省略できるので、大分楽になる。
  31. 何が問題でしょうか?
  32. 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.
  33. 48 以上 のまちがい
  34. 間違えて Web サーバから見えるようになっちゃうとか
  35. 捨てられたサーバからTLSの秘密鍵を盗む とかを NSA は行っているとされているらしい。
  36. image: CC0 https://commons.wikimedia.org/wiki/File:Heartbleed.svg
  37. TLS において、 FS の性質を持つものはすべて PFS だから、パーフェクトである性質の説明は飛ばします。 # FS + # 鍵合意のために公開可能な、ランダムな値を使う。 # 鍵合意の過程で決定的なアルゴリズムを一切使わない。 # でPFSになる。
  38. E RSA 暗号強度の低い、輸出用暗号で選べる鍵交換方式の一つ。 DH は高速に鍵を作れるが、RSA は辛い。
  39. 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 で鍵交換したときと同様に暗号通信する。
  40. 以下、適当に安全性が崩れたりしそうな感じの注意をするべきなこととかです。
  41. きちんとさっきの仮定がすべて成り立っていれば、一応安心できるように思うけれども、そうでない時はそうでない。
  42. どうでもいいようなサイトだったらまぁいいんだけど、Pixiv とか Booth に連携ログインできるしクレジットカード登録してるしどうなんだ……。 って感じする。 まともなサイトだとさすがにもう