- ベストアンサー
OpenSSLについての質問
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
クライアント側で作成される鍵は、クライアント毎により都度異なります。一度 SSL のセッションが切れると、新しく都度作り直されることになるでしょう。 ウェブサーバ側での公開鍵情報は変わりません。 詳しくは参考 URL をどうぞ。。
関連するQ&A
- 自己署名証明書によるSSL通信について教えてください！
SSL通信により、データを暗号化してWeb上でやりとりするシステムの構築を考えています。 そこで自己署名というのを考えているのですが、署名の流れがいまいち分かりません。 認証局利用の場合、私の理解では、 【サーバ側】 １．サーバ側でRSA秘密鍵を生成 ２．RSA秘密鍵を元にCSRを作成 ３．CSRファイルを認証局に送信 【認証局】 ４．CA秘密鍵により暗号化し、サーバ証明書を作成 ５．サーバ側にサーバ証明書を送信 【サーバ側】 ６．クライアント側にサーバ証明書を送信 【クライアント側】 ７．サーバ側よりサーバ証明書を受信する ８．認証局より公開鍵を取得する ９．認証局の公開鍵でサーバ証明書の暗号化された鍵（認証局の秘密鍵で暗号化されたもの）を復号する １０．復号した鍵により、サーバ証明書の暗号文を復号する となります。（間違いがある場合はご指摘下さい） では、自己署名を行う場合はどうなるのでしょうか？ 単純にサーバ証明書を自分で作成すると考えてよろしいのでしょうか？ CSRファイルの作成などもやはり行うのでしょうか？ クライアント側の流れは変わらないのでしょうか？ また、この操作は接続毎に毎回行うことになるのでしょうか？ （秘密鍵、サーバ証明書は毎回変わるのでしょうか？） 初歩的な質問とは思いますが、よろしくお願いいたします。
- ベストアンサー
- ネットワーク
- ディジタル署名の質問
＜@ITから引用＞ディジタル署名の場合，メッセージは送信者の公開かぎで復号する。公開かぎは一般に公開されるものなので，だれでも暗号文を復号できる。そのため，Webサーバが不特定多数のクライアントに対して自分自身を証明する用途などに使われる ここでディジタル署名の質問なのですが、上記の「だれでも暗号文を復号できる」のでは暗号の意味がないと思うのですが。 自分で考えたのですが、不特定多数とあるようにクライアント（受信者）を特定してはいないということですか？Webサーバ（送信者）は自分自身を証明するとあるのでまず、サーバの秘密カギはサーバを特定しますよね。 詳しく教えてくれると助かります。
- ベストアンサー
- ネットワーク
- OpenSSLでショッピングサイト
OpenSSLを使い決算画面（クレジットや個人情報）を暗号化してショッピングサイトを作ろうと思っています。 しかし、認証局？などについてあまり理解できていないと思います。 そこで、認識が間違っていないかご意見いただけたらと思います。 １、ベリサインなど有料SSLとOpenSSLの違い (1)価格 有料/無料 (2)強度 設定により同じ 256ビット（128か256が一般的的なビット数？）などのビット数が同じなら強度も同じ。 (3)認証 ベリサインなどが存在する会社だと証明してくれる/基本的に自分で自分を証明、もしくはお金を払って認証だけ依頼？ 私が思うに、機能については変わらないにもかかわらず、料金が随分と違うのでOpenSSLでやろうと思います。 不安なのは、OpenSSLの機能が果たしてベリサインなどと同じなのかどうか？ そして、よく分かっていないのですが、「期限切れ」や「SSLが機能していない」などのメッセージがでる？と聞くのですが、これはどういうことでしょう？ もし詳しい方がいらしたら教えていただけるとうれしいです。 よろしくおねがいします。
- ベストアンサー
- ネットワーク
- SSHのホスト認証について
現在VineLinux3.2を使ってサーバの勉強をしている、ド素人です。 SSHのユーザ認証が、 (1)サーバ側で乱数生成→クライアントの公開鍵で暗号化→ (2)クライアントに送信→ (3)クライアントが受信→ (4)秘密鍵で複合化→サーバに送信→ (5)サーバはクライアントから送られた乱数を確認して認証 という流れで、なるほど、これでユーザを認証できるってのは分かるのですが、 ホスト認証がよくわかりません、 SSHでサーバにアクセスすると、 サーバの公開鍵が ~/.ssh/knows_hosts に登録されますが、 この公開鍵を使って、ユーザ認証と同じ方法で接続先ホストを認証してるのでしょうか？ そうだとしたら、 2度目のアクセスからはホストを認証するのに、 この~/.ssh/known_hostsの 公開鍵を使った方法が有効だというのは分かりますが、 一番最初のアクセスではこの公開鍵を使ってもホストの認証は出来ないと思うのですが（接続先から送られてくる公開鍵を使うだけなので） どういう仕組みになってるのでしょうか？ よろしくおねがいします。
- ベストアンサー
- Linux系OS
- 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申請の際にうまいこと，書き換えることができてしまいます． そう考えると，どのような対策ができるでしょうか フィンガープリントなどで比較することになるのでしょうか， フィンガープリントは偽装することができないのでしょうか． 以上となります． 様々な質問を書いてしまい，申し訳ありません 説明不足で乱文だとは思いますが， 分かる範囲でお答え頂けませんでしょうか． 宜しくお願い致します．
- ベストアンサー
- ネットワーク
- ■HTTPS通信の時の証明書について。■
<構成図> 端末PC----WAN----Server(SSL,CA,WEB) <条件> 自己認証局(CA)により、https通信を検討しています。 認証方法としては、 １．サーバ証明書を利用する（URLのSection1）方法と ２．クライアント証明書を利用する（URLのSection2）があります。 <参考URL> http://park15.wakwak.com/~unixlife/practical/openssl.html ■質問1 端末PCから、Serverに通信するとき、 １．サーバ証明書の方法ですと、端末PCにサーバ証明書を入れなくても、 警告がでるが、通信はできそうですが、 ２．クライアント証明書の方法も、端末PCにクライアント証明書をいれなくても、 警告がでるが、通信はできますか？ ■質問2 上記の例だと、自己認証局(CA)による<条件>ですが、 外部CA認証局を利用する場合も、 １．サーバ証明書、２．クライアント証明書の方法ともに、 警告がでるが、通信はできるのでしょうか？ 宜しくお願いします。
- 締切済み
- ネットワーク
- SSLによる電子証明書交換のセキュリティについて
SSLを勉強しております。 私の今の解釈ではSSLによる電子証明書の交換手順は 以下のようなイメージです。 (1)[データの方向：クライアント → サーバー] <ClientHello> マスターキーのための乱数 今からの暗号通信に用いる暗号方式のリスト などをサーバーに送信。 (2)[データの方向：サーバー → クライアント] <ServerHello> 選んだ暗号方式 マスターキーのための乱数 <ServerCertificate> サーバーが保持するサーバー証明書 サーバーが保持するルートCA証明書 <CertificateRequest> <ServerHelloDone> ・ ・ ・ 次にClientCertificateが送られてきて・・という感じですが、ここまででわからない点があります。 以下に質問を挙げます。 [質問] 手順(2)においてサーバーは電子証明書をクライアントに送るわけですが、参考書を読んでいる限りでは証明書データは暗号化せずにそのまま生データを送るような説明でした。 もしそうだとすればパケットキャプチャさえすれば証明書をそっくりそのまま盗まれることになりますので考えにくいのですがどうなのでしょうか？ 暗号化されているなら「何の鍵」で暗号化されているのでしょうか？ クライアントの公開鍵は(2)のタイミングではまだ知らないのでクライアントの公開鍵ではないと思いますが。 長くなってすいません。 わかりにくければ補足します。 よろしくお願いします。
- ベストアンサー
- ネットワーク
- 自己署名証明書（オレオレ証明書）の暗号化について
SSL暗号化通信の仕組み自体は，下記URLの通りとして把握しております． (1*) http://www.twsvc.com/about_ssl (2*) http://www.ibm.com/developerworks/jp/websphere/library/web/web_security/pdf/2_6.pdf これを，オレオレ証明書を用いた暗号化通信で考えると，セキュリティに関する識者である高木氏は，自分の日記にて以下のように書いています． >共通鍵暗号による暗号化通信をしています。鍵は一緒に配送します。この暗号は正常に機能しているでしょうか？ >「今の話は共通鍵暗号じゃなくて公開鍵暗号だろ」って？ オーケー、では、次の比較に対してどう答えるか。 >1.共通鍵暗号による暗号化通信 >2.公開鍵暗号による暗号化通信で認証なし（認証検証時の警告を無視する使用形態） >3.公開鍵暗号による暗号化通信で認証あり （略） >では、1.と 2. を比べたときはどうか。「3.ほどではないが 1.よりは 2. の方がまし」と言えるだろうか？ それは誤りである。 （略） >公開鍵暗号の公開鍵がいっしょに配送されている暗号化通信では、傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえば、それで暗号化されて戻ってくる暗号文を復号できる。 ※詳細は，高木氏の「PKIよくある勘違い(1)「オレオレ証明書でもSSLは正常に機能する」」をご参照ください． ここで，疑問になるのが，”傍受点で、流れてきた鍵を、別途用意した自作鍵に差し替えて流してしまえばいい”という点です． オレオレ証明書では，ルート証明書にたどり着けないため，ブラウザはオレオレ認証局の公開鍵をもっていない． そのため，サーバ証明書内の公開鍵を取得できない． だから，サーバ証明書送付時にオレオレ認証局の公開鍵を送付する必要がある． オレオレ認証局の公開鍵を用いて，サーバ証明書から公開鍵を抜き出す もしこのとき，オレオレ認証局の公開鍵が自作鍵に置き換えられたとしても，ただ単にサーバ証明書から公開鍵を抜き出すことができず，そこで通信が終了すれば”それで暗号化されて戻ってくる暗号文を復号できる”ことも無いように思えるのですが，いかがでしょうか． （つまり，高木氏の言う差し替えた自作鍵でサーバ証明書内の公開鍵が取得できるかどうか） これができなければ，確かに暗号化通信（というか通信そのもの）自体は破綻していますが，高木氏の懸念しているような「重要な情報の流出」にはつながらないように思えます． 乱文になってしまいまして申し訳ありません． もし，私自身に勘違いや解釈違い等ありましたら，ご指摘いただけると幸いです． よろしくお願いします．
- ベストアンサー
- ネットワーク
- openSSLの脆弱性問題のニュース
openSSLについてのバグ！？で問題になっていますが、私の解釈ですと、攻撃者がサーバに攻撃すると、サーバから６４kバイトのデータがメモリから盗まれ、秘密鍵等が流出する。と認識来ていますが、秘密鍵等ですが、メモリ上の６４kバイトなら、すべてのデータが、流出する可能性があるように感じますが、違いますか？メモリ上に展開される恐れのある物すべてに。 また、サーバがこのためアップデートするのは、理解でしますが、我々クライアントも何かアップデートをしました。が我々のアップデートは何をしたのでしょうか？ よくわからずにアップデートしてしまったのは、問題がありますが、攻撃されるのはサーバで、サーバから攻撃される恐れがあるための、アップデートでしょうか？
- ベストアンサー
- その他(ソフトウェア)
- httpsで暗号化されているのか。
ＩＩＳ８にて自己証明書を作成し社内運用しています。 自己証明書ですがお客様にも開放しようと思っています。 クライアントに証明書を入れていない場合、ＩＥだと「このＷｅｂサイトのセキュリティ証明書には問題があります。」とエラー表示が出ても「このサイトの閲覧を実行する(推奨されません)」をクリックすることで次の画面に移行するのですがこの場合、暗号化はされているのでしょうか？ カギをクライアント側にも導入しないと暗号化されないのでしょうか。
- ベストアンサー
- ネットワーク
お礼
zemさん、ご返答ありがとうございました！