あどけない話

Internet technologies

TLSのひみつ

セキュリティ

書くと約束したのは、かれこれ1年半前でしょうか。書こうと思えば、すぐ書ける内容でしたが、結婚の準備におわれてうやむやになったままでした。

まだ書いてほしいとのことだったので、2ヶ月ぐらい前に書きました。3月7日に公開されていたとは知りませんでした。orz

TLSのひみつ：

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: ※ アプリケーションのデータ