ぼちぼち日記

おそらくプロトコルネタを書いていることが多いんじゃないかと思います。

書評 プロフェッショナルTLS&PKI 改題第2版 (PR)

はじめに

『プロフェッショナルTLS&PKI改題第2版（原題: Bulletproof TLS and PKI Second Edition）』が出版されました。今回は出版前のレビューには参加していませんが、発売直後にラムダノートさんから献本をいただきました。ありがとうございます(そのためタイトルにPRを入れてます)。原著のサイトでは前バージョンとのDiffが公開されており、今回は翻訳の確認を兼ねて更新部分を重点的に読みました。このエントリーでは、改訂版のアップデート部分がどのようなもので、今後どう学んだらよいかということを中心に書いてみたいと思います。

短いまとめ： HTTPSへの安全意識が高まっている今だからこそ『プロフェッショナルTLS&PKI』を読みましょう。

長文注意！： 書いているうちに非常に長文(1万字以上)になってしまったので、長文が苦手な方は、GPT-4要約(400字)をお読みください。

今は嵐の前の静けさか？

2018年のTLS 1.3の仕様化から5年が経ち、近頃は大規模な脆弱性に対する急な対応がなくなったなと感じています。朝起きてみたら重大な脆弱性が突然公表されて世の中大騒ぎ、慌てて調査してその日のうちにパッチ当て作業をしなければいけなかったり、日本の連休中なのにOSSのCriticalな脆弱性対応が予告され、眠い目をこすりながら夜中にリリースを待ったりする、ということもかなり少なくなりました。最近ではTLS 1.2をレガシーなものに移行するために機能凍結も提案され、TLS 1.3の耐量子暗号への対応も徐々に進められています。

他方、OpenAIが開発しているQ* というプロジェクトが、多くの平文と暗号文を分析して、未知の数学理論を使いAES-192暗号を破った、という噂も流れています。近い将来優れたAGIが現れて、暗号技術が突然危殆化したり、セキュリティプロトコルの深刻な脆弱性が密かに見つかって知らないうちに悪用されたりする、といったこともあるかもしれません。PKI分野では、政府が認めた認証局をブラウザーに登録することを義務付けるかどうかについて、欧州のeIDAS規則の改正案で議論されています。ブラウザベンダー側は大反発していますが、トラストアンカーの管理をめぐる状況は今後大きく変わるかもしれません。

こうした激動の時が来る前に、今こそ落ち着いてネットワークセキュリティについて学ぶ絶好の機会だと私は考えています。

この本の目的と魅力

セキュリティは難しい分野であることは確かですが、それでも完全に知識がないわけにはいきません。ITの分野で働く全ての技術者には、一定のセキュリティスキルが必要とされるでしょう。その複雑さはダニングクルーガー効果の「完全に理解した」と「全くわからない」の間を頻繁に行き来するものです。セキュリティをさらに詳しく理解しようとすればするほど、各分野で深い知識が要求され、簡単には理解できない泥沼に陥りがちです。

この本の特長は、セキュリティという複雑で高度な技術分野の難しい部分を上手く省略し、比較的理解しやすい言葉で説明している点にあります。また、過去30年近くにわたるTLS/PKIの歴史を通じて生じた技術的な課題や問題点を幅広くカバーしていることも、この本の大きな魅力です。内容は完全な初心者向けではないものの、読者は各自のレベルに応じて「完全に理解した」(もしくは「全く分からない」)までこの本によって引き上げてもらえるでしょう。

この本を始めから一貫して読むのも良いですが、読み物中心の第1章が終わったら業務的な必要や興味に応じて特定の章を選び、自分なりの理解を深めていく方が良いのではないかと思います。実際に手を動かしてみてから同じ内容を再読すると、新しい理解と納得感が得られるはずです。そういう意味ではネットワークのセキュリティ対応を行うIT技術者にとって、いつでも参照できるよう常に一冊手元に置いて置くべき書籍だと思います。著者が始めに「本書の目的は、SSL/TLS と PKI について日常の業務で必要となる実用的な知識をすべて網羅することです」と書いてありますが、まさにそのとおりです。

