プロフェッショナルSSL/TLS
読んだ本
プロフェッショナルSSL/TLS
紙
PDF
メモ
全部読んでも流石に頭に入らなそうなので『プロフェッショナルSSL/TLS』の読み方(私論) - golden-luckyの日記に倣って1~8章を読む。
TLS関連の文章を読んだり実際に設定&運用の担当になった際に役に立つ程度の脳内インデックスを作ることを目標にやってみる
SSL2 は、Netscape 社の外部のセキュリティ専門家にはまったくと言っていいほど相談せずに開発されました
なるほど...牧歌的だ
Alice と Bob は暗号技術をわかりやすく説明するためによく使われている名前です。(略) 最初に彼らの名前が使われ たのは、1997 年、RSA 暗号システムを紹介する Ron Rivest の論文とされています
序盤の歴史の話はSSL/TLSとは何なんだ? 今こそ知ってもらいたいSSL/TLSのお話 〜 1回目 〜 SSL/TLSとは | さくらのナレッジを読めばOKみたいな感じ
暗号についての話は暗号技術のすべての序盤の話とか読むともっと深く歴史を知れる。この本では(SSL/TLSの本なので)サッとしか触れてないが。
ケルクホフスの原理 - Wikipedia
暗号方式は、秘密鍵以外の全てが公知になったとして、なお安全であるべきである。
暗号について簡潔にまとめてくれてる暗号技術勉強メモ - Qiitaは結構有難いのでよく見返す
初学者に毎朝唱えさせたい鉄則
(1)確立されたプロトコルを使い、自 分でスキームを含め設計しない。
(2)高レベルのライブラリを使い、暗号処理を直接扱うコー ドを自分で書かない。
(3)確立された暗号アルゴリズムを十分な鍵長で使う。
十分に暗号化された通信の保存、何がいけないのかというと未来の何かしらのブレークスルーにより復号できるようになったりしたときに遡って解読可能になってしまうから。国家安全保障レベルでは確かに無視できないな。
受動的攻撃とは(逆は能動的攻撃)
攻撃を受ける側の何らかの行動(例えば,「Webサイトへアクセスする」,「メールを開く/プレビュする」)を“トリガー”にする攻撃である
以降TLS1.2を解説
プロトコルという言葉がゲシュタルト崩壊してくる...
文脈によって規約/規則/規格当たりの言葉で補完すると混乱しないはず
プロトコル
Recordプロトコル
TLSの中心的なプロトコル
コネクション上でやりとりされる「データ転送」と「暗号処理」を担う
サブプロトコル
Handshakeプロトコル
通信を交わす両サイドのTLS接続で用いられるパラメータのやりとりと認証を担う
フルハンドシェイク
https://scrapbox.io/files/63aba9bb7f29e4001d4430ba.png
参照: 第2章 プロトコル 2.2 Handshakeプロトコル P27
1: 双方が接続に使いたいパラメータ(暗号スイートや鍵交換方法)を提示して合意
2: 提示された証明書の認証
3: セッションの保護に使うmaster secretを共有
4: ハンドシェイクの書くメッセージが書き換えられてないことを検証(MACを使う)
徹底的に中間者攻撃を疑い検証するように作られているな...
クライアント認証
サーバー認証は必須だがクライアント認証は必須ではない
IBM Documentationや【図解】クライアント証明書(https,eap-tls)の仕組み ~シーケンス,クライアント認証,メリット~ | SEの道標を参照
セッションリザンプション
ClientHello時に以前のハンドシェイクで割り当てられたSessionIDを送って通信を再開させることで証明書の検証などのハンドシェイクを省略するプロトコル
SessionIDをブルートフォースしたりできそうだけどセキュリティ的に大丈夫なのか?
TLSセッション再開 (session resumption) のしくみ - Qiita
A. 今のところSession IDが死んだという話は聞きませんので、セキュアと考えていいと思います。ただし、セッション再開の時にはサーバ証明書の検証をしませんので(クライアント証明書の検証もしません)、フルハンドシェイク時点では有効でも、セッション再開の時点では既に有効期限が切れていたとか、CRLが発行されていたとか、そういうのは検出できません(コネクション成功してしまいます)。これに対抗するにはセッションの生存時間を短めに設定するしかありません。RFC5246 (Google翻訳) (TLS1.2) の推奨は長くとも24時間となっています。まあそんなところでしょう
Change Chipher Specプロトコル
Application Dataプロトコル
Alertプロトコル
鍵交換
RSAがデファクトだが、サーバの秘密鍵が漏れると過去含めて全通信を復号される問題がある
PFS(Perfect Forward Secrecy)
秘密鍵が漏れても過去に遡って暗号文が復号されない特性
クライアントとサーバーで利用するmaster secretを接続ごとに毎回独立して利用できてよりセキュア
RSA は鍵交換と認証に利用可能であり、認証での利用には何の問題ないが、鍵交換には使わない方がいい
なぜ?
PFSではないので。どちらかの秘密鍵が漏れるとクライアント・サーバーともに過去のやりとりが復号可能になってしまう。将来のTLSではPFSのない暗号スイートはサポートされなくなる。
アプリケーションデータの暗号化
ストリーム暗号
ブロック暗号(AESが主流)
AEAD(認証つき暗号)
拡張
プロトコルを修正せず(handshakeの流れを変えず)にTLSに機能追加する仕組み
利用可能な楕円曲線暗号を交換したりするときなど、発展的にTLSを強化するのにも役立つ
ALPN
TLS接続上でアプリケーション層に異なるプロトコルを使うことをネゴシエーションするための拡張
懐かしのHeartbleed
HeartBeatはキープアライブとMTU探索の機能をTLSとDTSLで提供する拡張
これを悪用して任意のプロセスを読み取る攻撃がHeartbleed
NPN(Next Protocol Negotiation)
SPDYで必要になってGoogleがTLSを拡張したときにできたやつ。パワーだ。
HTTP/2 プロトコルネゴシエーション方法と ATS での実装 - Yahoo! JAPAN Tech Blog
SNI
SNIもTLS拡張で実現されてるのか〜。Cloudflareの解説記事の説明よかった。
SNIとは?TLS Server Name Indicationの仕組み | Cloudflare
SNIは、小包を家ではなくアパートに郵送するようなものです
TLSで何が秘匿化でき、何は観測可能なのか(暗号化前のハンドシェイク内容やTCPより下のIPなどのレイヤ情報等)は理解しておく必要あり
ここまで理解した上で付録のTLS1.3を読むと対応させながら読めて良いな
PKI(公開鍵基盤)
公開鍵が本物であることを証明する必要がある。これはどう実現するか?
インターネットPKIにおいては全員が無条件に信頼する証明書(秘密鍵と公開鍵含めたデジタル証明書(認証局自身の秘密鍵での署名入り))の発行をCA(認証局)と呼ばれる第三者機関に委ねるモデル
2つの公開鍵暗号(公開鍵暗号の基礎知識) - Qiitaに似たような話が書いてある
なんか全体的に読んだことあるな〜と思ったら図解 X.509 証明書 - Qiitaだった。この記事はあまりにもわかりやすすぎるのでおすすめ
弱点
CA自体の信頼性の問題。ドメインの安全性によらず自由に発行されすぎる。求められるセキュリティの割にシステムとしてはわりかし弱い。
失効ができない・できるまで時間がかかる
PKI のエコシステムの状況について公にわかっていることは、2010 年までほとんどありま せんでした。2010 年に、PKI エコシステムの活発なスキャニングやモニタリングの時代が幕 を開けました。
公開鍵ピンニング
信頼できるCAをサイトの所有者側が指定できる仕組み
攻撃の影響範囲を狭められるのでなかなか有効
そもそも全てのCAが任意のドメインに対する証明書を発行できることが問題。
ピンニングによってvalidな証明書と認められるCAを絞ることができる。
調べてみると証明書のピンニングはやめましょう | DigiCert.comという記事があった。
DigiCertは4章にて過去雑な証明書発行をやっていたが信頼できる記事なのか?
CT(Certificate Transparency)
証明書の監査とモニタリングのフレームワーク
発行した証明書をブロックチェーン上に記述するとかどうか?誰でも閲覧できるし書き換えできないし。金かかるけど。
PKIへの攻撃/HTTPおよびブラウザの問題/実装の問題/プロトコルに対する攻撃
悪意を持ってデジタル証明書が発行されると何が困るか?
要はコンテンツの保有者を偽ることができるようになる
例えばhoge.comのデスクトップアプリをダウンロードする時にhoge.comがvalidにホストしたソフトウェアであるとポップアップを出せるようになってしまう
よく考えたら確かにリスクありすぎる
すべての CA が、ドメ イン名の所有者に承認を求める必要なく、どんなホスト名の証明書でも発行できてしまう
20 年以上も使われてきたシステムが、数百の組織と数千の人間がすべて正しい行いを することを前提にしている
4~7章はSSL/TLSに関する周辺で発生した問題が2000年くらいから丁寧にまとめられていて歴史資料として面白い。長くなるのでこのメモに詳細は書けないけど総ざらいできて良い。
HTTPとブラウザの問題の章ではsecure属性の話などWebブラウザセキュリティで取り扱われている内容と被る部分も多い
実装の問題ではやはり主にOpenSSL由来のバグに関するHeartbleedやRSA/DHEの鍵交換にまつわるFREAK/Logjamなどの話が多い。
BEASTの件
各種ベンダーに脆弱性になり得ると指摘しているのに、度々それらを軽んじられてきたセキュリティ研究者。なんとかして現実的な攻撃手法のPoCを捻り出せないかと苦心したその執念がインターネットの安全性を高めてきたようだ。(ブラウザやライブラリで広く修正が入ったのは根本的な問題が指摘され始めてから10年かかっている。)
選択平文攻撃
任意の平文から暗号文を取得できる条件で、平文と暗号文を大量に生成し、そこから暗号鍵を推測する攻撃手法。
POODLE
Bullrun
あんまり情報なかったからChatGPTに聞いた↓
Bullrunは、2013年にエドワード・スノーデンという元NSAの契約者が明らかにした、分類されたNSAのプログラムです。このプログラムは、オンライン通信やデータを保護するために使用される暗号化基準や技術を弱めるか、回避するために様々な手法を使用するとされています。これには、暗号化ソフトウェアに「バックドア」や脆弱性を利用することや、暗号化されたトラフィックを受信して復号するための特殊なハードウェアやソフトウェアを使用することが含まれます。
Bullrunプログラムの目的は、NSAが暗号化された通信やデータにアクセスできるようにすることです。NSAがBullrunプログラムをどのように使用したか、また暗号化基準をどの程度回避できたかは明らかではありません。このような手法の使用は、プライバシー保護活動家や専門家の間で懸念を引き起こしており、暗号化基準を弱めることはインターネットユーザーのセキュリティとプライバシーを損なうものであると主張しています。
8章のデプロイ
実用的な話(鍵の選び方や管理方法、各種設定での注意事項など)のみキャッチアップしたいならここから読んでいくと良い
1~7章とその後の9~17章の中間地点。一旦ここまで読んで座学的なところが終わり、以降は最新情報や具体的なライブラリやミドルウェアでのセットアップの話が続く。座学だけでいい人はここまで+付録Aと10章くらい?で確かに良さそう。
ECDSA鍵はどのくらいのブラウザでサポートされてるのかなと調べてみたら今はほぼ全てのモダンブラウザでサポートされているようだった
Template:ウェブブラウザにおけるTLS/SSLの対応状況の変化 - Wikipedia
その他
rustls/rustls: A modern TLS library in Rust
TLS1.2/TLS1.3のRust実装
「Implementing SSL / TLS」を Rust で
Implementing SSL/TLSという良さげな洋書があるらしい。1235ページ...
RSA署名を正しく理解する
サイバー攻撃大辞典 | 攻撃例と対策
良さげな個人サイトあった。間違ってる内容もあるかもしれんが。
Template:ウェブブラウザにおけるTLS/SSLの対応状況の変化 - Wikipedia
ブラウザごとの各種脆弱性への対応状況やサポートする暗号方式がまとまっている(見にくいが...)
暗号鍵設定ガイダンス~暗号鍵の鍵長選択方法と運用方法~:IPA 独立行政法人 情報処理推進機構
暗号鍵設定ガイダンス | PDF
長く使われる想定ならば128bit以上が推奨とのこと
https://scrapbox.io/files/63ad46cfa88ff7001ecce304.png
【CTF入門】楕円曲線暗号の計算方法(入門)【kurenaif】
楕円曲線暗号の理論的なイメージはこの動画がわかりやすかった
HSTS/CSP
読書メモ