書くと約束したのは、かれこれ1年半前でしょうか。書こうと思えば、すぐ書ける内容でしたが、結婚の準備におわれてうやむやになったままでした。
まだ書いてほしいとのことだったので、2ヶ月ぐらい前に書きました。3月7日に公開されていたとは知りませんでした。orz
SSL(Secure Socket Layer)はラッパー(トンネル)として実装できるが、TLS(Transport Layer Security)はラッパーとして実装できないと勘違いしているエンジニアが多い。この記事では、(少なくともクライアント側では)TLS がラッパーとして実装でき、アプリケーションプログラムの実装を変更しなくても TLS が利用できることを示す。
率直にいって、僕は TLS は IETF の(数多い)失敗の1つだと思います。SSL の方が、遥かに優れています。
ただ、TLS の設計思想自体が誤解されているのはよくないと思い、書いてみました。
SSL/TLS の詳細
TLSのひみつには書きませんでしたが、折角なので SSL/TLS の詳細を載せておきます。※ の部分は、SSL/TLS によって暗号化されているという意味です。
C→S: {公開鍵暗号,共有鍵暗号,セキュアハッシュ関数}の候補 [ClientHello] S→C: セッションID, {公開鍵暗号,共有鍵暗号,セキュアハッシュ関数} [ServerHello] S→C: サーバの証明書 [Certificate] S→C: 第一段階終了 [ServerHelloDone] C: サーバの証明書の検証 C: 乱数の生成 C→S: サーバの公開鍵(乱数) [ClientKeyExchange] C→S: 通信路の暗号化開始 [ChangeCipherSpec] C→S: ※ セキュアハッシュ関数(クライアント定数+乱数) [Finished] S: 乱数を共有できたことの確認 S→C: 通信路の暗号化開始 [ChangeCipherSpec] S→C: ※ セキュアハッシュ関数(サーバ定数+乱数) [Finished] C: 乱数を共有できたことの確認 C: サーバ認証:サーバが秘密鍵を持っていることの確認 C→S: ※ アプリケーションのデータ S→C: ※ アプリケーションのデータ