SSLについてのまとめ（暗号化とサーバー認証）
SSLについて、初心者が調べたことをまとめます。
SSLとは
Secure Socket Layer（セキュアソケットレイヤー）
WebブラウザとWebサーバー間でやり取りする情報を暗号化して通信するためのプロトコルで、「SSL/TLS」や「TLS」とも呼ばれる。
インターネット上では、クレジットカード番号やユーザーID、パスワードなど、第三者に知られたらまずい情報がたくさんやり取りされている。これらの通信を、暗号化されていないHTTP通信で行った場合、盗聴や改ざんされてしまうリスクが大きい。そこで、SSLを用いた通信を行うことによって、大切な情報をインターネット上で安全にやり取りすることができる。
なお、SSLが利用されている通信は、URLの初めにhttps://が付いている、もしくはブラウザのアドレスバーに鍵マークが付いている。
※http://の場合は、SSL通信ではない。
SSLの機能
SSL通信には主に2つの機能がある。
データの盗聴や改ざんを防ぐ（暗号化）
データが盗聴されたり改ざんされたりするリスクを防止する。
なりすましを防ぐ（サーバー認証）
通信相手（サーバー）が信頼できるかどうかを確認し、なりすましを防ぐ。
暗号化の仕組み
暗号化は、通常は平文でやり取りされている情報を、当事者以外は分からない形式に変換すること。それにより、万が一第三者にデータを盗まれても内容を解読されることはない。
SSLでは、以下2つの方式を組み合わせて利用している。
- 共通鍵暗号化方式
- 公開鍵暗号化方式
「鍵」とは、暗号化したり復号化したり（暗号を元に戻すこと）するときに使うデータのこと。
共通鍵暗号化方式
データの暗号化と復号化で同一の鍵を利用する方式。
鍵は1種類しか存在せず、共通鍵で暗号化されたデータは同じ共通鍵でなければ復号化することができない。家の鍵みたいなイメージで、開けるにも閉めるにも同じ鍵を使う。
メリットとしては、1つの鍵で双方にデータのやり取りをするので、暗号化と復号化の処理速度が速いことが挙げられる。
一方、インターネットを使って安全に鍵を受け渡すのが難しいことがデメリット。受け渡しの際に鍵自体が盗まれてしまうと、あとから渡すデータ自体も盗まれた鍵で解読されてしまう。
公開鍵暗号化方式
データの暗号化と復号化で用いる鍵が異なる方式。
秘密鍵と公開鍵の2種類があり、片方の鍵で暗号化したデータはペアとなっている片方の鍵でないと復号化することができない。南京錠みたいなイメージで、開ける鍵と閉める鍵が異なる。
公開鍵暗号化方式では、以下のような流れで通信を行う。
※AさんがBさんから暗号化されたデータを受け取りたい場合を想定する。
- Aさんが公開鍵と秘密鍵のセットを作る。
- Aさんは公開鍵（閉めるための鍵）をBさんに送る。
- Bさんは受け取った公開鍵を使って送りたいデータを暗号化してAさんに送る。
- Aさんは自分の秘密鍵を使って受け取ったデータを復号化する。
公開鍵暗号化方式の一番のメリットは、開けるための鍵（秘密鍵）を外部に出していないこと。
上記の例で考えると、公開鍵（閉めるための鍵）が仮に盗まれてしまったとしても、秘密鍵（開けるための鍵）はAさんしか持っていないため、他人がデータを解読することはできない。
このようにして、公開鍵暗号方式ではデータを安全に受け渡すことができるが、一方で受け渡しが一方通行になってしまうというデメリットもある。相手と相互にデータをやり取りする場合は、相手にも別で公開鍵と秘密鍵のセットを作ってもらう必要があり、その分処理速度も遅くなってしまう。
SSL暗号化通信の実際の流れ
共通鍵暗号化方式と公開鍵暗号化方式のそれぞれのメリット・デメリットを踏まえて、SSLでは双方を組み合わせて使うことが一般的。
実際の流れは以下のようになる。
- クライアントがサーバーに対してSSL通信の要求をする。
- サーバーは自身の公開鍵が入ったサーバー証明書をクライアントに送る。
- クライアントは、入手したサーバーの公開鍵を使って「双方の暗号通信に使う共通鍵」を暗号化してサーバーに送る。
- サーバーは、自身の秘密鍵を使ってクライアントから送られてきた暗号化データを復号化して、共通鍵を取り出す。
- 共有した共通鍵を用いて、クライアントとサーバーは本来の目的であったデータのやり取りを高速で行う。
実際の暗号化データのやり取りには速度の速い共通鍵暗号化方式を使い、共通鍵の受け渡しのリスクを公開鍵暗号化方式でカバーするという構図になる。
サーバー認証の仕組み
フィッシング詐欺などのなりすましを防ぐために、通信相手となるサーバーが信頼できるかを認証するための仕組み。
以下のキーワードを抑えておくと良い。
- サーバー証明書
- 認証局（ルート認証局と中間認証局）
- 電子署名（デジタル署名）
前提知識
サーバ証明書とは
Webサイトの「運営者の実存性」を確認し、WebブラウザとWebサーバ間で「通信データの暗号化」を行うための電子証明書。SSLサーバ証明書とも言う。
サーバ証明書の発行にあたっては、「認証局」と呼ばれる組織への申請が必要。認証局は申請を受けると、対象のWebサイトのドメインの使用権の確認や、Webサイトの運営者（組織）の実存性の審査を行った上で、サーバ証明書を発行する。
サーバ証明書には、サーバ運営者の組織名、認証局の組織名、証明書の有効期限、サーバの公開鍵などの情報が書き込まれている。「実在する運営者（組織）によって運営されている本物のWebサイト」であることが認証局によって認証されることによって、ユーザーは自分がアクセスしたWebサイトを安心して利用できる。
認証局とは
コンピュータの世界における身元保証協会。暗号通信などで必要になる電子証明書（デジタル証明書ともいう）の発行を行う。サーバー証明書も電子証明書の一種。
認証局にはルート認証局と中間認証局がある。
ルート認証局
トップに君臨する認証局。他の認証局による認証を必要とせず、厳しい監査や運用実績、知名度などによって自分の正当性を自ら証明することができる。また、他の認証局に対して電子証明書を発行しして、認証局に対する信頼の拠り所にもなる。
中間認証局
ルート認証局以外の認証局。ルート認証局などの上位の認証局から電子証明書を発行してもらうことで自らの正当性を証明する。
電子署名（デジタル署名）
文書やメッセージなどのデータの真正性を証明するためにふかされる短い暗号データ。作成者を証明し、改ざんやすり替えが行われていないことを保証する。
公開鍵暗号化方式とハッシュ関数を組み合わせた仕組みで、メッセージの送信者は本文をハッシュした値を、本人しか知らない秘密鍵を使って暗号化して本文に添付し、相手方に送る。
受信者は添付されたデータを送信者の公開鍵を用いて復号化し、本文をハッシュした値と照合する。両者が一致すれば、メッセージが確かに送信者本人のものであり（秘密鍵は送信者しか知り得ない＆対になる公開鍵を使って復号化できたため）、かつ伝送途上で第三者による改ざんやすり替えが行われていないことが確認できる。
サーバ認証の流れ
上記の全体条件を踏まえた上で、サーバー認証の流れを見ていく。
サーバ認証の流れを一言でまとめると、クライアント（Webブラウザなど）は、サーバーから受け取ったサーバー証明書が、信頼のある認証局（複数の場合もある）による認証の手続きを経ていることを確認することで、そのサーバの信頼性を判断している。
サーバ証明書には身元保証として、自らを認証した認証局の電子署名が付いている。認証局の公開鍵を使って上記の電子署名を正しく復号できれば、ペアとなる秘密鍵を持っている認証局自身による署名であることがわかり、サーバー証明書がその認証局によって正しく発行されたことの証となる。
認証局の信頼性
認証局によって署名されたサーバ証明書があることで、サーバは自分の身元証明ができるわけだが、そもそもその署名をした認証局が本当に信頼できる機関なのかという問題が残る。
その問題を解決するのが、複数の認証局による認証の仕組み。実はクライアントにサーバ証明書が送られる際には、署名を施した認証局の証明書も一緒に送られている。もし、その認証局が他の認証局から署名を受けている場合は、さらにその署名をした認証局の証明書も付けて送られる。こうして、最終的には最上位に位置する「ルート認証局」の証明書が送られてくる。そこで、まずクライアントはこのルート認証局が信頼できるかどうかを確かめる。
通常、Webブラウザなどのソフトウェアには、信頼できるルート認証局の証明書があらかじめ同梱されている。このあらかじめ入っている証明書とサーバーから受信した証明書が一致するかどうかを確認し、一致していればこのルート認証局は信頼できると判断される。
ルート証明書が信頼できると判断されたら、次はルート証明書の中にある公開鍵を使って、ルート証明書から署名を受けた証明書を検証する。この流れで、すべての証明書を検証することで、サーバの信頼性に問題がないか確認していく。
※実際に、Chromeのアドレスバーにある「鍵」のアイコンをクリックすると、証明書や認証局の情報を確認することができる。
一番上にあるGTS Root R1というのがルート認証局で、一つ下のGTS CA 1D4というのが、ルート認証局からの認証を受けた中間認証局。
サーバー認証の実際の流れ（例）
最後に、サーバー認証の実際の流れを例でおさらいしてみる。
（サーバー証明書は中間認証局が発行し、中間認証局はルート認証局によって認証されている場合）
- SSL通信を開始する際に、サーバーがクライアントに対して、サーバー証明書、中間認証局の証明書、ルート認証局の証明書を送る。
- クライントはあらかじめ持っていたルート証明書の中から、今回送られてきたルート証明書と一致するものがあるか確認する。
- 一致していれば、信頼できるルート認証局の証明書であると判断できる。
- 続いて、送られてきたルート証明書から公開鍵を取り出し、中間認証局の証明書を検証する。
（中間認証局の証明書はルート認証局によって電子署名されているので、その署名をルート認証局の公開鍵で復号化する。） - 中間認証局の証明書をハッシュ化したデータと電子署名を復号化したデータが一致すれば、3で信頼性を確認したルート認証局から認証を受けた信頼できる中間認証局であることが分かる。
- 同様にして、中間認証局の証明書から公開鍵を取り出し、サーバー証明書を検証する。
- サーバー証明書が信頼した中間認証局から署名を受けていることを確認することによって、サーバーの認証が完了する。
- サーバーの認証が完了して初めて、クライアントは暗号化通信に使う共通鍵の生成を開始する。
※商用認証局から証明書の交付を受けるには費用がかかるため、Webサイトなどの中には、自らがルート認証局となって証明書を発行し、暗号化通信などに利用するサイトもある。そのようなサイトの場合、クライアントにあらかじめ同梱されているルート認証局による認証は受けていないことになるため、Webブラウザなどがその旨を警告するようになっている。
まとめ
SSL通信の目的は
- データの盗聴、改ざんを防ぐこと
- 通信相手のなりすましを防ぐこと
それぞれ
- 通信暗号化の仕組み
- サーバー認証の仕組み
を使って実現している。
SSL、奥が深すぎてビビりました。全体像が掴めるように意識して調べましたが、まだまだ分からない事だらけです。理解が間違っている箇所があればぜひご指摘ください🙇♂️
Discussion