今回のアップデートについて

本の最新版では、2021年までのTLS/PKIの最新動向を取り入れ、内容がTLS 1.3を中心に更新されています。本書は大きく4つのパートに区分されており、各セクションで行われたアップデートについていくつか紹介します。

パート1: 暗号技術、SSL/TLS、PKIについての概説(第1章〜第4章)

このセクションでは、これまでの歴史、通信と暗号技術の基本、TLS 1.3と1.2の概要、そしてPKIの仕組みについて詳しく解説しています。今回の改訂で最も注目すべき更新点は、TLS 1.3の仕組みに焦点を当てた新しい章が加わったことです。

TLS 1.3

以前は翻訳電子版限定で追加されていたTLS 1.3の章が、今回の改訂により第2章として本文に正式に組み込まれました。また、TLS 1.3の標準化が完了したことを受け、他の章もTLS 1.3に準拠するよう全面的に更新されています。

序章にある「本章では TLS 1.3 について高い視座から概説します」との記述通り、この章ではTLS 1.3の機能と仕組みについて理解するための必要な情報が提供されています。前職ではTLS 1.3の仕様を徹底的に学ぶ勉強会を開催していましたが、全てを習得するまでには2年以上もかかり、とても大変でした。その経験から本書のように最初の方で高い視座から理解することがいかに大切かを強く感じています。

この章の内容は、主に以下の3つの大きな項目に分けられます（内容が重複したりまたがっているような部分もあります）。

  1. TLSプロトコルのデータ構造とフロー(Record プロトコル、Handshake プロトコル、Alert、拡張)
  2. TLSのセキュリティを実現している仕組み(認証、暗号に関する計算、暗号スイート)
  3. 0-RTT

この本では、フルハンドシェイクとセッション再接続のプロセスが主に取り上げられており、TLS 1.3の基本的な知識はしっかりとカバーされていると思います。0-RTTに関しては、TLS 1.3の新しい主要機能として特に詳しく解説されていますが、最初は大まかに読む程度で良く、まずはセッション再接続の仕組みを理解することから始めましょう（後ほど私のブログも紹介します）。

この本では拡張について最小限の内容のみを扱っているので、その点には注意が必要です。著者は、「TLS に対する俯瞰的な理解にとって拡張の中身を詳しく知ることはあまり意味がない」と述べています。確かに拡張は複雑で種類が多く、TLS 1.2から引き継がれたものと新しいものが混在しており、全体的な理解には必ずしも必要ではありません。ただし、後ほど説明するように、TLS 1.3はミドルボックスに対応するために、多くの機能を拡張に押し込んでいます。そのため、TLS 1.3の本質を理解するためには、拡張を通じて実現されている重要な機能について学ぶことが避けられません。TLS 1.3についてもっと深く学ぶ方法については、後ほど詳しく説明します。

公開鍵基盤(PKI)

この章で特に注目すべきアップデートは、CT（Certificate Transparency）とCAA（Certification Authority Authorization）という2つの記述が新たに加わったことです。

CT(証明書の透明性)

CTは、認証局の問題に対応するためGoogleが開発したシステムで、パブリック証明書の透明性を高めることを目的としています。現在、AppleやMicrosoftもこのシステムに参加しており、PKIの標準的な一部として取り入れられています。本書では、CTの必要性や仕組み・現状について技術的な難しい部分には深入りせず、幅広く端的にまとめて概説しています。

現状、CTのシステムに対する監査体制の不足や大規模な運用に伴う可用性確保の困難はあるものの、認証局によるパブリック証明書の発行が公に監視されるようになった結果、一定の効果が得られています。例えば、後の章で触れられているように、Symantecが不正にテスト証明書を発行していた事実が明らかになるなど、CTによる透明性の向上が実際に問題を明るみに出しています。

