SSL(現：TLS)鍵の交換の仕方の解釈があっているのでしょうか？また、質問もお願いしますm(__)m

以下で説明します。
A社：会員システムWEBサーバを提供
client：A社のシステムを利用するクライアント
CA：認証局

手順
1.A社はまず自社内で公開鍵と秘密鍵を作成
2.CAを選び申請し公開鍵だけを渡す。これでA社はサービスを公開できる状況
3.clientはA社のサーバとコネクション確率しログインページへ
4.A社は自分の公開鍵があるCAのIPアドレスをclientに配布
5.clientはA社が使用しているCAから公開鍵をもらう。（公開鍵は暗号通信後どうなっているか？）
6.client内で入力したログイン情報を公開鍵で暗号化してからA社サーバへ送る
7.A社は公開鍵で暗号化されたclientのログイン情報を受け取りA社だけが持っている秘密鍵で暗号を解く（複合っていうのかな？（笑））

結果ログイン情報は悪意のある第三者から盗聴されることはあっても、秘密鍵がない限りわからない。

質問

・5の（）で囲んでありますが、暗号化通信が終わった後の公開鍵は削除されるのでしょうか？また、ログイン情報などを送るために残しておくものなのでしょうか？

・今年1月1日にSHA-1（暗号方式と捉えています。）の廃止というものを聞いております。これは鍵を作成する際のことを言っているのでしょうか？

・なぜわざわざCAを経由しているのでしょうか？A社が公開鍵を送ればいいと思うのですが…（これについては下記で考察として書いています。）

考察（質問も含まれています）

恐らくですけど、本当にそのA社のサーバであるか確認するため。
例えば、A社のログインページの時に本当にそのページはA社のものなのかというのを確認するためですか？
悪意のある第三者がA社のシステムのログインのページのリンク先を変えても、これにより守られると考えていいのでしょうか？
A社のクライアントのログイン情報を盗むため非常によく似た悪意のあるサイトを作っている第三者（Bさん）が
A社が登録していないCAにSSLの申請したとします。
clientはそこにアクセスしてもCA側はBさんの正しいサーバですと返してるだけでわかりません。このようなことは実際に起きているのでしょうか？

よろしくお願いしますm(__)m

行動規範の内容に同意します

回答3件

ベストアンサー

SSL/TLS 一般ではなく、https に限定したほうがわかりやすそうなのでそうしますが、他のプロトコルでも以下の議論は一緒です。

さて、正しい手順を書きます。
1.A社はまず自社内で公開鍵と秘密鍵を作成
2.CAを選びCSR (公開鍵の入った証明書の申請用データ) を送り、認証してもらいます。認証してもらった証明書を WEB サーバに設定します。これでA社はサービスを公開できる状況
3.clientはA社のサーバとネゴります。具体的には証明書をもらい、証明書が正しいかチェックします。ブラウザに埋め込まれているルート CA に認証された CA に認証された CA に認証された ... CA に認証された証明書であれば、正しい証明書と判断し、中の公開鍵を利用します。clientはA社の公開鍵で暗号化した新規の共通鍵を生成してA社に送ります。A社しか知らない秘密鍵で復号して共通鍵を取り出し、これにより以降はclientとA社しか知りえない共通鍵で暗号化して通信します。コネクショログインページへ

こんな感じでしょうか。

追記

・暗号化通信が終わった後の公開鍵は削除されるのでしょうか？また、ログイン情報などを送るために残しておくものなのでしょうか？
公開鍵はキャッシュされることもあると思いますが、毎回入手すればいいものなので残す必要はありません。公開鍵暗号は計算コストが高いので、その後のセッションで使う共通鍵を交換するためだけに使います。

・今年1月1日にSHA-1（暗号方式と捉えています。）の廃止というものを聞いております。これは鍵を作成する際のことを言っているのでしょうか？
SHA-1 は暗号方式ではなくて、ハッシュアルゴリズム（ダイジェストアルゴリズム／一方向関数）の一つです。暗号は復号できる、つまり、元の平文に直せるアルゴリズムですが、ハッシュは別名「一方向関数」にもあるように、もとに戻すのが非常に困難であるアルゴリズムです。
PKI (公開鍵暗号に基づく通信基盤) において、ハッシュは公開鍵暗号と並ぶ重要な要素です。通信の秘匿ではなく、署名、すなわち、通信の内容を書いた人が、確実に秘密鍵を持っている人であることを確認するために使われます。
具体的には、送りたいメッセージのハッシュを計算し、それを秘密鍵で暗号化したもの、それを署名と呼びます。署名付きのメッセージを受け取った人は、メッセージのハッシュ値と署名を復号化した値を比べ、等しければ、確かに秘密鍵を持った人が書いたメッセージであると判断できます。

