見出し画像

ブラウザの鍵マーク「HTTPS」ってなんだろう? 後半

こんにちはこぐまです。

HTTPSの後半です。

前回のまとめ

・公開鍵で暗号化したものは、(それとペアとなる)秘密鍵でしか復号化できない(鍵をあけられない)
・公開鍵で暗号化したものは、公開鍵で復号化することはできない。

上記2つの法則から、あなたから渡したい相手へ
共通鍵を(ほかの人に見られずに)安全に渡す方法が生み出されました。
(実際は、このあたりの詳細なシーケンスは多少違うのですが、それはまたいずれお話しできればと思います。私も記事を書いて、実はそうだったんだ~と新たに学んだことも多いです。不特定多数の人に見られたくないものを共通鍵と公開鍵暗号方式を利用して渡すという方法があるということを知っていただければいいかなと思います。)

さて、晴れてこれで、あなたと相手で同じ共通鍵を持つことができました。
当然ながら、共通鍵は、あなたと相手しかもっていないので、
本当に渡したいもの(パケット)にこの共通鍵で施錠して、相手めがけてインターネットに流せば、渡したい相手に届きますし、万が一渡したい相手以外に届いてしまっても、その中身を空けることはできませんね。
これが暗号化通信です。

あなたは安全に渡したい相手に荷物を届けられました。
これで、一安心ですね・・。
・・・
・・・
いやいや、実はかなりの落とし穴がここにあるのです。

その相手は、ほんとうに渡したい相手・・?

小さいころ、「姫ちゃんのリボン」という漫画がありました。
アニメ化もされて、SMAPがOPやEDを歌っていて、アニメも曲も個人的にとても好きでした。
主人公姫ちゃんは、自分にそっくりな魔法の国の王女様から、どんなものにも変身できるリボンをもらいます。そして誰かや自分のために、そのリボンを使って変身し、てんやわんやいろんな出来事が起こっていく・・という物語です。
このような変身系の物語は、たくさんあると思いますが、いずれにせよ、
自分を違う存在に偽装できます。
ちょっと嫌な書き方をしてしまいましたが、ネット上でもこの偽装が
行われているのです。
つまり、あなたが本当に渡したい相手と最初にやり取りする時点で、すでに相手が偽装していた場合、あなたが頑張って二人だけの共通鍵を作り、渡した荷物は、本当に渡したい相手ではなく、なりすました別の誰かに見られてしまいます。いわゆるフィッシングサイトというのはこの類を発展させたものになります。超問題ですね。

「AさんがAさんである」と証明する方法

これまでの説明の通り、あなたの箱が本当に渡したい相手に届かない可能性があります。これを防ぐには、あなたが渡したい相手が、本当に本物かどうかを最初に見極める必要があります。
さて、この見極めはどうすればいいでしょうか?

1.Aさんに「私はAさんだ!」と言ってもらう
→ これはあまり有効ではなさそうですね・・。
2.私とAさんしか知らない情報で確認する
→ これは少し有効そうですね。でも第三者が盗み聞きしていたら簡単に破られちゃいそうですね。
3.国や組織、警察官等が持つ公的機関が「あなたはたしかにAさんですね」と断言する
→ これはかなり有効そうですね。知人友人ではなく、公的に正当性が証明されるということがポイントです。

ということで、インターネットの世界でも、AさんをAさんと断定するには、
3のような形を用います。
つまり、インターネットの世界の中で、管理機関みたいなところから、
「この人はたしかにAさんだ」とお墨付きをもらうわけです。
あなたはが荷物を送り届けたいAさんが、たしかに世界的にも認められたAさんであることを把握してから、先の共通鍵の連携を行います。

ITの言葉でいえば、「管理機関みたいなところ」=「認証局(CA)」といいます。認証局は1か所ではなく、たくさんありますが、基本的にはAさんは
そのいずれかの認証局で証明してもらうことになります。

さて、Aさんが認証局に、自分自身がAさんであることを証明する(お墨付きをもらう)ためにはどうしたらいいのでしょう?
これは結構簡単で、自分の身分証明書を要求するのです。
その流れを説明します。

「ぼくはAです。ぼくの情報をいろいろ送るので、ぼくの身分証明書をつくってください。」

