ぺーぺーSEのブログ

備忘録・メモ用サイト。

トップ > SSL > SSLめも

SSLめも

SSL

SSLの仕組み

TransportLayerSecurity（TLS）は、セキュリティーを要求される通信のためのプロトコルである。
当プロトコルは、しばしばSecureSocketsLayer(SSL)とも呼ばれている。
これは、TLSの元になったプロトコルがSSLだったことと、SSLという名称が広く普及していることによる。
SSLは、認証・暗号化・改竄（かいざん）検出の機能を提供する。
具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、SSL通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択される。

認証

SSLは公開鍵証明書に基づく認証を提供する。
公開鍵を使った安全な通信路を形成するための基盤のことを公開鍵基盤（PKI:PublicKeyInfrastructure）と呼び、SSLもPKIの一種。
公開鍵暗号方式ではRSAが有名。
SSLの一般的な用途では、サーバだけが証明書を提示し、クライアントがその正当性を確認する。
なりすましを防ぐために、証明書には認証局(CA:CertificationAuthority)による電子署名が必要である。
サーバ上には、サーバ証明書と秘密鍵があり、クライアントはサーバ証明書が取得できるようになっている。
サーバ証明書は、公開鍵に、信頼できる機関である認証局（CA）が署名したものである。
それでは、サーバ証明書に署名しているCAが信用できると、どうやって確信することができるのか？
実は、CAは他のCAに署名してもらっていてそのCAは・・・と、CAをさかのぼっていくことができ、CAの親玉であるルート認証局（ルートCA）がいくつかあって、それらルートCAの証明書はあらかじめWebブラウザに組み込まれている。
サーバ証明書にあるCAの署名からルートCAにたどれないCAが認証したサーバ証明書をブラウザが受け取った場合は、ブラウザが警告を出す。
ブラウザは、サーバ証明書に入っているCommonNameと接続しているドメインを比較して、サーバ証明書に書いてあるものと違うドメインのWebサーバに接続しようとしている場合は警告を出す。
ユーザーは、ブラウザのアドレスバーを見ることによって、自分が意図しているドメインのサーバと接続していることを確認できる

暗号化

共通鍵暗号に基づく暗号化を提供する。
共通鍵暗号方式では、3DES,RC4,AESなどが有名。
公開鍵暗号の処理は、共通鍵暗号方式の処理に比べて時間がかかるため、SSLでは、公開鍵暗号方式で共通鍵の受け渡しをして、実際のデータのやり取りは共通鍵暗号方式で行うような工夫をしている。

改竄（かいざん）検出

SSLでデータレコードを送信する際には、レコードのシーケンス番号、共通鍵、そしてデータからチェックサムを算出し、それをレコードに付加して送信する。
このチェックサムデータを元データに対するメッセージダイジェストと呼び元データが改変されていないことを確認・証明するために使う。
メッセージダイジェストのアルゴリズムで有名なものにはMD5,SHA1がある。

秘密鍵とサーバ証明書の作り方（OpenSSL編）

Webサーバがhttpsをしゃべるようにするためには、

      1. 秘密鍵ファイル
      2. サーバ証明書ファイル

の２つのファイルを作成する必要がある。

秘密鍵ファイルの生成

まず、秘密鍵を作成するためには、シード値（ランダムなデータ）と、パスフレーズ（俗に言うところのパスワードに相当）が必要になる。
パスフレーズは、後の手順で必要（再度入力が必要になる）だが、シード値は秘密鍵を推測するのがより困難になるために、ここで一時的に使われるだけのものである。

# openssl md5 * > seed.data

この例では、カレントディレクトリのファイルのMD5ハッシュ値をシード値にしている。

# openssl genrsa -rand seed.data -des3 1024 > secret-key.pem

先ほどのシード値を使って、秘密鍵ファイルsecret-key.pemが作成される。
このとき、パスフレーズの入力が促されるので、パスフレーズを入力する。
上記の例では、トリプルDESで暗号化された1024bitの鍵長の秘密鍵を作ってる。
この時のできるファイルsecret-key.pemは「-----BEGINRSAPRIVATEKEY-----」で始まって「-----ENDRSAPRIVATEKEY-----」で終わっている。

サーバ証明書ファイルの生成

サーバ証明書ファイルを取得するためには、まずCA署名してもらうCSRファイルを作成する。
次に、CSRファイルをCAに送って、署名してもらったものがサーバ証明書ファイルになる。
CAは、送付元の身元を確認してから署名する必要があるためCSR送付→サーバ証明書の受領の間に、会社が確かに存在しているという証明（会社の登記等）を求めてくる。

# openssl req -new -key secret-key.pem -out csr.pem

いろいろ聞かれるが、extra以降聞かれることは答えなくても良い（？）。
Emailアドレスも入力しなくて良い（？）。
具体的にどんなことを書けばよいかは、サーバ証明書を発行してくれる機関のサイトを参照のこと。
これで、csr.pemというファイルができる。
この時のできるファイルcsr.pemは「-----BEGINCERTIFICATEREQUEST-----」で始まって「-----ENDCERTIFICATEREQUEST-----」で終わっている。
これをCAに送付すると（最近では、Webフォームから送信するようです）署名されたファイルが送り返される。
受信されたサーバID通知メール中の「-----BEGINCERTIFICATE-----」から「-----ENDCERTIFICATE-----」までを切り取って、ファイルに保存する。

自己署名証明書の作成

上でも述べているように、信頼できる第三者であるCAに署名してもらわなくては、第三者に使ってもらうためには意味が無いのが、サーバにテスト的に証明書を入れる場合や、身内だけでSSLを使う場合もある。

# openssl x509 -in csr.pem -out server.cert -req -signkey secret-key.pem

これで、サーバ証明書ファイルserver.certができる。
以上の手順で、秘密鍵ファイルが出来上がりそれをWebサーバに組み込むとSSLサーバとして使用することができるが、このままだと、Webサーバの起動時に、秘密鍵を作成した時のパスフレーズを聞いてくる。
これにより、万一秘密鍵ファイルが盗まれた場合でも、パスフレーズを知らなければなりすますことができないことになる。
しかし、これではWebサーバを自動的に起動したい場合は不便。
そこで、

# openssl rsa -in secret-key.pem -out secret-key-nopass.pem

を実行することにより、パスフレーズを必要としない（暗号化されていない）秘密鍵secret-key-nopass.pemが作成される。
これを、secret-key.pemと置き換えれば、Webサーバ起動時にパスフレーズを聞いてくることはなくなる。
また、秘密鍵ファイルを作成する時に-des3オプションをつけなければ、最初から暗号化されない秘密鍵ファイルを取得することもできる。

参考：
http://www005.upp.so-net.ne.jp/nakagami/Memo/SSL/
http://ja.wikipedia.org/wiki/Transport_Layer_Security