・なぜわざわざCAを経由しているのでしょうか？A社が公開鍵を送ればいいと思うのですが…
通信中に CA を経由しているわけではありません。ブラウザが「これは信用できる CA だ」としてるルート証明書を持っており、A社がclientに渡す証明書には、それを認証した CA を認証した CA を認証した CA ... とたどっていって、ルート証明書にたどり着けばA社の証明書を正しいと判定できます。
ブラウザによっては組み込みの証明書が違います。モバイル端末を含む多くのブラウザに組み込まれれているルート証明書の CA は、「より信頼されている CA」というわけです。これが、CA によって値段がかなり違う意味でもあります。

よろしくお願いしますm(__)m　

投稿2016/02/23 04:24

編集2016/02/23 04:46

unau

総合スコア2468

mint.cherry

2016/02/23 04:35

回答ありがとうございます。鍵の流れしか調べていなく勉強不足でしたm(__)m unauさんの回答情報をもとに証明書というものも調べたいと思います。 > CA に認証された CA に認証された CA に認証された ... CA に認証された証明書であれば、正しい証明書と判断し CAはツリー上になっているということなのでしょうか？つまり最上位CAがいてそれが認められたCAを基本的に私たちが利用しているということでしょうか？

unau

2016/02/23 04:47

元の投稿にあった質問への回答を追記しました。

mint.cherry

2016/02/23 11:21

返信追記ありがとうございます。少し時間はかかりましたが、鍵証明書のこと少し深く勉強したのち読ましていただきました。たいてい理解しました。私もいろいろとかんちがいしていたのがすっきりしました。

unau

2016/02/23 19:46

SSL/TSL クライアントには、証明書の管理ツール・管理機能が付属していると思います。そこで「これは信頼できる」という最初から入っている「ルート証明書」が見られます。Google Chrome で言えば、[設定]→[HTTPS/SSL]→[証明書の管理]→[信頼されたルート証明機関] で見られます。今、自分のところで見たら 60 個くらい証明書が入ってました。IE (たいていのバージョン) だと、[設定]→[インターネットオプション]→[コンテンツ]→[証明書] で見られます。ガラケーでも見られ、私の GRATINA だと [機能設定]→[プライバシー／制限]→[証明書設定]→[ルート認証局] で見られ、41 個の証明書が入っていました。ブラウザで https なページを見ているとき、たとえばこの teratail を見ているとき、アドレス欄に鍵マークが出ていると思います。それをクリックすると、証明書の情報が見られます。誰が発行したどういう目的の証明書で有効期限はいつまでか、など。さらに、ルート証明書からどうやって認証されたかも表示されます。今、Chrome で確認してみたら、「*.teratail.com」の証明書は「RapidSSL SHA256 CA - G3」が認証しており、さらにこの CA の証明書を「GeoTrust Global CA」というルート証明書が認証しているのがわかりました。証明書にはどんなことが書かれているか、確認してみるといいのではないでしょうか。

unau

2016/02/23 20:02

余談ですが、公開鍵暗号を用いた通信基盤としては、「この CA は絶対信頼できる」というルート CA を「信頼の起源」とする、すなわち「権威による信頼の起源」に基づく PKI (SSL/TSL はこっち) の他に、「自分を信頼の起源」とする PGP などもあります。「どの通信相手（の公開鍵）を信頼するのか」というときに、全部の公開鍵の信頼度を管理することは現実的でないので、「信頼できるものが信頼しているものは信頼できる」という信頼の連鎖によって公開鍵の信頼性を担保するわけですが、その連鎖の起源になる最初に信頼すべきもの、が、PKI では「社会的に考慮してここは間違いない」というルート証明書であり、PGP では「自分がこの人は間違いない」という相手の公開鍵になります。

行動規範の内容に同意します

確かに、公開鍵を自前で用意してそれを直接相手に渡す、という方法では、その公開鍵の信用性をどう検証するかという点がネックになります。そこで考えられたのがPKIと呼ばれる、第三者による署名を使った仕組みです。

A社が秘密鍵と公開鍵を生成する
ドメインexample.comに対して公開鍵Yを使った証明書の発行をCAに依頼する
CAは依頼者の希望する証明書の内容について審査を行う

（ドメインの持ち主かどうか、本当にその企業か、など）
4. CAが依頼通りの証明書を作成し、CAの秘密鍵で署名を行い、できあがった証明書をA社に送る

そしてクライアントが接続する時には、

サーバーはクライアントに自分の証明書を送る
クライアントは証明書の内容（接続先のドメイン、有効期限など）を確認する
またクライアントは信頼できるCAの証明書のリストを持っているので、それらのCAによって署名されているかどうか、手持ちの公開鍵で署名が検証できるかどうかを確認する
全ての検証に問題がなければ乱数Aを生成し、サーバー証明書に含まれる公開鍵で暗号化して送る
互いがその乱数Aから共通鍵を生成し、それを使って以後の通信を行う

という流れになっています。ご質問に対するポイントとしては、

証明書の信用性はCAが審査する
審査に問題がなかったか、つまりその証明書が信用できるかどうかは、クライアントの持っているCAの証明書で検証することができる
本命の通信は毎回ランダムに生成される共通鍵で暗号化される

（公開鍵暗号と比べて処理コストが小さい、場面に応じて最も強力な暗号方式を使える、等々）

