SSL / TSLの基本

自身のSSL / TSLについての理解を記録しておく。

当初の疑問:

SSLは誰が挙動を保証している？

• SSL通信はクライアントアプリケーションからTCPにデータ送信する前に、SSLを噛ます

• SSL ニアリーイコール TSL(SSLの次世代がTSL。どちらもセキュリティ掛ける規約)

• 実際のSSL通信は「公開鍵+秘密鍵と共通鍵の併用」

• プレマスタ・シークレット = 共通鍵のもとになるデータ

SSL通信の流れ：

1. SSL掛かったサイトを訪問する
2. サーバーがクライアントに公開鍵送る
3. クライアントはサーバーから送られてきた公開鍵で、自分が持ってる共通鍵に鍵を掛けて、サーバーに送る
4. サーバーは秘密鍵で鍵を開け、中に入っている共通鍵を取り出す
5. これ以降、クライアントとサーバーは共通鍵でデータに鍵を掛け、通信し合う。

わざわざ共通鍵を使うのは、その方が処理が速いから。双方がやり取りする間、ヘッダー（どんな暗号方式を使うかとか）とデータ（内容）を送り合っている。

公開鍵+秘密鍵が必要になるタイミングは、セッションごと？ 最初のSSLのサイトアクセス時は処理が遅くなってる？確認する方法あるかな。

とりあえず当初の疑問:

• SSLは誰が挙動を保証している？の答え。＝＞「 認証局」 というのがあって、そこが保証している。

• サーバー証明書：ここにサーバーの公開鍵 と 認証局の署名（= 秘密鍵で暗号化したデータ = 秘密鍵を持っているのは認証局だけ = 認証局が認定したと同義）が含まれている。

次の疑問:

• サーバー証明書に含まれる認証局の署名が本物かどうかは、エンドユーザーはどうやって分かる？（秘密鍵で暗号化したデータがどうなっていたら本物かどうか、どうやって分かる？）

認証局は「複数」ある

• クライアントのPCには最初から、ルート認証局の情報がいくつかinstallされている（今後も当分ルート認証局は同じであり続けるという事か）

• PCに入っているルート認証局情報と、サイトにSSLアクセスした時に受信したサーバー証明書に入っているルート認証局情報を照らし合わせて、一致したらそのルート認証局情報は信頼できる

＝そのルート認証局が保証しているサーバーも信頼できる

＝そのサーバーが配布している公開鍵を使ってOK

• よって疑問の＝＞サーバー証明書に含まれる認証局の署名が本物かどうかは、エンドユーザーはどうやって分かる？

は、「最初からPCに信頼できるルート認証局情報のリストが複数入っており、それと照合することで信頼できるかを判断する」 が答えとなる。