CTのシステムは、認証局やブラウザベンダーのエンジニアでなければ、一般のIT技術者が直接関わることは少ないかもしれません(*1)。しかし、認証局がネットワークセキュリティの根本としてのトラストアンカーを担っているため、技術者としては現行のPKIシステムがどれほど信頼性を保証しているのかを理解しておくことが重要です。

この節を読むと、翻訳の難しさがよくわかります。特に「ログに登録されているという証明が証明書にない」という部分です。原文では"proof of registration"と"certificate"という、どちらも日本語での「証明」ですが、「証明が証明書にない」となると少しわかりづらくなってしまいます。この場合の "proof"を「証拠」としたならどうかなと最初思いましたが、なかなかピッタリくる日本語が見つからないですね(既にラムダノートさんにフィードバックしています）。読む際には、どのような証明を指しているのかを常に意識しながら進めると良いでしょう。

(*1) 2024年1月5日19時追記: セキュリティ担当者なら自社サービスドメインのCTログをモニターして不正証明書が発行されていないか監視するといった関わり方が必要でしたね。実は過去自分も Meta が提供しているCTログモニターで監視をしていたのですが、通常の証明書発行時の通知がうざくなってしまい途中で止めてしまいました。何かアノマリー検知みたいな仕組みと組み合わせないとCTログの監視はちょっと大変かなと思いました。

CAA(CA に対する認証)

CAAは、証明書を発行できる認証局をDNSレコードに登録し、登録されていない認証局からの証明書発行を防ぐ機能です。これは、認証局による不正な証明書発行に対してユーザが取ることができる唯一の防御策です。この節では、CAAの設定概要、導入方法、現在の課題などが説明されています。

本書には明確に記載されていないものの、私の経験から言うとCAAの難しい点は、CNAMEを使って複雑にドメインのエイリアスを利用している場合です。CNAMEドメインにはCAAレコードを直接設定できないため、CNAME先または上位ドメインにCAAを設定する必要があります。この際、CNAME参照とDNSツリークライミング（DNSの階層を遡ること）を考慮した設計が必要です。

当初の仕様（RFC6844）ではこの点が曖昧で、Errataで指摘されていましたが（現在のRFC8659では修正されています）、CNAMEを使って複雑なドメイン利用をしている場合は、特に神経を使いました。ただし、CAA導入自体はDNSにレコードを登録するだけであり、アプリケーションが直接CAAレコードを参照することは禁じられています。そのため、テストをしっかり行えば、CAA導入によるサービス運用への直接的な影響はかなり低いと言えますので、その点は安心できるでしょう。

一方で、CAAの導入は認証局の不正対策だけでなく、社内セキュリティガバナンスの観点からも大きな意味があります。大規模な組織では、特定の商用認証局に限定してサービス用ドメインの証明書を利用するケースが多いでしょう。しかし、サービス部門が組織認証を回避して、勝手にドメイン認証を行って他の認証局の証明書を利用してサービスを運用してしまうかもしれません。問題は証明書の発行自体ではなく、このようにセキュリティ内規に従わない（またはその存在を知らない）部門は、他にもシステムに何らかの脆弱性を残している可能性があることです。

最悪の場合、サービスドメインを含む証明書と秘密鍵が盗用されてフィッシングサイトに利用されるなどのセキュリティ事故につながる恐れがあります。CAAを導入することで、こうしたリスクをある程度コントロールできると言えるでしょう。内部的なセキュリティガバナンスを徹底する一つの手段としてCAAを導入すると言った面もあるかと思います。

この章ではCAA導入に関する手順が詳しく記載されており、非常に参考になります。大規模な組織だったりすると、もしかしたら知らない間にどこかの部署で違う認証局から証明書が発行されているもしれないという状況では、CTログを徹底的に調べる必要があります。さらに、CAA導入後には指定認証局から正常に証明書が発行される試験はもちろんですが、不正な証明書発行を防止できているか他の認証局からの発行テストも考えないといけません。CAA設定のチェックのためとは言え、リアルに不正な証明書の発行を試すのは背徳感があって非常にドキドキします。しかし、実際に体験するとCAAの導入がもたらすセキュリティ向上の重要性を実感できるでしょう(当然ですが実際にテストする場合は、認証局の業務に迷惑を掛けないよう十分に配慮して行いましょう)。

CAAに関しては、私のブログでもその仕組みを紹介しています。この章を読んでCAAについて理解を深めたい方は、より詳しい情報を得るためにぜひ私のブログをご覧いただければと思います。

jovi0608.hatenablog.com

パート2: 信頼を支える基盤、セキュリティプロトコル、その実装であるライブラリとプログラムが抱えるさまざまな問題(第5章〜第8章)

このセクションでは、PKI、HTTP、ブラウザ、実装、そしてプロトコルの問題点や攻撃方法について詳しく解説しています。20年以上前に起きた問題から最新の課題までを網羅し、TLS/PKIが直面している問題や課題の歴史的背景を学ぶことができる非常に価値のあるパートです。各問題は複雑で深いものが多いですが、歴史的な謎解きを楽しむような感覚で、過去の問題が現在のTLS/PKI技術にどのように反映されているかを学んでいただければと思います。

PKI に対する攻撃のアップデート

PKIの問題については、カザフスタン政府による傍受用のルート証明書の導入騒ぎと Symantec の Distrust について追記されています。その時の自分の一言tweetコメントを載せておきます。

HTTP/ブラウザ問題のアップデート

このアップデートでは、皆さんが日常的に使用しているブラウザーにおけるEV（Extended Validation）証明書の表示がなくなった背景と、証明書失効のメカニズムにおけるOCSP Staplingの機能について詳細に追記されています。EV証明書の表示がなくなったことと、Chromeブラウザの表示アイコンが変わったことについては、少し古い情報ですが、私のブログでも解説しています。興味がある方は、ブログも合わせてご参照いただければと思います。

jovi0608.hatenablog.com
jovi0608.hatenablog.com

本書では、現行PKIの証明書失効機能の問題点と限界に関して深く掘り下げています。それを読むと現在のPKIシステムに少し悲観的になるかもしれませんが、OCSP stapling は、ユーザーのプライバシー保護と証明書失効メカニズムを少しでも改善するために実行可能な数少ない手段の一つであり、現状でも対応する価値は十分にあると思います。しかしこの先は現状の証明書失効メカニズムを改善していく方向ではなく、短期証明書の導入を拡大し、失効機能に依存しない新しい対策へと移行していくだろうと予測しています。

実装の問題、プロトコルに対する攻撃のアップデート

このセクションは、幅広く深いセキュリティ知識が求められる部分です。特に、プロトコルの基本的な構造に起因する脆弱性は、これまでの専門家によるプロトコル設計に対する深い考察を裏切るようなものが多いため、これらを理解することはTLS 1.3への深い洞察に繋がるでしょう。しかし、この理解への道は困難であることを覚悟してください。

今回のアップデートでは、STARTTLSの実装に関する脆弱性、TLS 1.3のダウングレード攻撃防止機能、ALPACA、ROBOT, Racoon攻撃、そしてKCI攻撃についての内容が追加されています。KCI攻撃については、私のブログで詳しく解説しています。少し難しい内容かもしれませんが、図を使って丁寧に説明していますので、興味のある方はぜひ参照してみてください。

jovi0608.hatenablog.com

ROBOT（Return Of Bleichenbacher’s Oracle Threat）攻撃についての記述は衝撃的でした。1998年に発表されたRSA PKCS #1 v1.5のエラー処理対するBleichenbacher攻撃という脆弱性が、約20年後も多くの商用製品で未解決のまま残っているという事実です。開発者としてはエラーをすぐに処理したいという本能的な願望がありますが、その急ぎ足が逆に脆弱性を生む原因になり得てしまいます。結果暗号実装では、さまざまなサイドチャネルを考慮する必要があり、セキュリティに関わる実装の難しさを改めて感じさせられる事例でした。

Racoonについては、以下のツイートがその内容を一言でまとめています。「やはり暗号実装は難しい」。これも暗号技術の実装における複雑さと難易度を端的に示している例と言えるでしょう。

パート3: 安全かつ効率的な設定でTLSをデプロイするための情報(第9章〜第10章)

このセクションでは、パフォーマンス、HSTS（HTTP Strict Transport Security）、CSP（Content Security Policy）、ピニング、そして設定ガイドについて述べられています。最新のアップデートでは、QUICとHTTP/3の概要が新たに追加されました。

ピニングについては、第1版で紹介されていたブラウザ向けのHPKP（HTTP Public Key Pinning）が廃止された背景が説明されています。他方、アプリケーションでは不正行為や攻撃を防ぐために証明書ピニングが求められる場合があり、ピニングを利用する際の注意点や方法などが新しく追記されています。

パート4: OpenSSL(第12章〜第13章)

改訂前の「プロフェショナル SSL/TLS」では、Apache、Java/Tomcat、MS Windows/IIS、Nginx といった具体的なアプリケーション設定を解説した章がありましたが、改訂版ではOpenSSLだけ残し他はなくなりました。このパートで OpenSSLの使い方とOpenSSLコマンドによる動作検証のやり方など記述しています。

一つ残念だったのは、本セクションは OpenSSL1.1.1ベースで解説されていますが、既に2023年9月にEOLになってしまったことです。ただし実際に確認したところ OpenSSL3系では出力が少し違うだけで、それほど大きく違う箇所はありませんでした。手順や出力では、SEED-SHAなど古い暗号が使えなくなったことを注意すれば良いかと思います。 またTLSの古い機能を調べるためにサポート切れ OpenSSL-1.0.2g での使い方も追記されていますが、こちらは手元でコンパイルして検証用途だけに限定して使いましょう。

今回新たに追加された内容には、OpenSSLのセキュリティレベルに関する説明、TLS 1.3の設定手順、OpenSSLの初期設定方法、そしてSession Resumption（セッション再開）の手順が含まれています。

「13.11 セッションリザンプションの動作を確認する」セクションでは、OpenSSLのバグのためにTLS 1.3では-reconnectオプションを使用してセッション再開の動作を確認することができないという注記が追加されています。しかし、バグ自体は直っていませんが、替わりにOpenSSL-3.xではs_clientにCコマンドを直接送信することでTLS 1.3の再接続を実現できるようになっています。TLS 1.3を使用するクラスター環境で、チケットなどのリザンプション機能のテストが必要な場合は、この方法を試してみると良いでしょう。

$ echo C | openssl s_client -connect example.jp:443
Connecting to XXX.XXX.XXX.XXX
CONNECTED(00000006)
(中略)
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
RECONNECTING
Connecting to XXX.XXX.XXX.XXX
CONNECTED(00000006)

このOpenSSLのセクションは、おそらく本書の中で私が最も頻繁に参照している部分です。同様の内容を扱う他の書籍はほとんど見かけません。OpenSSLのコマンド、機能、引数、設定値は非常に多岐にわたるため、通常はOpenSSLのマニュアルやソースコードを確認することが多いですが、それは面倒な作業です。なので、まずはこの章に記載がないかを探すようにしています。特に、プライベートCAを作成し、検証用の証明書を自分で発行する際、OCSPサーバーの設定方法まで記載されており、大いに役立っています。

自分でプライベート認証局を設立し、ルート証明書を自分のブラウザの信頼リストに追加することで、様々な検証を行うことができ、TLS/PKIに関する技術的な知識が大きく広がります。まだ試したことがない方は、PKIの仕組みを体験する意味でも、OpenSSLを使って自分のプライベート認証局を作成してみることをお勧めします。

本書でTLS 1.3を理解するためのちょっとしたアドバイス

ここまで改訂版のアップデートとTLS/PKI技術の内容に焦点を当ててきましたが、次に第2章を読んでTLS 1.3をより深く理解するために、いくつか私なりのアドバイスをご紹介したいと思います。

1. Record層の形式について。

「2.1.1 Record プロトコルの形式」セクションでは、TLS 1.3のRecordプロトコルがミドルボックスの影響を受けて形式的なプレースホルダーになっていることが説明されています。Record層やClientHelloのバージョン番号の透過性に関して、以下の私のブログでより詳しい情報を提供しています。

jovi0608.hatenablog.com

このブログでは、このような状況がなぜ生じたのか、どれくらいの影響があるのかについての背景と詳細が理解できます。また、本書の「7.7.2 相互運用性の問題/バージョンに対する不寛容」、「7.7.7 将来の相互運用性の問題を防ぐGREASE」、そして「9.1.5 QUICとHTTP/3」のOssificationの節も合わせて読むことで、ここで述べられている内容の理解が深まるでしょう。

2. ハンドシェイクメッセージの構造は、実際に目で見て確かめる。

TLS 1.3は、暗号化通信に迅速に移行するため、Wiresharkなどのパケットキャプチャツールを使って通信内容をすべて確認するのは大変で、手間のかかる作業になります。しかし、ただ本に書かれたハンドシェイクの説明を読むだけでは、実際の動作についての実感は得られないでしょう。プロトコルを学ぶ基本は、実際のプロトコルデータを自分の目で見て理解することから始まります。OpenSSLのコマンドを使えば、比較的容易にハンドシェイクメッセージの中身を見ることができます。そのためには-traceオプションを試してみると良いでしょう。

$ openssl s_client https://example.jp/ -trace

-trace オプションを使用すると、実際のTLSハンドシェイクの詳細な内容を見ることができます。サーバ側とクライアント側で様々な設定を試しながらハンドシェイクの中身を確認し、各フィールドや拡張がどのような意味を持っているのかを調査し、考察しながらデータを分析することをお勧めします。このように実際のデータを直接見ることで、TLS 1.3に関する理解が大きく深まるはずです。

openssl の trace 出力例

3. 暗号に関する数式は、そんなものと最初は深入りしない。

暗号技術は、第1章でも少し触れられているように、非常に複雑で難解な分野です。すぐに深みにはまり、困難に直面することも多いでしょう。最初のうちは、深入りしすぎないように注意しましょう。ただし、読み進めていると、突如としてわけの分からない数式が登場することがあり、それに戸惑うかもしれません。以下のような数式が出てきたときに、理解が止まってしまわないように、ある程度のその先の手がかりを確保しておくと心理的に楽になります。

AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data)