というところにあります。これが一般的なSSL通信です。

http://itpro.nikkeibp.co.jp/article/COLUMN/20071002/283518/

※同じ公開鍵暗号でもSSL以外のプロトコルではもっと単純なものもあります

今年1月1日にSHA-1（暗号方式と捉えています。）の廃止

SHA-1はハッシュアルゴリズムと言われるもので、任意長の入力データを元に160ビットのハッシュ値を生成します。このアルゴリズムは入力データがわずかにでも変化するとハッシュ値も変化し、一方ハッシュ値から元のデータは計算しにくく設計されているため、元データの改ざん検知に使われます。

SSL証明書の場合はCAが署名をする際、証明書のデータから生成したハッシュ値に対して署名を行います。もし同じハッシュ値を持つ証明書を作ることができれば、「署名の正しい」証明書を偽造される可能性が出てきてしまいます。

http://www.atmarkit.co.jp/ait/articles/0603/09/news117.html

SSL証明書におけるSHA-1の廃止というのは、今後発行する証明書にはSHA-1は使いませんよ、という話です。基本的には素直にSHA-2で発行してもらえばよいのですが、古いガラケーなどはSHA-2に対応していないこともあり、その場合今後発行される証明書では通信ができなくなります。

A社のクライアントのログイン情報を盗むため非常によく似た悪意のあるサイトを作っている第三者（Bさん）がA社が登録していないCAにSSLの申請したとします。

SSL証明書を発行する際、通常最も緩い審査がドメイン認証です。これはドメインの所有者であることを確認したうえで証明書を発行します。具体的にはDNSサーバー上に指定されたレコードを設定したり、ドメイン所有者に対してメールを送ることでこの確認が行われます。故に、ドメインの所有者でない第三者がそのドメインに対する証明書を取得するのは困難になっています。

高価なものになると、帝国データバンクや登記簿で企業の実在性を調べたりといったことも行います。

https://jp.globalsign.com/service/ssl/knowledge/types-of-ssl.html

投稿2016/02/23 05:34

unarist

総合スコア47

mint.cherry

2016/02/23 13:04

回答ありがとうございます。 URLで非常に勉強になりましたm(__)m ありがとうございます。すこしすっきりしました。 > 古いガラケーなどはSHA-2に対応していないこともあり、その場合今後発行される証明書では通信ができなくなります。まさにそのことが最近ありましたので気になっていました。 > ドメインの所有者でない第三者がそのドメインに対する証明書を取得するのは困難になっています初めに…ドメインについては知識不足ですいませんm(__)m 例えば、A社のドメインがaooa.comというドメインを持っていたとします。悪意のある第三者（Bさんが）aoooa.comというドメインを取得した場合ドメインは違います。CAに申請登録できますか？

unarist

2016/02/23 13:47

別のドメインであるaoooa.comの正規の所有者であれば、有効な証明書を取得することが可能です。それがドメイン認証SSLです。似ているドメインと勘違いされることを防ぐため、似た名前のドメインも本来の企業が取得してしまうということも行われますが、SSL証明書のレベルの対策としては企業認証SSL証明書やEVSSL証明書などの企業名が出る証明書を使い、ユーザーに目視判断してもらうという策があります。

行動規範の内容に同意します

SSL通信の中で、「公開鍵をCAまで確認しに行く」という過程はありません。

セットアップ段階

A社はまず自社内で公開鍵と秘密鍵を作成（ここはその通り）
A社の側で、自分の公開鍵とサーバ名など必要な情報を、A社の秘密鍵で署名したCSRを作成して、CAへ送信します。
CAで認証が完了すると、A社の公開鍵をCAの秘密鍵で署名した「公開鍵証明書」が発行されます。これをサーバにインストールして準備完了です。

通信開始段階

クライアントが通信しようとすると、A社のサーバから公開鍵証明書が送られてきます。
正しいCAの署名かは、CA自体の公開鍵証明書で検証できますが、これにも別な秘密鍵で署名がしてあります。
最終的には、ブラウザに入っている「ルート証明書」までたどり着けば、鍵の正しさのチェックは完了です。
正しいドメインに発行された証明書だと確認した上で、通信を開始します。公開鍵暗号を本文に使うと負荷がかかるなど不都合があるので、公開鍵暗号は最初に鍵を交換するための署名・暗号化だけに使って、あとの通信はAESなどの共通鍵暗号で行います（この鍵は、通信ごとにバラバラにすることが多いです）。
共通鍵を持っているのはサーバとクライアントだけなので、第三者が内容を知ることはできません。

質問への解答

1つ目: A社のサーバの公開鍵は全世界に向けて配信しています。なお、不正に証明書を入れ替えるのを防ぐために、ブラウザ側に記憶させて「同じ証明書」か確認する、ということも行われています。
2つ目: SHA-1は、データからハッシュ値（人間で言う「指紋」のようなもの）を取るためのアルゴリズムです。途中で何度か出てきた「署名」や、データが改ざんされていないかの検証などに使われます。
3つ目: 実際にA社から公開鍵を送信しています。