- ベストアンサー
SSLによる通信について
oneyanの回答
- oneyan
- ベストアンサー率42% (80/187)
とりあえずSSLでは、 クライアントから使用可能な暗号種をサーバーに送信し、 サーバーはその中から、一番強い共通の暗号キーを選択。 その後、サーバー証明書、署名などを、クライアントに送信。 クライアントは、共通キーを作って、 そのキーをサーバーの公開キーで暗号化して、送信。 で、 やっと暗号化した相互通信が始まりますので、 たいていのSSLのサーバーでしたら、 個人情報がクライアント側に送られて・・ の以前からすでにかかっていると思います
関連するQ&A
- SSLの原理？
「SSLのフォームに入力された情報は自動的に暗号化されて送信される」という説明がよくあるのですが、ユーザから送られた内容がSSLサーバ内で暗号化されるのではないのでしょうか？サーバで暗号化されるのであれば、サーバへ到達するまでは暗号化されないのでしょうか？もしくはユーザが送信する時点で暗号化されるのしくみということなのでしょうか？つまり、SSLサーバは「解読機」ということになるのかな？また、「SSLサーバはWebサーバのすぐ隣にないと意味がない」という見解を何かで読んだのですが、これはつまり「WebサーバとSSLサーバの間のやり取りは暗号化されない」ということでしょうか？私がWebページを作っているクライアントに説明を求められています。よろしくお願いします。
- 締切済み
- ネットワーク
- SSLによる電子証明書交換のセキュリティについて
SSLを勉強しております。 私の今の解釈ではSSLによる電子証明書の交換手順は 以下のようなイメージです。 (1)[データの方向：クライアント → サーバー] <ClientHello> マスターキーのための乱数 今からの暗号通信に用いる暗号方式のリスト などをサーバーに送信。 (2)[データの方向：サーバー → クライアント] <ServerHello> 選んだ暗号方式 マスターキーのための乱数 <ServerCertificate> サーバーが保持するサーバー証明書 サーバーが保持するルートCA証明書 <CertificateRequest> <ServerHelloDone> ・ ・ ・ 次にClientCertificateが送られてきて・・という感じですが、ここまででわからない点があります。 以下に質問を挙げます。 [質問] 手順(2)においてサーバーは電子証明書をクライアントに送るわけですが、参考書を読んでいる限りでは証明書データは暗号化せずにそのまま生データを送るような説明でした。 もしそうだとすればパケットキャプチャさえすれば証明書をそっくりそのまま盗まれることになりますので考えにくいのですがどうなのでしょうか？ 暗号化されているなら「何の鍵」で暗号化されているのでしょうか？ クライアントの公開鍵は(2)のタイミングではまだ知らないのでクライアントの公開鍵ではないと思いますが。 長くなってすいません。 わかりにくければ補足します。 よろしくお願いします。
- ベストアンサー
- ネットワーク
- 自己署名証明書によるSSL通信について教えてください！
SSL通信により、データを暗号化してWeb上でやりとりするシステムの構築を考えています。 そこで自己署名というのを考えているのですが、署名の流れがいまいち分かりません。 認証局利用の場合、私の理解では、 【サーバ側】 １．サーバ側でRSA秘密鍵を生成 ２．RSA秘密鍵を元にCSRを作成 ３．CSRファイルを認証局に送信 【認証局】 ４．CA秘密鍵により暗号化し、サーバ証明書を作成 ５．サーバ側にサーバ証明書を送信 【サーバ側】 ６．クライアント側にサーバ証明書を送信 【クライアント側】 ７．サーバ側よりサーバ証明書を受信する ８．認証局より公開鍵を取得する ９．認証局の公開鍵でサーバ証明書の暗号化された鍵（認証局の秘密鍵で暗号化されたもの）を復号する １０．復号した鍵により、サーバ証明書の暗号文を復号する となります。（間違いがある場合はご指摘下さい） では、自己署名を行う場合はどうなるのでしょうか？ 単純にサーバ証明書を自分で作成すると考えてよろしいのでしょうか？ CSRファイルの作成などもやはり行うのでしょうか？ クライアント側の流れは変わらないのでしょうか？ また、この操作は接続毎に毎回行うことになるのでしょうか？ （秘密鍵、サーバ証明書は毎回変わるのでしょうか？） 初歩的な質問とは思いますが、よろしくお願いいたします。
- ベストアンサー
- ネットワーク
- 関連のシーケンス図を紹介して頂けると有り難いです。
SSL方式で個人情報を送信させているサイトでは、先ず第一段階で、サーバ側からクライアント側へ公開鍵が送られていくのでしょうか？
- ベストアンサー
- その他（インターネット接続・通信）
- 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申請の際にうまいこと，書き換えることができてしまいます． そう考えると，どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか， フィンガープリントは偽装することができないのでしょうか． 以上となります． 様々な質問を書いてしまい，申し訳ありません 説明不足で乱文だとは思いますが， 分かる範囲でお答え頂けませんでしょうか． 宜しくお願い致します．
- ベストアンサー
- ネットワーク
- SSLの公開鍵をCAから取得できる？
SSLの通信を確認しているのですが、 クライアントPCとサーバがSSLで通信する場合、公開鍵をサーバから クライアントPCは取得しているようですが、CAからは取得できないのでしょうか？ ブラウザにルート証明書がインストールされていないCAなら、 公開鍵をCAに要求し取得するものだと思っていましたが、 そうではないのでしょうか？ググっても明確な情報がでてきませんでした。ぜひご教示宜しくお願い致します。
- 締切済み
- その他（インターネット接続・通信）
- SSLの暗号化について
ミルです。 SSLの暗号化の仕組みについて易しく教えていただきたいです。 SSLのWebページで情報を送信すると、どんなしくみで 送信側と受信側で鍵をやりとりするってことなんでしょうか？ 本を読んでもよくわかんなくって。
- ベストアンサー
- ネットワーク
- SSLの通信速度について
宜しくお願いします。 サーバ⇔クライアント間をSSLで暗号化すると、アクセス自体は遅くなるのでしょうか？もしそうだとすると、やたらめったら(例えば全てのファイルに対して)SSL暗号化すると重たいサイトになってしまうでは？と懸念しております。
- ベストアンサー
- ネットワーク
- ＳＳＬ暗号化の仕組みについて教えてください
ＳＳＬ暗号化の仕組みについて、教えてください。 公開鍵を使って共通鍵を生成し、共通鍵で通信をすることで傍受やなりすましによる情報漏えいを防ぐということはわかるのですが、 第三者が公開鍵も、共通鍵も傍受して、情報を傍受していたら情報漏えいのリスクは完全には排除できないような気がするのですが、その点にまでコメントされたものは本でもネットでも見当たらなかったので、 どなたかご存知の方がいらっしゃればご解説願います。 http://www.soumu.go.jp/joho_tsusin/security/kiso/k01_ssl.htm
- ベストアンサー
- スパイウェア