はい、暗号技術の少し深い部分を理解するための入り口として、私のブログがお手伝いします。

TLS 1.2で使用される形式について、ChaCha20-Poly1305のAEAD（Authenticated Encryption with Associated Data）に関する解説は、こちらのブログに、 jovi0608.hatenablog.com

そしてAES-GCMのAEADについてはこちらのブログに、少し簡単に書かれています。興味がある方はぜひ参照してみてください。そうすることで、AEAD-Encrypt関数に関するイメージが少しは明確になるのではないかと思います。

jovi0608.hatenablog.com

また本章では、TLS 1.3の鍵導出と鍵スケジュールに関して、「2.5 暗号に関する計算」という節でかなりのページを割いて詳細な解説をしています。多くの読者が「なぜこんなに複雑な手順を踏むのか？」という疑問を持つことでしょう。本書では、『「1 つの鍵は 1 つの用途にしか使わない」というのが暗号学における原則です。』の一文で済ませてしまってますが、この疑問に対するもう少し詳しいヒントを、以下のツイートで少しだけ触れていますので、参考にしてみてください。


. .

4. 拡張についていったん横に置いておくけど頭に残しておく。

原著者は、TLSに対する全体的な理解のためには拡張の詳細を深く知ることが必ずしも重要ではないと述べており、そのため本書ではTLSの拡張については詳しく解説せず、仕様への参照を促しています。確かに、TLSの拡張は種類も機能も多岐にわたり、詳しく解説すると理解が難しくなる可能性があります。しかし、TLS 1.3はTLS 1.2と形式的な互換性を保つため、多くの機能を拡張領域に組み込む方針で再設計されています。個人的にはこれらの拡張はもはやプロトコルの核心部分そのものだと考えています。全体的な理解のためには必要ないかもしれませんが、TLS 1.3の本質を深く理解するためには、いずれ重要な拡張機能についての理解を避けては通れないでしょう。

