以下は、某メルマガに書いた記事です。
オリジナルはこちら
httpsのプロトコル（通信手順）解説の４回目です。
長々と続けてきたこの連載もやっとここで一段落です。
今回はhttpでも非常にわかりにくい鍵交換の仕組みについて解説しています。
今回もお楽しみください。
今回は、httpsの通信手順（プロトコル）解説の４回目です。 繰り返しになりますが、通信手順といっても難しいことをやるわけ ではありません。コンピュータ同士でのチャットのようなものです。 チャットと言ってわかりにくければ携帯電話のショートメッセージ による会話と言えばイメージしやすいでしょうか。 そのチャットを通してお互いに必要な情報をやりとりします。 httpsの場合であれば、「あんただれ？」とか「俺は暗号方式○○ か△△が使えるんだけど、そっちは？」などというやりとりを するわけです。 これを専門用語でプロトコルと呼ぶにすぎません。 今回はサーバ証明書の確認の次のステップである鍵交換について 解説します。 そうそう、最初に用語定義をしておきます。 クライアント： 今からサーバにつなぎたいコンピュータ。 一般的には家庭にあるＰＣのブラウザがクライアントとなります。 以下の図中ではこれを[ク] と記載します。 サーバ： 一般的にサーバとは単体で使うことを目的とせず、他の利用者や コンピュータにサービスを提供するコンピュータのことです。 ここでは、httpsでの通信を提供しているコンピュータを指し、 多くの場合、ブラウザでアクセスする先のWebサイトとなります。 以下の図中ではこれを[サ] と記載します。 1. 鍵交換 －－－－－ 鍵交換というのは、暗号化と複合に使う鍵を第三者に知られない ように相手に渡す方法を言います。 普通に考えれば、相手には伝わって、それ以外の人にはわからない ようにする方法なんてなさそうに思います。 実際、鍵を安全に受け渡しする方法は長い間見つかっていません でした。それを数学的アプローチで解決する方法を見出したのが、 デフィーとヘルマンによるDH法と呼ばれる鍵交換の方法でした。 その詳細はこの連載の「https その３（鍵交換）」で解説しま したので、詳しくはそちらをご覧いただきたいのですが、もの すごくおおざっぱに言えば、サーバ側とクライアント側で交換 した値を元にして、第三者には計算できない値を得る方法です。 3. 鍵交換の手順 －－－－－－－－ では、実際にはどんな手順で鍵交換を行うのでしょうか？ 1. [サ]→[ク] ServerKeyExchange 2. [ク]→[サ] ClientKeyExchange 最初にサーバ側は、ServerKeyExchangeのメッセージとしてDH法の 計算に必要なサーバ側の値を送信します。 次に、クライアント側は、ClientKeyExchangeのメッセージとして、 同様にクライアント側の値を送信します。 （厳密にはもう少し複雑ですが、解説が煩雑になるので省略します） これで互いに相手の値が得られたので、後はDH法に従って 計算をすることで、鍵交換ができました。 互いに値をあけっぴろげに送っているのに、第三者は計算できない？ と不思議に思われた方はこの連載の「https その３（鍵交換）」を 再読ください。 https://archives.mag2.com/0001678731/20181029064000000.html なお、鍵交換は上記のDH法以外にもRSA方式などいくつかの方法が ありますが、長くなりすぎますので省略します。 4. プリマスターシークレットから共有鍵へ －－－－－－－－－－－－－－－－－－－－ では、これで鍵交換ができたのだから、その値を使ってhttpsの暗号 鍵に...、とはなりません。 httpsではさらにもうひと手間をかけます。 ここまでは以前も書いた内容ですが、ここからが、httpsの共有鍵を 求めるキモとなります。 上記の鍵交換で得た値をプリマスターシークレットと言います。 この値を元に、マスターシークレットという値の得る計算をします。 わざわざ再計算するのは理由があります。 というのは、鍵交換の方式によってプリマスターシークレットの 形式というのは違っているのです。 もし、このままの形式で計算を続けようとすると、プリマスター シークレットの種別毎に別々の計算式を用意しなければなりません。 例えば、鍵交換の方式が３種、暗号化の方式が５種の場合、１５ 通りの計算式を個別に用意する必要があるわけで、さすがに効率が 悪すぎます。 そこで、マスターシークレットという統一形式の値を再計算して 求めておけば、その後は同じ手順ひとつだけで済むわけです。 なるほど、じゃあそのマスターシークレットがhttpsの暗号鍵に...、 といいたいところですが、これも違います。 今度は、鍵の大きさが暗号方式によってまるで違うことが問題に なります。 マスターシークレットだけでは、鍵として使える量に足りない場合 があるのです。 そのため、マスターシークレットを元に、キーブロックという別の データを再生成します。 このキーブロックというのはいくらでも必要なだけの量のデータを 得られる計算式ですので、暗号鍵に必要なサイズのデータを取り 出せるわけです。 そして、ようやく、このキーブロックから取り出した値がhttpsの 暗号用の鍵として使える値になるのです。 httpsって恐ろしく面倒臭い計算をしているのですね。 5. 暗号による通信の開始 －－－－－－－－－－－－ 以上の手順で暗号用の鍵を得ますと、いよいよ暗号化による通信 が始まります。 上記で得た暗号用の鍵をセッション鍵と言います。 セッション鍵は名前の通り、セッションの期間中だけ有効です。 ですが、httpsのセッション寿命って非常に短いのです。 どのくらい短いかというと多くの場合１秒以下という短さです。 試しに、Googleのページ（https://www.google.co.jp)を表示した ところ、12個のセッションが開かれていました。 あれだけ手間がかかる手順を、Googleのようなシンプルな画面を 表示するだけでも12回もやりとりするわけです。 普段何気なく使っているhttpsですが、実際にはこれだけの大変な 手間をかけて、実現しているのですね。 6. つまりhttpsとは？ －－－－－－－－－－－ さて、長い連載になったhttpsの解説ですが、まとめれば次の３つ のことを行っていると言えます。 ・暗号化の手順を規定することで、最新の暗号を使いやすくする。 ・証明書を確認することで、通信相手が正しいことを確認する。 ・経路を暗号化することで、通信内容をわかりにくくする 一般的には３つ目の効用が大きく取り上げられますが、それだけ ではないということは、ここまでの解説を読んだ皆さんならご理解 いただけると思います。 たとえば、 「証明書が適切ではない」などというエラーはなぜ出るのか？ 「バージョンが違う」とか「利用できる暗号方式がない」などと 言われて接続できないのはなぜか？ といったことも（なんとなくでも）理解できるようになったのでは ないかと思います。 さて、しつこいですが、httpsについては、もう少し補足したい点 もあります。 次回はhttpsの番外編として、これまで触れなかった事項について 解説したいと思います。 次回もお楽しみに。