ITの窓辺から

三流IT技術者の日常

TLS通信の内容に迫る Lv1

TLS

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通信のパケットに迫り、どのようなやり取りが行われているのかを見ていこうと思います。