現在、TLS拡張は0番から61番までがアサインされています。本書でも参照されていますが、詳しい一覧はこちらのIANAのページ Transport Layer Security (TLS) Extensions
にあり、TLS 1.3でどのハンドシェイクに使われるかのタグが付いています。全体的な理解を深めた後で、さらに詳細を知りたくなったら、TLS 1.3仕様で定義されている拡張（参照がRFC 8446になっているもの）に注目してみてください。これらの拡張を理解することで、TLS 1.3のより深い理解につながるでしょう。

5. 0-RTT についてより深く知りたいなら。

TLS 1.3の新機能である0-RTTを理解することは、TLS 1.3の理解においてクライマックスに相当する段階です。第2章のまとめで「ただし、0-RTTでは常に前方秘匿性が有効になるわけではない。それでも旧バージョンよりはましだ」と述べられています。このポイントを深く理解するには、実際に0-RTTの前方秘匿性を破る実験をしてみることが最も効果的です。詳しい解説は以下のブログで行っていますので、意欲のある方はぜひ課題に挑戦してみてください。

jovi0608.hatenablog.com
jovi0608.hatenablog.com

もっとゆるく学びたい人へ(リアルTLSハンドシェイク演習)

以前、「プロトコルを学ぶ基本は実際のデータを目で見ることから始まる」と述べましたが、次のステップとして「実際にプロトコルデータを作成し、送受信する」ことが理解を深める上で非常に効果的です。自分でTLSクライアントをプログラムして、既存のTLSサーバに対してデータを送り、応答を解析することで、さらなる理解が促進されます。実際にデータを扱うことで、理論だけでは得られない深い洞察や実践的な知識が身につくでしょう。

とはいうものの、実際にプログラムを書くことに躊躇される方もいるでしょう。もう少し気軽に学びたい方には、リアルTLSハンドシェイクの演習を試してみることをお勧めします。これは、前職で行った大学の社会人コースの講義で使用した演習課題です。参加者は2人1組になり、クライアント役、サーバ役に分かれてポストイットにTLSハンドシェイクのデータを模して記述し、お互いに交換します。なんちゃってDH鍵交換やハッシュ計算など行い、最終的には机の上に並んだ色とりどりのポストイットを通じて実際にどのようにTLSのセキュリティ通信が実現されているのかを体感できます。この方法は、受講者からも「実際のTLS通信プロセスを実感できた」という感想もいただいています。

リアルTLS1.2ハンドシェイク演習

この演習はかなりゆるいものですが、もしご自身がグループで本書を輪読する機会があれば、以下のレポジトリにTLS 1.2の課題が用意されていますので、実際に試してみてください。そして、TLS 1.3ではどのように違ってくるのか、その探求を皆さんの宿題として挑戦してみてください。学びを深めるために、是非ともこの機会を利用して頑張ってみてください。

github.com