認証局(CA)にこのように要求することを証明書署名要求(CSR)といいます。
この時に必要なのは、Aさんの公開鍵各種申請情報(ドメイン情報等)です。インターネットのURLは、「(https://)xxxxxxxxx.jp」みたいになっていると思いますが、あなたがAさんに荷物を送りたいときは、このURLめがけて送るわけです。このxxxxxxxxとなっているところをドメインといいます。
これは、Aさんが自分で名付けた名前で、世界で唯一のものです。
重複した名前は許されないため、早い者勝ちです。この名前を管理している会社をレジストラと言いますが、ちょっと別の話になるのでここでは割愛します。とにかく、ドメインを管理してくれる会社があるということです。

さて、認証局は何をやるかというと、この登録されているドメイン(Aさんが自分でつけた名前)と、Aさんから来た証明書署名要求(CSR)の情報から、そのドメインの所有者が本当にAさんであるかどうかを審査します。
そして、審査に合格した場合、
「はい、あなたは確かにAさんで、インターネット上にて「(https://)xxxxxxxxx.jp」という名前で活動されていますね!」と認識されるわけです。その証明として、SSLサーバ証明書(デジタル証明書)を付与されます。
この時、「あなたが確かにAさんであることを○○認証局が証明しました!」という認証局のお墨付きのために、認証局の秘密鍵でサインをします。これをデジタル署名と言います。認証局の秘密鍵でサインをするということは、そのSSLサーバ証明書は、認証局の秘密鍵で暗号化されるということです。

これでAさんは晴れて「認証局の署名済み(認証局の秘密鍵で暗号化された)SSLサーバ証明書」を手にしました。
なお、この認証局の秘密鍵で暗号化されたSSLサーバ証明書は、認証局の公開鍵で復号できますね。
なので、確かに自分が申請を送った認証局によってお墨つきをもらったことも確認できます。

あなたはSSLサーバ証明書を通して、確かに相手がAさんであると認めると同時に、Aさんを認めた認証局も認める。

さきほどまではAさんと認証局のやりとりでしたが、
ここからはあなたとAさんのやりとりになります。

あなたがAさんに荷物を届ける要求を最初に行ったとき、Aさんは「認証局の署名付きのSSLサーバ証明書」をあなたにおくります。
つまり、自分自身(Aさん)が公的に証明されたという「証」をあなたに送り、あなたを安心させてくれるわけです。

「認証局の署名付きのSSLサーバ証明書」を受け取ったあなたは、その正当性を確かめます。この時の観点は2つです。

1.「認証局の署名付きのSSLサーバ証明書」を「認証局の公開鍵」で復号できるかどうか。
2.Aさんへのお墨付きを与えた「認証局」自体を認められるかどうか。

1については、認証局の公開鍵は「公開」されている鍵なので、2でも紹介しますが簡単に手に入ります。その公開鍵を用いて、Aさんから送られてきた「認証局の署名付きのSSLサーバ証明書」を復号し、SSLサーバ証明書を取り出せれば完了です。(正確には、「元データ」と「ハッシュ値を秘密鍵で暗号化したデータ」の2つがあり、元データからはハッシュ値を、暗号データは認証局の公開鍵で復号してハッシュ値を求め、その値が一致することを確認しますが、ちょっと難しいので割愛します。)

2については、実は、最初から信頼されています。誰が信頼しているかというと、あなたの利用しているブラウザです。
ブラウザには最初から信頼に足る主要な認証局が登録されている(認証局自体のデジタル証明書が登録されている)ので、そこから公開鍵を取得することができます。この公開鍵は、1の「署名付きSSLサーバ証明書」の検証に利用します。簡単に取得できるというのはこのことです。
(実は認証局にも階層構造があり、一番上の認証局のことをルート認証局とよびます。階層構造になっている子、孫の認証局は、上から連鎖的にその存在を証明されていることになります。)

そして、ここまですべてが準備できた通信がようやく「https://・・・」
となるわけです。鍵マークです。

まとめ httpsとは「相手を確かに認めて、秘密に送る」こと

HTTPS通信するための条件は2つです。

1.通信の暗号化(あなたのAさん以外には中身を確認できない仕組み)
→ 公開鍵、秘密鍵、共通鍵を用いて実装
2.Aさんの真正性の証明(Aさんという存在が確かに認められた存在であること)
→ SSLサーバ証明書、デジタル署名で実装

上記2つが満たされている場合、「https://・・」(鍵マーク)が付きます。
相手を確かに認めて、秘密に送ること」・・これがHTTPSです。

そして、2のSSLサーバ証明書についてはグレードがあります。
存在証明レベルと言えばいいですかね。

グレード1(DV)・・・あなたがアクセスしようとしているドメインの持ち主が確かにAさんであることを証明する。
グレード2(OV)・・・Aさん(というか企業A)の実在まで確認する。
グレード3(EV)・・・企業Aの在籍確認、会社運用情報等まで確認する。

鍵マークをクリックし、「この接続は保護されています」の右の矢印を押下します。

そして、以下のように表示されればグレード1「DV認証」もしくはグレード2の「OV認証」です。
ちなみに、「note.com」はグレード1のDV認証です。

GMOなど、クレカ代行や金融取引などを行っている場所は、以下のように
発行元まで表示されます。これはグレード3の「EV認証」です。

「証明書は有効です」の下に発行元が書かれています。

DV認証とOV認証の切り分けが難しいですが、以下サイトでURLを入れればわかるようです。

ここで、URLを入れて、「organization」の項目が出てくれば、OVもしくはEVです。
なので、ここでDVかそれ以外かを切り分けて、かつ、ブラウザでGMOのように発行元の会社名まで表示されていればEV認証、いなければOV認証ということになります。

詳しく知りたい方は以下のサイトにも書かれておりますので是非ご参考に!https://www.antiphishing.jp/news/info/certificate_checker_20220906.html

ということで、まとめてみました!
自分自身かなーり勉強になりました!
公開鍵基盤について、暗号化について、SSLサーバ証明書のグレードについて、いろんな役にたつ解説記事ありますので、ぜひぜひ調べてみてください。
私のnoteも、後々イメージ図などつくって更新していきたいと思います。

読んで下さってありがとうございました!

この記事が参加している募集

この記事が気に入ったらサポートをしてみませんか?