TLS通信の内容に迫る Lv1
HTTPS接続を受け入れる準備があるWebサーバにアクセスする際に通信としては何が起きているのか、詳細に迫っていきます。ただ、今回の記事ではタイトルの通りLv1ということで、とにかくブラックボックスを放置しまくった記事になります。
HTTPSはHTTP over TLSのことを指します。TLSプロトコル上でHTTP通信を行うことで、TLSプロトコルが提供しているセキュリティ機能を使用することができます。すなわちTLSプロトコルを理解すればHTTPSは理解できたようなものです。TLSプロトコルが提供している主なセキュリティ機能は以下の3種類です。
- 盗聴対策
- なりすまし対策
- 改ざん対策
この3種類の対策ができればセキュリティを確保した通信ができると現在は考えられています。HTTPSというと暗号化を連想するかもしれません。間違ってはいないのですが、説明が足りません。なりすまし対策でやっている処理がTLSプロトコルで完結するのかと言われるとそうでないところもありますが・・・。
盗聴対策
ここでいう盗聴とは、攻撃者にパケットをミラーリング等の手段で入手されることではなく、実際のデータ部分の内容を読み取られることを指します。
盗聴対策を行うためにはデータの暗号化を行い、復号化手段を持たない攻撃者にデータを読み取られないようにします。ここで広く用いられている暗号化方式は公開鍵暗号方式と共通鍵暗号方式です。これらの方式の詳細はこの記事では触れませんが、大きな違いは鍵配送問題に対応できているかどうかと、クライアントやサーバにかかる負荷の差です。まとめると以下の表の通り。
| 項目 | 公開鍵暗号方式 | 共通鍵暗号方式 |
|---|---|---|
| 鍵配送問題 | 現実的な処理レベルで対応 | 非現実的 |
| 負荷 | 高負荷 | 低負荷 |
CSS書くのが面倒でやっつけテーブルです。いずれ何とかしたいところ・・・。
まず鍵配送問題です。そもそも鍵ってなんだという話ですが、暗号化を金庫に入れることに例えると、鍵は名前の通り金庫を開けるための鍵になります。つまり通信を行う両者が持っていないといけないものです。少し考えるといくつかの問題があることが分かります。
1つ目は鍵の数です。通信を行う人が二人なら良いのですが、10人いたらどうでしょう。全員で同じ鍵を持つという手もありますが、鉄の結束を持つ10人であればお互いに全員を信頼することもできるかもしれませんが、例えばインターネットの世界では不特定の人が通信を行うため、同じ鍵を使い回すわけにもいきません。そうすると人数が増えるに連れて鍵の数が加速度的に増えていきます。
2つ目は鍵自体の配布です。鍵が攻撃者の手に渡ると暗号化する意味もなくなってしまうので、鍵は流出しないように管理する必要があります。ではどうやって鍵を渡すのでしょうか。鍵自体を暗号化して配布？その復号化のための鍵は？というように、鍵を安全に配布することはなかなか難しいのです。しかも1つ目の問題の通り、鍵の数は膨大になる可能性があります。
3つ目は鍵の管理です。何らかのコストを支払って大量の鍵をうまく配布できたとして、その鍵をずっと使い続けるのでしょうか。攻撃者に盗まれたり鍵を複製されたりする可能性もあります。鍵に何らかの問題が発生した時、またコストを支払って鍵を配布する必要があります。
共通鍵暗号方式は通信を行う人が事前に同じ鍵を共有する必要がある方式なので、この鍵配送問題が問題になります。公開鍵暗号方式は事前に同じ鍵を共有しなくても暗号化通信ができるように、数学的な観点から考案された方式です。じゃあ全部公開鍵暗号方式でやればいいじゃない、と考えたくなりますが、上記の表の通り公開鍵暗号方式はクライアントやサーバの負荷が大きいのです。これは暗号化や復号化のために複雑な数学処理を毎回行う必要があるためです。クライアント側はともかく、サーバ側は多数のアクセスを受け付けるためこれらの処理に必要なリソースが馬鹿にならないのが現実です。
そこでTLSプロトコルは、公開鍵暗号方式と共通鍵暗号方式のいいとこ取りをできるように構成されています。端的に書いてしまうと、事前に共通の鍵を公開鍵暗号方式で暗号化して配布し、その鍵を使って共通鍵暗号方式によりデータを暗号化します。負荷のかかる公開鍵暗号方式を使う処理を減らした構成というわけです。鍵の数が膨大になることは変わりませんが、TLSセッション単位で使い捨ての鍵を使用することになっているので鍵管理のコストは小さいです。
こうして無事に暗号化が行われ、盗聴対策ができました。
なりすまし対策
AさんがBさんに手紙を送るとします。手紙を受け取ったBさんは封筒に送り主がAさんと書いてあるのを見つけましたが、この記名は本当にAさんが書いたものだと確信をもつことはできるでしょうか。Aさんがこれから手紙を送ることを何らかの方法で知ったCさんが偽の情報をBさんに伝えるために偽装したのかもしれません。
同様のことがクライアントとサーバ間の通信でも発生し得ます。クライアントが接続したサーバは本当に意図したサーバでしょうか。
なりすまし対策にはデジタル署名という技術が使われています。TLSプロトコルじゃないのかよと言いたくなるところですが、デジタル署名の仕組みの元になる情報をTLSプロトコルにより準備します。アクセスの起点になるのは多くの場合クライアントなので、クライアントはサーバが本当に自分がアクセスしようとしているサーバなのかを検証する必要があります。ここで登場するのがよく言われるサーバ証明書です。
自分の身分を証明したいと考えているサーバは、アクセスがあったクライアントにサーバ証明書を送ります。サーバ証明書には自分のサーバ情報が書いてあるのですが、これだけでは手紙の例えと何も変わりません。そこでサーバ証明書にクライアントが信頼している第三者から「お墨付き」を貰った上でサーバ証明書を送ります。このお墨付きがデジタル署名になります。このお墨付きについても数学的な仕組みが利用されており、お墨付きの証を別の人が行うことができないようになっています。お墨付きのサーバ証明書を受け取ったクライアントは、アクセス先でなりすましが発生していないことを確信するわけです。
Webブラウザに信頼済み認証局という設定があります。この信頼済み認証局というのが信頼している第三者に当たります。
改ざん対策
これまでに書いた対策により、通信相手も確定できましたし内容を第三者に読み取られることもなくなりました。しかしAさんが送ったメッセージは正しくBさんのもとに届いたでしょうか。何らかの事故により文字がかすれたりして意味が変わってしまっていないでしょうか。
そこで登場するのが改ざん対策で、送った内容と受け取った内容が一致していることを証明するための機能です。具体的には通信する2者で共通の鍵を持ち、送信データに対して鍵を使った同一の処理を行い結果が等しくなることを確認することで、送信データと受信データが一致していることを証明します。改ざん対策で用いられている共通の鍵をメッセージ認証コードと読んでいます。共通鍵暗号方式と似ていますが、暗号化を目的としているわけではありません。
TLSプロトコルの中ではメッセージ認証コードを生成するための元になるデータのやり取りを行います。当然ながらメッセージ認証コードは通信者以外に知られてはいけません。攻撃者にバレた場合、元のデータを改ざんした上でメッセージ認証コードを発行することでこれらの仕組みを全て無効化することができるためです。
3種の対策には沢山の技術が使われている
3種の対策に関する概要を書きました。これらを実際に実現するために、かなりの数の技術が使用されています。私もそうだったのですが、これらの技術を別個に学ぶとそれぞれの関連性が分からず、結局バラバラな知識のままで理解が曖昧になってしまいます。次回はLv2として具体的にHTTPS通信のパケットに迫り、どのようなやり取りが行われているのかを見ていこうと思います。
PKIとその実装を学ぶ
8月は相当な忙しさで更新が滞っていました。業務システムに対するいくつかの新機能リリースに加えて、別システムで動作しているロードバランサのバグに派手に引っかかり、ロードバランスしている全サーバへのアクセスが数時間おきに不安定になるという酷い事態に見舞われていました。先週でようやく全て解決できましたが・・・。
で、本来の記事の流れではSquidでSSL Bumpすることを考えていましたが、今月のトラブルをきっかけに色々と調べていくうちにPKIやTLSの理解が不十分であることが自覚できました。丁度良い機会なので知識を整理しておこうと思いたち、ちょっと寄り道することにしました。
まずはSquidの話を続けてきたこともあるので、PKIの話をベースにしつつもHTTPSにまつわる話にフォーカスしていくつもりです。そして記事構成に悩むところですが・・・。今回はまず導入みたいな記事です。
PKIとHTTPS
PKIとは何かをすぐに説明できるでしょうか。この記事ではPKI単体についてはあまり触れませんが、インターネットという非セキュアなネットワークを介して通信を行う際に発生する以下の脅威に対応できる仕組みです。
- 盗聴
- なりすまし
- 改ざん
どう対応していくのは別の記事に任せるとして、PKIでは公開鍵暗号方式の仕組みを使用してこれらの脅威に対応しています。これは完全に正しいですが、HTTPSによる通信の詳細を知るためには公開鍵暗号方式のみの理解では足りません。
HTTPSのような暗号化通信の仕組みを解説する場合、多くは以下のような流れでしょう。
- 共通鍵暗号方式の仕組みの説明し、
- 必要な共通鍵の数の多さを語り、
- 公開鍵暗号方式の仕組みを説明し、
- 公開鍵暗号方式を使用する場合のシステム負荷の高さに触れ、
- HTTPSでは共通鍵暗号方式と公開鍵暗号方式のいいとこ取りをしている。
完璧な流れだと思います。ただ、それだけでは三流IT技術者としてはHTTPS通信において具体的に何が行われているのか分からないので、一つ一つの過程と実装を確かめていきたいと思います。次の記事から。
OpensslかWindows Serverの認証局機能を使ってプライベートCAを立てて、証明書や鍵の中身を見ながら理解を含めていく予定です。
何に使うのか
おそらくこれらをちゃんと理解したところで、通常のエンプラのインフラシステムで役に立つ回数はそんなに多くないはずです。とはいえ、暗号化通信が叫ばれる昨今、ハッシュ関数やTLSバージョンの陳腐化等、微妙に変化が激しい分野になりつつあります。さらにこれらの変更がかかった場合の影響範囲は甚大なので、それぞれの技術を正しく覚えておくことは役に立つでしょう。例えば最近で少しインパクトのある変更として、Office365に接続する際の暗号化方式としてTLS1.2以外受け付けなくなるというものがあります。
また、当然ながらWebサービスの開発者もこれらについては意識しておく必要があります。インフラ担当(ミドル担当)に丸投げしないように。
その他の雑記
はてなブログで記事を書くとき、編集を見たままモードで作成しています。GUIツールにHTMLのtable作成モードがないのでtable作成が本当に面倒です。私のHTMLの知識はHTML4.0とCSS2.1で止まっていますが、そろそろ表現の幅をつけていきたいところです。というか、はてなブログのCSSも何がどこに書いてあるのかよくわからないです。次の週末はデザインも弄ってみようかな。
