読者です 読者をやめる 読者になる 読者になる

らっちゃいブログ

日々の学びと気づきを発信するブログ

非エンジニアのための SSL/TLS 入門(後編)

ssl/tls

スポンサーリンク

前編を読んでない方はまず先にお読みください。

racchai.hatenablog.com

『非エンジニアのための』というタイトルではありますが、ここから先は専門用語も登場します。

というより、専門用語を覚えることを目的とした内容にするつもりです。SSL/TLS に関してはエンジニアとのコミュニケーションが必要なことがよくありますので、専門用語を理解してそういった場面で役立ててほしいと思います。

早速ですが、ここから先は送信者をクライアント、受信者をサーバーと呼ぶことにします。エンジニア世界ではこれが共通語なのです。

よくわからなくても、がんばってついてきてくださいね。

サーバー証明書

前編で名刺と呼んでいたものは、正式にはサーバー証明書と呼ばれるものです。

その名の通り、サーバーが正しいことを証明するためのものです。何をもって正しいのか?という疑問については、後々わかるようになっていますので、ここではスルーしてください。

サーバー証明書には以下のような情報が記載されています。

サーバー証明書を作るには

申込書に必要事項を書いて、その申込書に認証局がサインしたものがサーバー証明書と呼ばれるものになります。

この申込書は正式には Certification Sign Request (以降CSR) といいまして、もちろん電子データです。

CSRを作るのはエンジニアの仕事だと思いますので、具体的な作り方については本記事では触れませんが、エンジニアにとっては誰にでもできる簡単なお仕事です。

CSRが用意できたら、次は認証局を選定します。

有名どころとしては、いまではシマンテックと名前が変わってしまいましたが、ベリサインと聞くとご存知の方も多いかと思います。どの認証局を選べばいいかわからないという方がいらっしゃいますが、よっぽどのサービスでない限りは国内シェアと価格の安さだけを基準に選んでしまって大丈夫だと思います。

認証局が決まったら、あとは認証局にサインを依頼すれば、サーバー証明書の完成です。

認証局のサイン

サインは一方向暗号(指紋)と公開鍵・秘密鍵のペアを使って作成される署名(電子署名)です。

公開鍵暗号ではなく公開鍵・秘密鍵のペアと表現したのには理由があります。

前編では「公開鍵は『閉める』だけのカギ、秘密鍵は『開ける』だけのカギ」と説明しました。

しかし実のところ、公開鍵と秘密鍵は同じ構造をしているので、どちらの鍵でも『閉める』ことができます。その場合、『開ける』ことができるのはもう一方の鍵だけになります。この特性を利用し、電子署名では秘密鍵を使って閉め、公開鍵を使って開けるという使い方をします。

実際にどう使うのかといいますと、認証局は受け取ったCSRから指紋を計算し、それを自身が持つ秘密鍵で暗号化するのです。この暗号化された指紋が署名となります。

公開鍵は公になっているわけですから、誰にでも開けられる鍵なんて何の意味があるのかと思われるかもしれませんね。電子署名では中身が誰に見られるかは重要ではなく、誰が鍵が閉めたのかを保証することを目的としています。ですので、『認証局にしか閉められない鍵が閉まっている』ということさえ証明できればそれで良いのです。

サーバー認証

サーバー証明書を受け取ったクライアントが、その有効性を確認することをサーバー認証と言います。

何を確認するかというと、以下の項目になります。

  • 有効期限

サーバー証明書に記載されている有効期限が切れていないかを確認します。有効期限は発行日から一年間というのが一般的です。

アクセスしたサーバーのドメイン名と、サーバー証明書に記載されたドメイン名が一致しているかを確認します。

信頼できる認証局なのか、そして本当にその認証局の署名なのかを検証します。

Internet Explorer等のブラウザ(クライアント)は必ず自身が信頼している認証局(の証明書)一覧を持っていますので、その中に該当する認証局が含まれていることを確認するだけです。 サイン自体の検証については、前述の通り『認証局にしか閉められない鍵が閉まっている』かどうかを確認できればよいです。 該当する認証局の証明書から公開鍵を取り出し、署名を複合化することができれば、それだけでサインが正しいものであることが確認できてしまいます。簡単ですね。

改めてSSLの通信を説明してみる

用語の理解ができたところで、前編で解説した内容を用語も絡めて説明してみます。

SSL の通信は共通鍵暗号を用いて実現しています。共通鍵暗号を使用するためには、クライアントとサーバーが同じ共通鍵を持っている必要があります。共通鍵を交換するため、暗号化通信の前にSSLハンドシェイクを行います。

ハンドシェイクでは、まずクライアントがサーバー証明書を受け取り、サーバー認証を行うことから始まります。サーバー認証ではドメインの確認、有効期限の確認、署名の検証を行います。署名は公開鍵暗号を逆に利用しているので、認証局の公開鍵で複合化することできるかを検証します。サーバー認証に成功したら、クライアントは共通鍵を作成して、サーバー証明書に記載されているサーバーの公開鍵を使って暗号化します。サーバーは暗号化されたデータを受け取り、自身が持つ秘密鍵を使って復号化することで共通鍵を得ることができます。クライアントとサーバーが安全に共通鍵を共有できたら、ハンドシェイクは終了です。

そこから先は共通鍵暗号を使って安全な通信を行うだけです。

まとめ

今回は専門用語を理解することを目的に記事を書いてみました。

細かいところを解説しだすととたんに複雑になってしまうため、ところどころ情報を省略したり場合によっては正確でない表現を使用したりしました。わかる人にとってはつっこみどころ満載な記事になっていると思います。自分から見てもそうです。

ですが、細かいところまですべて正しい理解をする必要はないと思っています。まずは大枠を理解することが重要で、そこから先はググるなり書籍を読むなどして必要に応じて理解すればよいのです。

ちなみに私はこちらの本をおすすめしています。結城さんの本はどれもやさしく解説してくれているので、エンジニアでなくても理解できるようになっています。ぜひ読んでみてください。

暗号技術入門 第3版 秘密の国のアリス

暗号技術入門 第3版 秘密の国のアリス