DHEについてDHEの取り扱いについては、先に書いた通りガイドラインと私の評価が少しずれています。読んでみると少し記述がおかしい部分も見られますので、そこをコメントさせていただきます。明示的に鍵長を指定できない代表例のアップデート以下に2例が示されていますが、最新の状況では条件によりますが、DHE鍵長の指定ができるようです。実際に試して検証をしていないのでポインターだけになります。使えばRSAの鍵長に合わせてDH鍵長も変えられる。リンクが間違っていました。さんありがとうございました。https://technet.microsoft.com/ja-jp/library/security/3174644.aspxhttps://docs.microsoft.com/ja-jp/windows-server/security/tls/tls-registry-settings#keyexchangealgorithm---diffie-hellman-key-sizesレジストリを変更すればDH鍵長も変えられる。DHEの鍵長の決まり方DHEで利用する鍵長の決定方法についての記載が、非常におかしく思います。p46より引用の部分ですが、TLS1.2(RFC5246)の範囲では、DHEでは鍵長を交換する仕組み自体がありません。上図の通り、サーバ側が勝手にDHのパラメータをクライアントに投げるだけです。クライアントがサポートされていない鍵長だとハンドシェイクエラーになります。プロフェッショナルSSL/TLSから該当部分を一部引用してみましょう。策定され、TLS1.3にも取り込まれています。それは、ECDHEと同様にDHEのパラメータを名前付けし、ClientHelloのExtensionでECDHE/DHEともにサポートするDHEグループリストをサーバに伝える方法です。これですと、サーバはクライアントがサポートされているDHグループを判断し、鍵交換を行うことができます。RFC7919をサポートしているブラウザは私の知る限りまだ見ていません(誰が知っていたら教えてください)。結局DHEを推奨すべきかどうかこのように現状のDHEは、鍵長交換ができないと言った大きな欠点があります。DHEの演算性能や必要となるデータ量などECDHEに比べて全くメリットがない状況です。Secrecyを実現するためにDHEの需要がありました。幾つかのパテントがexpireし、X25519の利用も見えてきました。DHEのサポートを取りやめています。言って全くDHEを捨て去っていいかというわけではなく、ECDHEのバックアップとして必要です。TLS1.3ではFFDHEが取り込まれているので、ECDHEに何かあった時用に緊急避難用のアルゴリズムとして残しておく必要性があると思います。従ってFFDHEが使えない現状で、TLS1.2でのDHE利用には、私の評価は黄色(注意)を付けています。X25519はどうなのかX25519ができるまでの経緯を書いてみます。P-256の闇NIST-P曲線は1999年にNISTによって規定されました。規定にはNSAが関わったという話です。NSAの協力の元でNISTを策定を進め、2005年に規定されました。2006,7年頃にこの乱数生成仕様にはバックドアがあるのではないという研究発表が出てきました。Dual_EC_DRBGは、ある特定の2つの楕円曲線上の点を元に疑似乱数を生成していく仕組みです。バックドアとみなされていたのは、この2つの楕円曲線上の点の関係が計算できていれば、表に出ている乱数から生成器の内部状態を再現でき、次の乱数が予測できるというものでした。TLSでは内部の秘密鍵の生成にも疑似乱数を使用します。これが外部から予測できればアウトです。実際にNSAが本当にバックドアを狙って仕込んだのかは、わかりません。この2つの楕円曲線の点はNSAの技術者からNISTへ提案を受けたものだという証言が残っています。2004年にNSAから1000万ドルかけてRSA社のライブラリにこの擬似乱数生成を入れ込み、実際に販売してたことも判明しました。2013年のスノーデン事件で明るみになった情報の中にも、NSAが標準化作業に入り込み、バックドアの仕込みをやっていたことを匂わすような記述が見受けられたそうです。状況証拠的には真っ黒です。ほどなくDual_EC_DRBGは廃止され、使われることはなくなりました。これも楕円曲線のある一つの変数が、出どころのわからない数値にSHA-1ハッシュをかけて生成したものでした。現在これ以上のことはまだわかっていません。Dual_EC_DRBGの例を見れば、非常に疑わしいのは明らかです。WGからCFRGにNIST標準によらない鍵交換とデジタル署名用の楕円曲線暗号を選定するよう依頼が行われました。curves当初2ヶ月程度で選定を終わらせる予定が、様々な要望や提案が入り混じり、案の定大議論が沸き起こりました。最初の候補として採用されることになりました。これが今のX25519につながります。djb氏が考案したためパテントに対するリスクも小さく、係数も数学的判断を元に決定されています。ソフトウェア処理でもそこそこ高速できるように工夫され、できるだけ簡潔な演算ができるようになっています。NIST-P256は複雑で、サイドチャネル攻撃を回避して高速化をするためには、非常に苦労します。それとは、大きく性質が異なります。Ed25519と区別する関係になっています。curve25519/curve448と鍵交換のX25519/X448が仕様化されました。(EdDSA)として仕様化が完了しました。これでTLS1.3に向けてIETFが選定した楕円曲線が使える環境が整いました。比べてみるとこんな感じです。Edgeで既に使えるようになっています。ブラウザベンダーの危機感は大きく、クライアント側の普及は早いです。サーバは、OpenSSL-1.1.0系から使えるようになっています。X448はOpenSSL-1.1.1が必要です。現在、X25519がどの程度使われているのか、最近の計測結果を見つけましたので紹介します。1万で8.73%程度です。方はGoogle系のサイトが多いからだと思われます。P-256が86.9%の割合でした。来年末OpenSSL-1.0.2のEoLなので、OpenSSL-1.1.x系に入れ替えが進むと一気にサーバ側の普及が進むものと思われます。MS系のサービスがX25519が優先されるようにサービスを提供しています。気になるX25519の性能ですが、他の楕円曲線暗号の鍵交換とくらべてどうでしょうか?今月リリース予定のOpenSSL-1.1.1のpre6版で比較してみます(AVX/AVX2入りCPUです)。P-256より約1.5倍近く速いです。X25519は、OpenSSL-1.1.1でかなり高速化されているので、適切なセキュリティ強度で申し分ない性能が得られると思います。NISTの推奨楕円曲線にNISTじゃない楕円曲線暗号を策定したのですが、なんとこの成功を受けNISTがcurve25519/curve448を推奨楕円曲線として採用する予定であることを明らかにしました。800-186が発行されるでしょう。信じるか、信じないか、あなた次第です。P-256がMUST、X25519がSHOULDの実装になっています。高性能で程よい安全と、そして大きな安心を得られ、今後普及が見込まれるX25519を入れられないガイドラインは非常にもったいないなと個人的に思うのです。関するWhitePaperがいくつか公開されました。Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データがNSAによって盗聴されていることをうかがわせるものだったからです(「NSA、グーグルと米ヤフーのクラウドに「思いのまま」アクセスか--米報道」)。Googleのサービス内通信では、RPC(当時はStubby、後のgRPC)が使われていることはよく知られていました。TLSを使うようになったんだろうなぁ、と漠然と想像するだけでした。蓋を開けてみると、GoogleはRPCに特化したALTSプロトコルを独自に開発し、それを全面的に利用していたのでした。Googleが10年かけてフルスクラッチで作り上げてきたALTSとは、いったいどんなものなのか?詳細はまだ公開されていませんが、WhitePaperから読み取れるALTSの姿を書いてみたいと思います。Disclaimer本記事は、公開されている資料から筆者が読み取った内容を記載しています。ALTSの詳細な仕様や実装はまだ公開されていません。筆者の想定違いや読み間違いの部分もあるでしょう。筆者は、Google社とは一切関係なく、元社員や現社員からの情報も持ち合わせていません。従いまして、本記事の内容は、一切保証されませんので、お読みになる際はご注意下さい。サービスのネットワーク構成まずは、Googleサービスのネットワーク構成を見てみましょう。Cloud」のWhitePaperにその概要が記載されています。Deployment」に少し記載されており、そちらも参考になります。これらの情報を合わせて、今回関係ある部分だけを抜き出すと、以下のネットワーク構成のようになっていると思われます。location)を通ります。End)で行うといった2段構成になっています。Proxyを経由して、GFEで直接ハンドシェイクを行います。ProxyによるQUIC接続に構成を変えたところ、検索サービスのレイテンシが4%から7%以上も向上し、TCPを上回る性能改善だったと報告されています。WhitePaperには、GFEがTCPの終端も行うことも記載されているので、全てのクライアントがRELを通るわけではなく、クライアントから直接GFEに接続する構成も存在しているものと思われます。TLSとQUICの終端を担うGFEでは、DDoS防御の後にバックエンドのサービスへ負荷分散やルーティングを行います。Serviceの2つにルーティングされています。Security)が使われています。service間の通信でALTSが使われています。ALTSは、暗号通信とメッセージ認証だけ行う平文通信の2種類をサポートしています。Googleのデータセンタ間をつなぐWANを経由する場合、ALTS通信は暗号化通信ですが、Googleが管理しているデータセンタ内では、暗号化されずメッセージ認証だけの通信が行われます。これらは全て自動で判断されます。authenticationによるLayer3の認証が行われています。Tokenを付与し、受信側のホストでそのTokenの検証を行って認証を実現していると記載されています。Secretの2つから生成されています。secretを合わせたものから作成します。Plane間で再ネゴシエーションして更新されます。Spoofingなどに対する防御を実現しています。ALTSの特徴ALTSは、2007年よりGoogle内部で開発が始まりました。当時TLSはそれほどセキュアではなく(TLS1.2は2008年仕様化)、TLSの機能も十分でなかったため、Googleのサービス要件に合わせるためにスクラッチからサービス間通信のプロトコルを開発する道を選んだようです。TLSで不十分な点は、サーバ名といった名前とその命名スキームに強く機能が結びついてしまうことでした。それに対しALTSでは、複数の名前スキームが使えるようにして、マイクロサービスに適した柔軟性と簡潔性を実現しました。Buffer形式を採用しました。Bufferは、Googleサービス内部で多く使われています。ALTSの柔軟性は、ホスト名ではなくidentityをベースに認証を行うことにあります。このidentityは、従業員、物理マシン、プロダクションサービス、アプリ実行するWorkload等、ネットワーク上のあらゆるレイヤーのもの全てに割り当てを行い、通信の相互認証を可能としました。Googleは独自内部PKIシステムも構築しました。内部CAからこれらのidentityにALTS用の証明書をほぼ自動で配布し、初期化時に使えるようにセットアップし、頻繁に証明書の更新や失効操作も自動で行っています。いやはや、これすごいです。他にもALTSの特徴として、以下の項目が挙げられます。アプリ的には全く透過。開発者はALTSを意識しなくていい。サーバ・クライアント双方でセッション再接続(resumption)が可能で、複数のサーバ・クライアント間でセッション引き継ぎができる。アップデートで最新の暗号方式の導入やプロトコルのバージョンアップなどが容易にできる。ALTSのトラストモデルALTSのすごいことの一つに、物理ホストからアプリ・運用開発者まで含めたトラストモデルを構築していることにあります。ここでは、そのトラストモデルの仕組みについて書きます。Certificateの3つのレベルの証明書で構成されています。CAを持つ認証局のようなもので、その詳細は不明です。ServiceからMaster証明書、Handshake証明書へchainがつながり、Handshake証明書が、実際のALTSハンドシェイクで利用されるものです。証明書はidentityベースで発行されます。ALTS証明書発行の特徴として、signer(署名者)とissuer(発行者)の役割が別れていることです。ServiceにCSRを送ります。Serviceは、CSRにあるissuerとidentityの関係を署名します。IDなど)を付与し、自身の証明書も含めてHandshake証明書を署名・発行します。ALTS証明書は、TLSで使われているX.509証明書と全く異なる内容になっています。Workloadの3種類に別れています。それぞれGoogle従業員向け、ホスト向け、アプリ向けの証明書を表します。CertificateHuman証明書は、Google従業員がRPCを使う際に利用する証明書です。Handshake証明書が発行されます。Policyが配布されており、ATLSハンドシェイク中に証明書のissuerやidentityに応じてアクセス許可が判断されます。Policyでissuerやidentityをチェックしており、不正な権限によるALTS接続を拒否するようになっています。Master証明書を持っています。Handshake証明書を生成します。Handshake証明書のidentityは用途によって別けられており、一つのマシンは異なる複数のidentityを持つことができます。Master証明書の署名検証を行う構成も存在しているとのことです。CertificateWorkload証明書は、Googleで使われているクラスタ管理システムBorgと連携してアプリケーション間のRPC通信で利用します。このWorkload証明書が、アプリケーションによるサービス間のセキュア通信を実現する証明書です。Borgの構成では、BorgmasterがBorgletを通じてアプリケーションを実行するWorkloadを作成します。Master証明書からBorgmasterのHandshake証明書を生成します。これによって、BorgmasterはALTS通信が可能となります。Master証明書を生成します。Handshake証明書を作成・管理します。Workloadマシンに送付されると、Workloadのアプリは実行時にALTS通信が使えるようになります。これら一連の流れが、Borgの仕組みと連動して実現されています。Secrecyを利用していません(機能はサポートされていますが無効化されています)。その代わり、証明書に記載された固定の鍵情報を用いた鍵交換を行います。その際、証明書を頻繁に更新し、同一の鍵を長期に使わないようにしてリスク回避をしています。そのため、証明書の更新期間は非常に短く、以下のように種類によって異なっています。全て自動化されているからできる技です。ALTSでは、Human証明書だけ明示的な有効期限を持っています(20時間)。それ以外は、時刻同期の問題によって失効機能の障害が発生するのを避けるため有効期限を記載せず、CRL(証明書失効リスト)を使って直接失効管理しています。IDによって管理されます。Serviceに登録します。証明書の更新や事故時に明示的にCRLに登録して証明書を失効させます。このCRLのデータは、全てのサーバに配布されています。膨大なものと思われそうですが、数百メガのデータが圧縮によって数メガ程度になっているそうです。ALTSハンドシェイクALTSのハンドシェイクは、双方向認証のセキュア通信に特化するためTLSのハンドシェイクを効率化し、非常に簡略化したものです。再接続にはクライアント、サーバそれぞれでチケットを用いたセッションの引き継ぎができる拡張機能も付加されています。新規接続ALTSハンドシェイクは、ClientInit/ServerInitとClientFinished/ServerFinishedの4種類だけです。ハンドシェイクの詳細な仕様やフォーマットは公開されていません。ClientInit/ServerInitには、各種ハンドシェイクパラメータと証明書の情報が含まれます。Secrecyが使われていないので、鍵交換はClient/Server双方のHandshake証明書に記載されている公開鍵(ECDH:curve25519)を使って行います。ALTSは双方向認証を実現するべく、サーバ・クライアントは、それぞれの証明書を受信すると、失効情報やポリシーのチェックを行います。鍵交換で導出された共通鍵は、TLS1.3と同様にHKDF-Expand/Extract(RFC5869)を使って鍵スケジュールを行います。Function)によって、ペイロードメッセージの暗号化するレコードプロトコルの暗号シークレット、完全性をチェックする認証シークレット、次回再接続の際に利用するResumptionシークレットの3種類を導出します。最後のServerFinished/ClientFinishedは、ハンドシェイクが改ざんされてないことを確認するためのものです。これは認証シークレットとHMACを使って実現します。再接続用のチケットも送付します(後述)。クライアントはServerFinishedを受信したら直ちに暗号化通信を開始できるので、ALTSは1-RTTでアプリケーションデータを送付できることになります。ALTSのフレームフォーマットは、4バイトの長さフィールド、4バイトのデータタイプのフィールドに続いてペイロードが続きます。ペイロードの最大長は現在1Mバイトで、将来もっと小さくする予定だそうです。TLSと同様にペイロードのreply攻撃に備えるため、サーバ・クライアント双方でシーケンス番号の管理も行われています。ペイロードの暗号化の場合はAES-GCMとAES-VCM、完全性確保だけの通信ではAES-GMACとAES-VMACのいずれかが利用されます。AES-VCMはあまりなじみがありませんが、2007年頃に提案された暗号方式で、VHASHというユニバーサルハッシュを利用したAEADです。AES-VMACは、VHASHをメッセージ認証に使ったものです。クライアントResumptionALTSには、クラスタリング利用を前提とした再接続(Resumption)の仕組みが備わっています。Resumptionです。再接続用にサーバ#1からチケットをクライアントに送付します。Secretを暗号化したものです。Keyを使って行われます。Keyを共有しています。IDを持つ別のサーバ#2に再接続すると、あらかじめサーバからもらったチケットを付与してハンドシェイクを行います。Keyを共有しているので、チケットからResumptionシークレットを復号することが可能です。これを使ってフルハンドシェイクをせずにALTS通信を続けることができます。サーバResumptionALTSでは、クライアントResumptionの逆、サーバResumptionの機能も用意されています。Keyを共有しています。今度は、最初のハンドシェイクでクライアント#1からチケットをサーバに送っておきます。IDのクライアント#2からサーバに新規接続があった場合、サーバはチケットをクライアント#2に送ります。Secretを複合することができます。クライアント#2とは、新規接続だけどフルハンドシェイクなしにALTS通信を継続できることになりました。サーバResumptionは、複数の負荷分散装置で切り替えやルーティングの変更があった場合でも、配下のサーバへの再接続が新規接続にならないといったメリットを持つことができます。ALTSの制限事項ALTSには、その仕組み上いくつか制限事項があります。鍵の危殆化による成りすまし)攻撃を受ける可能性があります。Keyが漏洩して危殆化すると、他のホストに成りすましが可能になってしまうということです。Resumptionの利点を得るためであり、リスクを受容するしかないです。ハンドシェイクのプライバシーTLSと同様にALTSのハンドシェイクは平文でやり取りされるため、どのidentityがどこに接続しにいっているのかネットワーク中間者は見ることができます。Secrecyを無効にしています。Secrecyを維持できません。0-RTTALTSでもTLS1.3と同様に、0-RTTでアプリケーションデータの送付を実現することは可能です。Secrecyではなく、reply攻撃に対する脆弱性も持っています。ALTSはRTTが小さい環境で使われるので、あえて0-RTTを使う必要はないと判断し、0-RTTの機能を除いています。最後にこのようにALTSの設計や機能は、TLSに慣れていた目から見ると非常に気づきが多いものでした。今後、ALTSの詳細な仕様やオープンソース実装が公開され、標準化の動きが出てくることを期待したいです。その時にはGoogleは既に次の新しいものに移行しているでしょう。08:56RPCに特化したGoogleのセキュリティ通信ALTSとは何かTweet広告を非表示にするもっと読むコメントを書く2017-03-17書評:プロフェッショナルSSL/TLSごめんなさい、書いてたら長くなってしまいました。長文嫌いな方は避けて下さい。鹿野さんの名前を間違えてました。翻訳本のレビューします?時雨堂が出資してる出版会社が翻訳権を勝ち取ったのです。」とお誘いを受けたのが、そもそもの始まりでした。内容の濃さもさることながらあの分量とクオリティ、記述の正確さや厳密さに対して特に高いものが要求されるセキュリティ分野。初心者向けではないエキスパート向け。なんと大胆、少し無謀なことではないか?」との思いが正直頭をよぎりました。自分もちょうど17年半勤めた前職を辞めて転職した直後。遠慮がちに上司に伺ったところあっさりOKの返事。っ、理解のある上司で良かった、ホント感謝します。「レビューについては、一文一文を集中的にではなく、ざっと見ていただくようなものを」と控え目なもの。「いやいや、この本をざっくりレビューじゃ失礼です。見させていただきます。」と、少し自分にプレッシャーをかけつつ読み始めました。一晩作業してみて私からの返事。「第一印象として、まだ日本語訳としてこなれてない部分が多いなと思いました。2章で技術的に難しい記述になると英文の表現に引きずられて日本語の文意が取りづらいなと感じる部分が多くなりました。日本語訳を読みながら詰まったり、気になったところにコメントを差し込んだのですが、結局29ページで100個近くのコメントになってしまいました。」まぁ正直な感想です。これじゃ全然先に進まない。幸いに、技術的に間違って訳している箇所はかなり少なく、ちゃんと内容を理解して翻訳がされているのがわかります。これならきっと原書のクオリティを保ったまま翻訳本にできるはず、そう確信しました。その後、何章か同じペースでコメントを入れ進めたのですが、そのうち本業の方が立て込んでしまい途中でレビューが止まってしまいました。その間、鹿野さんから私のコメントに対する返事を頂いたのですが、驚いたことに監訳の方に丸投げするわけではなく、ちゃんとご自身で判断されて修正対応されてます。私のコメントが間違っていることもしばしばで、逆に鹿野さんから指摘を受ける始末。あれっ?エンジニアの方が編集者してるんじゃないか?マジそう思いました。そんなまま数ヶ月経った後、「原稿を更新しました」とのご連絡。うぅ、うっかりメール見落としてた。未レビュー章を片付けないとまずい、早速レビュー開始。「あれっ、めちゃくちゃ読みやすい。この章のレビューコメントがゼロ。「うそ、以前ならそんなことはないはず。「時間をおいてもう一度読み直そう。翌日、「やっぱりゼロだ。鹿野さん曰く、「思い切った編集方針に切り替えました。あかん、このままじゃ本当にレビューしているのか疑われてしまう。いう心配してしまうくらいの素晴らしい出来になりました。そんなこんなギリギリまでドタバタのレビューがかかってしまい、ご迷惑をおかけしました。SSL/TLS」が刊行されました。余談はこのぐらいにして早速本の中身について書いてみます。私は過去2年(2015/16)、セキュリティ・キャンプ全国大会でTLSを教える講義を担当してきました。各地から集まる若く優秀な学生さんに対してTLSをどう教えるのか、最も悩むところです。結局はいくら悩んでも、TLSのハンドシェイクの仕組みを学んでもらうことに落ち着いてしまいます。TLS仕様(RFC5246)自体は、ハンドシェイクやプロトコルフォーマットを規定するだけで、実はX.509証明書などPKIやAES、RSAなど暗号技術の仕様については、TLSで具体的な中身はほとんど含まれていません。これらは他への関連仕様として参照されており、IETFで扱うWGも違います。後ろ髪引かれるのは、狭義的(RFC5246)な見方では、キャンプではそれらを外部仕様としてTLSを支える土台としてスコープ外にせざる得ないことです。時間的にも、キャパ的にも、全部盛り込むのは無理があります。最終的にはこのスライドでごまかしています。それに対し本書では、これら全部引っくるめてTLSセキュリティを解説しています。秘密鍵の管理:「第8章デプロイ」な関係になります。全部を網羅するので扱う技術領域の幅が一気に増え、それぞれが深い内容を含みます。どんな専門家でも頭でわかっているつもりなだけで、いざちゃんとした成果物まで仕上げるとなると並大抵の労力ではすまないでしょう。パフォーマンス最適化までカバーしている。あぁもう凄いですね、と感服するしかありません。本書を購入し読み始めた方は、その広大な技術領域と膨大な量に圧倒される人も多いかと思います。個人的には、これから1章から読み始めることにしても、必ずTLSの技術領域に関する土地勘を意識することが大切だと考えます。読む部分・深く精読する部分などを決めて、ある程度メリハリのある読み方をすることをお勧めします。この本の凄いところ話がそれますが、実は先日社内から依頼を受けて「技術のスキルアップ、私のやり方」というセミナーを内部で開催しました。自分のこれまでの取り組みを振り返りながらあれこれメンバーと共に話をした実に楽しい時間でした。ブログの書き方」というセッションを設け、某メンバーのブログのビフォー・アフターを紹介しながらブログの書き方やアウトプットの重要性などの話をしました。その時のスライドの一部がこれです。自分が思うに、今回の本はまさにこれなんですよね。この本に対して私のスライドを比較するのはほんと失礼だと思いますが、この本の凄いところをこの図に関連付けて書いてみます。序文で著者自身がこの本の目的を「著者が時間をかけた分読者の時間は節約できるよう、著者が知っていることの中でも特に重要な内容を詰め込み、僅かな時間で同じ内容を理解してもらうことである。「特に重要な内容」を詰め込んでおり、上図の様におそらく著者はこの10倍、もしくはそれ以上の分量を調べ上げているはずです。その中から著書のコンテキストに合わせて絞り込み、体系化した内容にして書いているのだと思います。この作業自体は他の本でも行われており、特別なことでもないでしょうが、TLSやPKIなど過去20年分しっちゃかめっちゃかした技術領域を広く網羅した範囲で行ったのは凄いです。この本を購入することは、TLS/PKIに関連に重要な情報に辿り着くまでの調査とそれを理解するための時間を買っていると思って良いです。本当のエキスパートを目指す人は、ここに書いてあることが全てではなく、この裏に広大な技術領域が広がっていると思って下さい。11章以降は各実装の使い方になっていますが、これは「実際に検証して確認(エピソード記憶)」に該当する作業です。これまで学んだことが実際どう設定に反映されるのかここで結びつけることができます。私が思う本当に理想的なアウトプットだなと感心します。私は原著を所有していますが、実はこれまであまり中身を通して読んだことがありませんでした。使う時は、なにか調べ物をする時です。新しい脆弱性情報が公開されると全て新規のものは稀で、大概新しい手法に過去の脆弱性を組み合わせたり、改良したりしたものが多いです。その際はこの本が大活躍します。関連するインシデントや脆弱性を楽に探すことができ、その一次リンクが脚注に数多く掲載されているからです。日々発生する脆弱性やインシデント情報。いくらブックマークしていても少し経つところっと忘れてしまいます。検索で探し当てるにしてもS/N比が悪く効率的ではありません。忘れてしまった自分のブログに助けられることもしばしば。この本は本当に一次情報にこだわっています。書いてある内容・図・データも、その多くが一次情報からのエビデンスがあるものということがはっきりわかります。この一次資料へのポインターは、何事にも代えがたい情報です。受け取ることができます。近うちに商品ページからリンクが貼られるようです。解説やリンクがメルマガのニュースレターとして配信されてきます。普段いろいろアンテナを張っているつもりでも結構見逃しているものが多々あり、このニュースレターで助けられることも多いです。この本を読んで知識を得た方は、是非これで最新情報を得て下さい。良い事ばかり書いても書評にならないので、いくつかレビューしていて気づいた注意点を。11章以降の実装バージョン11章以降の実装で解説しているソフトウェアは最新のバージョンに追随していないものがあります。昨年末にサポートが切れています。使いましょう(実は一部OSディストリビューションではそのまま自社サポートの範囲内で継続利用しているところもありますが、個人的にはあまりお勧めしません)。suite系は異なっている場合があります。本文で解説されているFREAK攻撃などにより輸出グレードCipherは全てdisableされています。SLOTH攻撃の影響でSSLv2も完全に削除されています。なくなっており、本書で記述されている出力結果と異なる場合もありますので注意して下さい。翻訳版は原著のフォークをせず、原著の更新を待つというポリシーですので、しばらくは更新を待ちましょう。TLSに対する非常に高度な脆弱性の発見と公開がされてきました。私は原論文を読んでいたので、翻訳文を読んでいるときでも「あぁこの部分はこういう記述にしたのか」とか「これはこのことを指しているな」といったことを思いながら読むことができ、それほど違和感を感じませんでした。その記述は正確性を犠牲にせず、どこまでわかりやすく書こうとしているか、著者の工夫が見られるからです。訳文だけしか読んでいない読者だとどこまで理解ができるのかな?と少々不安に思いました。トリプルハンドシェイク攻撃」は、理解するのに最難関の部類に入るものです。これは翻訳の出来、不出来のレベルではなく、実は容易な文言で解説するにはこの辺が限界じゃないかと思えてしまうほどです。これ以上もっとわかりやすく書いて読者に伝えることができるか?自分でも全く自信がありません。これらの部分は、一度読んでもわからないからと言ってあきらめず、是非原論文にでもあたって欲しいなと思います。原著は、発行後も更新されています。記載の時期によって微妙に記述の仕方が変わっている部分もあります。技術的な整合性は取れているので問題はないのですが、RC4の危殆化やBEAST攻撃に関する部分など前半と後半で微妙にニュアンスが違っているなと読んでいて感じるところもありました。他にも、著者の過去ブラウザの挙動の改善にいろいろ取り組んだ時の経緯で、ブラウザのインターフェイスには結構厳しい表現で書いているところも見られました。この点、著者の努力の甲斐があってかこの領域、最近ではブラウザベンダー側の改善が著しい分野です。セキュリティインジケーター」で記載されているセキュリティアイコンの変更に関しては、翻訳本では最新ブラウザの画像を使っています(本文の更新自体は原著通りです)。これも今後の改訂が期待されるところです。頭から読んでいると文書の更新時期が想像でき、まるで継ぎ足しのタレを味わっているようで読んでいて味わい深いです。TLS1.3の改訂に向けて17章のまとめの文章は、私にとっても非常に考えさせられる文章です。まとめの章は、商品ページに全部が掲載されていますので購入前でも読むことができます。「TLSはこれまで欠陥が多く修正が重ねられてきたが、もともと完璧なプロトコルなどはなく、どんなものも同様の状況になりえる、これまで普及して成功を収めたプロトコルに希望を持とう」と書いています。TLSはこれまでの数多くの技術負債を抱え、かつ最大の後方互換が求められ安定的に動作することが求められるプロトコルです。衝突耐性が破られました。md5の歴史から2nd-preimage耐性が破られるまでは時間の問題でしょう。偽造RapidSSL証明書」を読めば予想できます。多大な社会的コストを払ってSHA-2の証明書に移行を進めたのはこういう過去の教訓を踏まえてのことです。マルウェア内で衝突計算が可能になるまでになっているようです。TLS1.3では、様々な機能の廃止や見直しが行われています。中身はほぼメジャーバージョンアップレベルであるため、バージョン名をTLS2.0やTLS4にするか、大きな議論に発展し最終的にTLS1.3のままで決着しました。通常その仕様を読んでもどうしてこのような仕様になったのか、その議論の経緯や理由が明確にかつ詳細に書かれていることは少ないです。本書を読めば、ここに書いてある脆弱性や攻撃を教訓としてTLS1.3の仕様が決められていることがわかるはずです。更新版が来れば、全てがこのTLSの技術負債を(完全ではないが)かなり一掃するTLS1.3の仕様につながっている、と理解する日が来るでしょう。以上、あまり書評にもならないことをつらつら書いてしまいましたが、実際この本が翻訳本として日本語で読めることは日本のエンジニアにとって本当に喜ばしいことだと思います。先に書いた通り、ここに書いて有ることは本当に重要なことに絞り込んだ内容であり、それ以外の部分がその裏に隠されています。いうことはこの本を使えば、残りの90%をさぐる非常に良い足がかかりになります。この本を教材とした勉強会を近いうちに内部で開始するつもりです。さぁ、メンバーが残り9割をこれからどこまで探ることができるのか、今から楽しみです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。