HTTPS(SSL)の仕組みとセキュリティについて

質問

SSLの仕組みと，そのセキュリティについての質問です．

現在，HTTPSで利用するSSLの仕組みについて勉強をしています．

しかしながら，
自身がSSLの仕組みについて正しく理解できているか分かりません．
また，どうしても理解ができない点が何個かあり，質問させて頂く次第になりました．
（様々な書籍やwebを拝見したのですが，いづれも腑に落ちませんでした．．．）

そのため，まず大まかに私が理解しているHTTP上のSSLの仕組みを書き，最後に質問を書かせて頂こうかと思います．
長くなりますが宜しくお願い致します．

■主な登場人物
・認証局
　CA秘密鍵
　CA証明書（公開鍵？）
　CA証明書発行要求　

・証明書
　KEYファイル（秘密鍵/公開鍵）
　CSRファイル/申請書（issuer側の情報/公開鍵）
　CRTファイル/サーバー証明書（CSRを認証局の秘密鍵で捻ったモノ）

■証明書の発行
１－１．証明書を発行したい者がCSRファイルという申請書を作成し，認証局に送ります．
　　　→CSRには登録情報(issuer)やサーバー（証明書を発行したい者）の公開鍵などが含まれます．
１－２．認証局はCSRファイルが適切であれば，署名（subject）し，認証局の秘密鍵でCSRの中の公開鍵のみを暗号化します．
１－３．これがCRTファイルになり，証明書を発行したい者に送り返されます．

この時，サーバー（証明書を発行した者）は認証局によって署名されたCRTファイルを持っています．
次にこれを利用したHTTPS通信について書きます．

■HTTPS通信
２－１．クライアントがサーバーに通信要請をします．
２－２．サーバーは証明書(CRT)をクライアントに送ります．
２－３．クライアントは送られてきたCRTが信頼できるか認証局の証明書（公開鍵）を使って検証します．
　　　→CRTに埋め込まれているサーバーの公開鍵は認証局の秘密鍵によって暗号化されているので，これを認証局の公開鍵で複合化します．
　　　→認証局の公開鍵はルート証明書といい，事前にブラウザに組み込まれているものとします．
２－４．クライアントは共通鍵を発行します．
２－５．クライアントはCSRから複合化したサーバーの公開鍵を用い，自身で発行した共通鍵を暗号化してサーバーに送ります
２－６．サーバーは受け取った暗号データを自身の持つ秘密鍵で複合化し，共通鍵を取得します．
２－７．後はこの共通鍵でデータを暗号化し通信します，

■質問
１．オレオレ証明書＋認証局の場合でも正常に通信ができるのはなぜか
私の理解だと2-3で，クライアントが認証局の公開鍵を用い，サーバーの証明書からサーバーの公開鍵を複合化し，それを元に共通鍵を暗号化しています．
これはクライアントが認証局のルート証明書（公開鍵）を保有しているから複合化できるはずです．
オレオレ証明書の場合は，認証局の公開鍵がクライアントにインストールされていません．
そのため，サーバーの公開鍵を複合化できず，共通鍵の生成に失敗し，通信できなくなると思います．
しかしながら，ブラウザは「署名が不明な接続先です」とのエラーを出すだけで，通信（接続）ができてしまいます．
なぜでしょうか．

２．IssuerとSubjectは暗号化されていないのか
私の理解だと1-2の認証局では，サーバーの公開鍵しか暗号化されていません．
ということはIssuerとSubjectは暗号化されていないということでしょうか．
また，それはなぜでしょうか．

３．IssuerとSubjectは偽装できるか
opensshを用いることで認証局を構築することができます．
この時に，Subjectの設定をベリサインの認証局と全く同じようにし，
証明書も，ベリサインの認証局を使っているサイトのIssuerと全く同じようにした場合，
SubjectとIssuerが全く同じ証明書ができると思います．
この場合は，本物の証明書と同様の証明書を複製できてしまうのでしょうか．
できないとは思いますが，それはなぜでしょうか．

４．証明書の偽装は可能か
ブラウザから証明書の情報を見ることができます．もちろんbyteデータのraw certificateも見ることができます．
この情報を丸々コピーし，全く異なるサーバーに証明書として読みこませて通信した場合は，
署名されてしまうのでしょうか．
されないとは思いますが，それはなぜでしょうか．
(例えば，URL=CN情報が異なっているから確認できるとか．．？それならCN情報だけ書き換えてしまえばいい？）

５．証明書の検証をするにはどうしたらよいか
証明書を検証をするには，その証明書を発行した認証局の公開鍵を利用するしかないのでしょうか．
例えば，サーバー証明書(CRT)のフィンガープリントsha1データを事前に保持さえしていれば，
サーバーに証明書を示された際にCRTのフィンガープリントを比較すれば，特定のサーバーかどうか検証できるか・・？

６．MITMについて
MITM攻撃により，証明書が途中で書きかわることが考えられます．
この場合は，書き換わった証明書をどのように特定すればいいのでしょうか．

例えば，認証局のルート証明書がないなどが考えられますが，
仮に，Rapid SSLなどで署名されている証明書でMITM攻撃がされた場合どうなるでしょうか？

この場合は，Issuerなどを比較するしかないように考えられます．
しかし，Issuerはcsr申請の際にうまいこと，書き換えることができてしまいます．
そう考えると，どのような対策ができるでしょうか

フィンガープリントなどで比較することになるのでしょうか，
フィンガープリントは偽装することができないのでしょうか．

以上となります．

様々な質問を書いてしまい，申し訳ありません
説明不足で乱文だとは思いますが，
分かる範囲でお答え頂けませんでしょうか．

宜しくお願い致します．

回答No.1

t_ohta · ベストアンサー

１）　認証局はサーバの公開鍵を暗号化してCRTファイルに書き込みません。電子署名を付けているだけです。
そもそも公開鍵暗号では、秘密鍵で暗号化したモノを公開鍵で複合することはできません。
これが可能になってしまうと公開鍵が有れば暗号の復号が誰でも出来ることになってしまい、暗号の意味がなくなってしまいます。
http://itpro.nikkeibp.co.jp/article/COLUMN/20071012/284426/?ST=selfup
オレオレ証明書が成立するのは、あくまでも署名の検証が出来ないと言うだけで、サーバの公開鍵は受け取れるので、共通鍵を暗号化してサーバに送付する事が出来るからです。

２）　１の回答の通りCSRの内容は暗号化されていませんので、CSR中身は見えます。

３）　CRTファイルに書かれている内容を書き換えると、署名を検証した時に不一致が発生するので書き換えられた証明書である事がバレてしまいます。

４）　いくら証明書をコピーしたとしても、秘密鍵がなければ公開鍵で暗号化されたデータを復号できません。
復号できないデータがサーバに送られてきても通信は成立しません。

５）　CRTは公開情報なので誰でも複製が可能です。その内容だけを信用しても相手が正しいサーバであることの証明にはならないでしょう。

お礼

理解できました！
本当にありがとうございます．