Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SSL のハンドシェイクについて
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
firedial
May 28, 2020
Technology
530
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SSL のハンドシェイクについて
firedial
May 28, 2020
More Decks by firedial
See All by firedial
家計簿管理システム Midas について / balance system Midas
firedial
1
290
Other Decks in Technology
See All in Technology
Bill One 開発エンジニア 紹介資料
sansan33
PRO
7
20k
Service Connect 上のサービスに ECS Service の外側から到達できなかった話
ota1022
1
270
今こそ聞きたいソフトウェア設計 ドメイン駆動設計再入門
masuda220
PRO
17
7.6k
【AG-UI × A2UI × MCP Apps】Generative UIをやさしく解説する
nrinetcom
PRO
1
140
【CEDEC2026】Creative Approaches to Localizing the Dialects and Unique Speech of Umamusume: Pretty Derby Characters in English
cygames
PRO
3
25k
【GCC2026】大規模言語モデルを活用した内製検索サービスの社内展開や業務活用
bandainamcostudios
PRO
0
240
まちスペース®とデジタルツインと「まちづくり」
hiro_ogi
0
130
コーチングの奥義 何もしないテクニック
jinwatanabe
0
110
自宅NWにISR4331を導入してみた話
okaits
0
110
同じWAFが、攻撃の“形”は弾く── 正当な“形”の不正は通す
kuroneko13
0
240
DatadogのBits Chatが開発組織にもたらしたもの / What Bits Chat Has Brought Us
sms_tech
1
280
生成 AI の基礎 〜 サンプル実装で学ぶ基本原理
enakai00
7
4.4k
Featured
See All Featured
A better future with KSS
kneath
240
18k
The World Runs on Bad Software
bkeepers
PRO
72
12k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
490
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
2.4k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
490
Un-Boring Meetings
codingconduct
0
390
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Into the Great Unknown - MozCon
thekraken
41
2.7k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
340
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
エンジニアに許された特別な時間の終わり
watany
108
250k
Transcript
SSL のハンドシェイクについて 〜絶対に守りたい秘密がある〜
自己紹介
自己紹介 • 名前: firedial • 生後: 10075日目 • 出身: 滋賀県東近江市
• 仕事: サーバーサイドエンジニア(PHP のはずだが最近は Vue.js と TypeScript を触っている) • 趣味: ビリヤード(自粛中)、都内散策(自粛中)、カメラ(自粛 中)、雀魂
今日のお話 • https 通信使われている技術ってなんだろう?? ◦ SSL というプロトコルが使われている!! ▪ どのように安全性が確保されているのだろうか? •
気になって調べてみた
前提知識
説明するに当たって必要な知識 • 共通鍵暗号方式 • 公開鍵暗号方式 • ハイブリッド暗号方式 • ハッシュ関数 •
メッセージダイジェスト • SSL/TLS
共通鍵暗号方式 • 秘密を共有したい 2 者間で同じ鍵を使う方式 • 種類: DES, 3DES, AES,
RC4 • 長所: 公開鍵暗号方式と比べて処理が早い • 短所: 通信する相手ごとに鍵を準備しないといけない
公開鍵暗号方式 • 暗号化する鍵と復号する鍵が異なる方式 • 種類: 後述 • 長所: 公開鍵と秘密鍵を 1
組作成すれば使いまわせる • 短所: 共通鍵暗号方式に比べて処理が遅い
公開鍵暗号方式 • 公開鍵暗号の目的は暗号化、鍵交換、署名の 3 つがある • 鍵交換 ◦ DH, RSA,
楕円曲線暗号 • 暗号化 ◦ RSA, 楕円曲線暗号 • 署名 ◦ RSA, DSA, 楕円曲線暗号 ※楕円曲線暗号は特定のアルゴリズムを指すものではない
ハイブリッド暗号 • 共通鍵暗号と公開鍵暗号両方使う方式 • 公開鍵暗号は共通鍵暗号の共通鍵を共有するために使う • 共有後は共通鍵を使って暗号化する ◦ SSL もこの方式である
ハッシュ関数 • 任意の長さのデータを固定長のデータに圧縮する、次の性質 を持つ関数 ◦ 一方向性 ◦ 第 2 原像計算困難性
◦ 衝突困難性 • MD5, SHA-1, SHA-256, SHA-512
メッセージダイジェスト • ハッシュ関数は MAC (Massage Authentication Code) という 技術でも使われる •
送信側と受信側で共通している秘密鍵 (MAC 鍵という) を用 いて真正性と完全性を保証する
メッセージダイジェスト(例) • MAC 鍵: hito_no_okane_de_yakiniku_tabetai • 送信したいメッセージ: 5000_choen_hoshii • sha-256(5000_choen_hoshii
+ hito_no_okane_de_yakiniku_tabetai) = b1b575b2ddd2057d254ef731b7106bef41af5f53277475e01789a31e31b3f7b6 • 送信者は 5000_choen_hoshii とハッシュ値 (MAC 値という) b1b57… を送る • 受信者は受け取ったメッセージと共有している MAC 鍵でメッ セージが正しいか検証する
SSL/TLS • SSL とは 2 台のマシン間を結ぶ安全な通信路を提供するプロ トコル • TLS は
SSL の後続のプロトコル • その二つは(中身は似ているものの)違うものである • TLS であっても SSL や SSL/TLS と呼ことが多い(らしい)
SSL のハンドシェイク
SSL 通信の全体像 クライアント サーバ TCP の 3 ウェイハンドシェイク SSL のハンドシェイク
データ転送 SSL の終了 TCP の切断 TCP SSL
SSL のハンドシェイクの目的 SSL のハンドシェイクの目的は 3 つある • クライアントとサーバでデータ保護にどのアルゴリズムを使う か共有する •
その暗号技術に使われる鍵を共有する • クライアントの認証 (必須ではない)
データ保護のアルゴリズム 暗号スイート 認証 鍵交換 暗号 ダイジェスト 番号 TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA RSA
3DES_EDE_CBC SHA 0x000A TLS_DH_DSS_WITH_3DES_EDE_CBC_ SHA DSS DH 3DES_EDE_CBC SHA 0x000D TLS_RSA_WITH_RC4_128_MD5 RSA RSA RC4_128 MD5 0x0004 ※他にも暗号スイートはたくさんある https://tools.ietf.org/html/rfc5246#page-75
実際の接続
全体の流れ 右図のようなハンドシェイクを 行なっている ※次ページ以降で詳細を説明して いくが、今回の話題から逸れるとこ ろは割愛している クライアント サーバ Handshake: ClientHello
Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
ClientHello • クライエントが使用できる 暗号スイート一覧を送る • 鍵生成用にランダムな 32 バイトの値を送る (client_random) クライアント
サーバ Handshake: ClientHello Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
ServerHello • どの暗号スイートを選ん だか送る • 鍵生成用にランダムな 32 バイトの値を送る (server_random) クライアント
サーバ Handshake: ClientHello Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
Certificate • 公開鍵を送信する クライアント サーバ Handshake: ClientHello Handshake: ServerHello データ転送
Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
ServerHelloDone • このフェーズのすべて送 信が完了したことを知ら せる • Certificate の後に送信で きるオプションがあるため クライアント
サーバ Handshake: ClientHello Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
ClientKeyExchange • Certificate で受け取った 公開鍵で暗号化した pre_master_secret と呼 ばれる鍵を送信する ※暗号化ではなく、鍵交換ア ルゴリズムでもよい
クライアント サーバ Handshake: ClientHello Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
ChangeCipherSpec • 送信側の実装がネゴシ エート済みの別のアルゴ リズムと鍵の素材に切り 替えたことを通知 • 後続のメッセージからそ れらのアルゴリズムを使う ことを通知
クライアント サーバ Handshake: ClientHello Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
Finished • ネゴシエートされた暗号 技術で暗号化される最初 の通信 • ハンドシェイクのメッセー ジのダイジェストを送信す る(改竄検知のため) クライアント
サーバ Handshake: ClientHello Handshake: ServerHello データ転送 Handshake: Certificate Handshake: ServerHelloDone Handshake: ClientKeyExchange ChangeCipherSpec Handshake:Finished ChangeCipherSpec Handshake:Finished
鍵の生成 • client_random, server_random, pre_master_secret を用い て master_secret を作る •
master_secret, client_ramdom, server_random を用いて共 通鍵暗号の共通鍵、 MAC 鍵を作成する ◦ これによって暗号通信が行われる!
まとめ
まとめ • SSL 通信の暗号方式は、共通鍵と公開鍵両方をつかうハイブ リッド方式を使っている • ハンドシェイクは実質 2 往復しかしていない(意外!) •
master_secret から共通鍵や MAC 鍵が作られている
もっと話したかったこと • サーバの公開鍵は本物であることを示す方法 • master_secret の作り方 • 暗号化、復号の計算コスト • ディジタル署名
参考文献
参考文献 • マスタリングTCP/IP 情報セキュリティ編 (齋藤孝道 著) 2013年 p15-16, p35-36, p55,
p58, p124 • マスタリングTCP/IP SSL/TLS編 (Eric Rescorla 著、齋藤 孝道 監訳、鬼頭 利之 監 訳、古森 貞 監訳) 2003年 p52-61, p75, p83-95 • 情報処理推進機構(IPA) PKI 関連技術情報, 2.2.4 公開鍵暗号方式の種類 2009/9/1 最終更新 (最終閲覧日: 2020/5/24) https://www.ipa.go.jp/security/pki/022.html