プロフェッショナル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 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署名を正しく理解する

サイバー攻撃大辞典 | 攻撃例と対策