HTTPSはどのように安全を保証しますか?
3991 ワード
HTTPSはどのように安全を保証しますか?
情報セキュリティについて議論するたびに、私たちが最も長く接触している情報暗号化伝送の方式はHTTPSに過ぎません.ブラウザのアドレスバーが緑色になったとき、このサイトを代表してHTTPSの暗号化情報伝送方式をサポートしています.そして、あなたとその接続は確実に暗号化されています.しかしHTTPSは単一のものではありません.私たちがよく使うHTTPプロトコルとある暗号化プロトコルとの混合についての知識があります.この暗号化プロトコルは通常TLSになります.HTTPSはなぜ安全ですか?実は私達はまずHTTPがなぜ安全ではないかを考えなければなりません.
教室に座っていたら、教室の中の他の人に何かの情報を伝えたいです.普通は選んで、メモを渡します.メモ用紙のこの比喩は実はとても正確で、これはインターネットの基本的なプロトコルTCP/IPプロトコルの基本的な動作モードです.通常、HTTPプロトコルのデータはTCP/IPプロトコルを用いて送信される.HTTPとは、あなたが送る目的地がどのクラスの席かをメモに書いて、それから伝える内容のことです.道の友達がメモを取ってから、メモに書いてある住所によって順次伝えばいいです.このように直面する最初の問題は、ルートの学生はあなたが何を書いているかを完全に知ることができます.
これはHTTPが直面する最初の問題です.この問題は通常「盗聴」または「嗅ぎ込み」と呼ばれています.あなたと同じネットワーク下やルート上の攻撃者があなたの伝達内容を垣間見ることができます.これはHTTPSが解決する最初の問題です.この問題は通常「暗号化」によって解決されます.非常に原始的な観点から考えると、実は双方が暗号を約束したのです.アルファベットの代わりに何の文字を使いますか?しかし、インターネットを考えると、毎日無数の情報が暗号化されているため、このような原始的な暗号化方法はあまり適切ではないようです.でも、実際の方法も似ています.AESというアルゴリズムで解決します.このアルゴリズムは、全体の情報を暗号化する鍵keyを必要とし、暗号化と復号に必要なkeyは同じであるので、この暗号化は一般に「対称暗号」とも呼ばれる.AESは数学的に保証されました.あなたが使うkeyが十分に長い限り、解読は不可能です.
まず、このようなクラックは確かに不可能であり、AES自体に対して効果的な攻撃ができるケースは現時点ではないと仮定します.
私たちはこの教室に戻ります.住所を書いてから、転送する内容をAESでぐずぐず暗号化してください.伝えようとしたところに、問題が来ました.AESにはキーがあるじゃないですか?keyは目的地をどうやってあげますか?鍵を直接紙に書いたら、途中の人はまだ解読できますか?現実的には他の方法で鍵を目的地に転送してもいいです.他の人に見られないようにしてもいいです.しかし、インターネットでは、このようにするのは難しいです.結局伝送はこれらのルートを通ります.暗号化を行うには、もっと複雑な数学の方法を探さなければなりません.
そこで、賢い人々はより複雑な暗号アルゴリズム、非対称暗号化を発明した.このような暗号化は理解しにくいかもしれませんが、この暗号化は一対の鍵(k 1,k 2)を生成することができるということです.k 1暗号化されているデータは、k 1自身では解読できません.k 2が必要です.k 2暗号化されたデータは、k 2では復号できません.k 1が必要です.このアルゴリズムは実際には多くあります.RSAをよく使うのですが、その基礎となる数学原理は二つの大きな素数の積で計算しやすいです.この積を取って、どの素数が乗算されているのかを計算すると複雑です.幸い、現在の技術では、大きな素因数を分解するのは確かに難しいです.特にこの大きな数が十分大きい場合(通常は2の10乗の2進法位を使うのがこんなに大きいです.)、スーパーコンピューターの復号にも時間がかかります.
この非対称暗号化の方法を利用して,シーンを想定した.メモを送りたいですが、メモを送る前に次の通信の対称暗号化鍵を転送します.そこであなたはRSA技術でk 1、k 2ペアを生成しました.k 1を明文で送りました.道の途中で誰かが切り取るかもしれませんが、無駄です.k 1暗号化されたデータはk 2で解読できます.この時、k 2はあなたの手の中にあります.k 1目的地に到着すると、目的地の人は次に対称暗号化伝送用の鍵keyを準備し、受信したk 1でkeyを暗号化して、暗号化されたデータを転送します.路上の人は切り取ってもキーを復号できない.自分の手でk 2を使ってk 1暗号化のkeyを解いてください.今は全教室であなたと目的地だけkeyを持っています.AESアルゴリズムで対称暗号化の伝送ができます.目的地との通信はもう誰にも盗聴されません.
もちろん、この時は二つの質問をするかもしれません.
非対称暗号化がそんなに安全であるなら、なぜ私たちは直接に情報を暗号化するのではなく、対称暗号化の鍵を暗号化するのですか?
これは、非対称暗号化の暗号は、生成と暗号化に対する消費時間が長いためであり、双方の計算時間を節約するために、データを直接伝送するのではなく、通常はそれだけで鍵を交換する.
非対称暗号化を使うのは完全に安全ですか?
確かに安全そうに聞こえますが、実際にはもっと悪質な攻撃があります.これは「中間者攻撃」と言われています.私たちは引き続きあなたを教室に座らせてメモを伝えます.今はあなたと目的地の中間者です.彼はあなた達のニュースを知りたいと思っています.この説明が複雑なので、Aと呼びます.目的地はBです.中間はMです.Bと最初の鍵の交換を完了すると、Mを経由します.Mはあなたが鍵を交換することを知っています.それは小さい紙を伏せて、自分がBだと偽って、キーを偽造しました.そしてあなたが送ったk 1で暗号化してkeyを返送しました.あなたはBと鍵の交換が完了したと思いますが、実はMと鍵の交換を完了しました.同時にMとBは一回の鍵の交換を完成して、Bにあなたと鍵の交換が完了したと誤解させます.現在、A->Bによって完全に暗号化され、A(暗号化接続1)->M(平文)->B(暗号化接続2)の場合になりました.このときMはAとBの伝送中のすべての情報を依然として知ることができる.
このような問題に対しては、ソースから保証できる限り、あなたの鍵の交換の対象は安全です.この時、私たちはインターネットHTTPSとあなたのメモの微妙な違いを認識します.メモを送る時、目的地との関係はほとんど対等です.あなたがウェブサイトを訪問する時、あなたの訪問の対象は通常比較的に大きいサービスプロバイダで、彼らは十分な資源があって、彼らの合法性を証明することができるかもしれません.
この時に第三者を紹介してCAといいます.CAはウェブサイトの合法性を認証するための非常に権威のある組織です.サービスプロバイダは、彼らが安全な接続を確立するときにCAの署名を持つことができる証明書を彼らに申請することができます.CAのセキュリティは、オペレーティングシステムまたはブラウザによって認証される.Windows、Mac、Linux、Chrome、Safariなどは、インストール時に彼らが安全だと思うCA証明書のリストを持ちます.あなたと安全に接続している人がこれらの人の署名を持っていると、この安全な接続は安全だと考えられ、仲介者の攻撃を受けられませんでした.
CA証明書は通常安全です.あるCAが発行した証明書が不正な用途に使用されると、ブラウザとオペレーティングシステムは通常、更新によってCA全体に与えられた証明書の全部を安全ではないと見なします.これにより、CAは一般的に証明書を発行する際に、より慎重になります.
したがって、対称暗号化+非対称暗号化+CA認証の3つの技術が混在していることにより、HTTPの後ろにS−Securityが付加されている.実はHTTPSの契約はここで説明したより複雑です.ここで言っているのは主に基本的な実現原理です.どちらかのリングが少し狂ってしまうと、暗号全体が不安定になります.これもなぜHTTPSの暗号化プロトコルがSSL 1.0からSSL 3.0にアップグレードされたのか、TLS 1.0によって現在TLS 1.2に取って代わられています.
それでも、あなたのHTTPSはできるだけあなたの転送の安全を保証していますが、このような安全は絶対的ではありません.例えば、CA証明書に問題があったら、中間者の攻撃に使われます.短期的には、ブラウザやオペレーティングシステムがあなたのCAリストを更新したり、手動でリストを調整したりするまで、あなたの安全は直接的なトラブルになります.しかし、多くの場合、取り越し苦労をしなくても大丈夫です.基本的には安全です.
もちろん、ルートも直接カバンをなくしてもいいです.見えないものも見えないです.
:https://zybuluo.com/phper/note/87318
良い文は略書から転送します.http://www.jianshu.com/p/b894a7e1c779httpsの各种を分かりやすく述べました.情報セキュリティについて議論するたびに、私たちが最も長く接触している情報暗号化伝送の方式はHTTPSに過ぎません.ブラウザのアドレスバーが緑色になったとき、このサイトを代表してHTTPSの暗号化情報伝送方式をサポートしています.そして、あなたとその接続は確実に暗号化されています.しかしHTTPSは単一のものではありません.私たちがよく使うHTTPプロトコルとある暗号化プロトコルとの混合についての知識があります.この暗号化プロトコルは通常TLSになります.HTTPSはなぜ安全ですか?実は私達はまずHTTPがなぜ安全ではないかを考えなければなりません.
教室に座っていたら、教室の中の他の人に何かの情報を伝えたいです.普通は選んで、メモを渡します.メモ用紙のこの比喩は実はとても正確で、これはインターネットの基本的なプロトコルTCP/IPプロトコルの基本的な動作モードです.通常、HTTPプロトコルのデータはTCP/IPプロトコルを用いて送信される.HTTPとは、あなたが送る目的地がどのクラスの席かをメモに書いて、それから伝える内容のことです.道の友達がメモを取ってから、メモに書いてある住所によって順次伝えばいいです.このように直面する最初の問題は、ルートの学生はあなたが何を書いているかを完全に知ることができます.
これはHTTPが直面する最初の問題です.この問題は通常「盗聴」または「嗅ぎ込み」と呼ばれています.あなたと同じネットワーク下やルート上の攻撃者があなたの伝達内容を垣間見ることができます.これはHTTPSが解決する最初の問題です.この問題は通常「暗号化」によって解決されます.非常に原始的な観点から考えると、実は双方が暗号を約束したのです.アルファベットの代わりに何の文字を使いますか?しかし、インターネットを考えると、毎日無数の情報が暗号化されているため、このような原始的な暗号化方法はあまり適切ではないようです.でも、実際の方法も似ています.AESというアルゴリズムで解決します.このアルゴリズムは、全体の情報を暗号化する鍵keyを必要とし、暗号化と復号に必要なkeyは同じであるので、この暗号化は一般に「対称暗号」とも呼ばれる.AESは数学的に保証されました.あなたが使うkeyが十分に長い限り、解読は不可能です.
まず、このようなクラックは確かに不可能であり、AES自体に対して効果的な攻撃ができるケースは現時点ではないと仮定します.
私たちはこの教室に戻ります.住所を書いてから、転送する内容をAESでぐずぐず暗号化してください.伝えようとしたところに、問題が来ました.AESにはキーがあるじゃないですか?keyは目的地をどうやってあげますか?鍵を直接紙に書いたら、途中の人はまだ解読できますか?現実的には他の方法で鍵を目的地に転送してもいいです.他の人に見られないようにしてもいいです.しかし、インターネットでは、このようにするのは難しいです.結局伝送はこれらのルートを通ります.暗号化を行うには、もっと複雑な数学の方法を探さなければなりません.
そこで、賢い人々はより複雑な暗号アルゴリズム、非対称暗号化を発明した.このような暗号化は理解しにくいかもしれませんが、この暗号化は一対の鍵(k 1,k 2)を生成することができるということです.k 1暗号化されているデータは、k 1自身では解読できません.k 2が必要です.k 2暗号化されたデータは、k 2では復号できません.k 1が必要です.このアルゴリズムは実際には多くあります.RSAをよく使うのですが、その基礎となる数学原理は二つの大きな素数の積で計算しやすいです.この積を取って、どの素数が乗算されているのかを計算すると複雑です.幸い、現在の技術では、大きな素因数を分解するのは確かに難しいです.特にこの大きな数が十分大きい場合(通常は2の10乗の2進法位を使うのがこんなに大きいです.)、スーパーコンピューターの復号にも時間がかかります.
この非対称暗号化の方法を利用して,シーンを想定した.メモを送りたいですが、メモを送る前に次の通信の対称暗号化鍵を転送します.そこであなたはRSA技術でk 1、k 2ペアを生成しました.k 1を明文で送りました.道の途中で誰かが切り取るかもしれませんが、無駄です.k 1暗号化されたデータはk 2で解読できます.この時、k 2はあなたの手の中にあります.k 1目的地に到着すると、目的地の人は次に対称暗号化伝送用の鍵keyを準備し、受信したk 1でkeyを暗号化して、暗号化されたデータを転送します.路上の人は切り取ってもキーを復号できない.自分の手でk 2を使ってk 1暗号化のkeyを解いてください.今は全教室であなたと目的地だけkeyを持っています.AESアルゴリズムで対称暗号化の伝送ができます.目的地との通信はもう誰にも盗聴されません.
もちろん、この時は二つの質問をするかもしれません.
非対称暗号化がそんなに安全であるなら、なぜ私たちは直接に情報を暗号化するのではなく、対称暗号化の鍵を暗号化するのですか?
これは、非対称暗号化の暗号は、生成と暗号化に対する消費時間が長いためであり、双方の計算時間を節約するために、データを直接伝送するのではなく、通常はそれだけで鍵を交換する.
非対称暗号化を使うのは完全に安全ですか?
確かに安全そうに聞こえますが、実際にはもっと悪質な攻撃があります.これは「中間者攻撃」と言われています.私たちは引き続きあなたを教室に座らせてメモを伝えます.今はあなたと目的地の中間者です.彼はあなた達のニュースを知りたいと思っています.この説明が複雑なので、Aと呼びます.目的地はBです.中間はMです.Bと最初の鍵の交換を完了すると、Mを経由します.Mはあなたが鍵を交換することを知っています.それは小さい紙を伏せて、自分がBだと偽って、キーを偽造しました.そしてあなたが送ったk 1で暗号化してkeyを返送しました.あなたはBと鍵の交換が完了したと思いますが、実はMと鍵の交換を完了しました.同時にMとBは一回の鍵の交換を完成して、Bにあなたと鍵の交換が完了したと誤解させます.現在、A->Bによって完全に暗号化され、A(暗号化接続1)->M(平文)->B(暗号化接続2)の場合になりました.このときMはAとBの伝送中のすべての情報を依然として知ることができる.
このような問題に対しては、ソースから保証できる限り、あなたの鍵の交換の対象は安全です.この時、私たちはインターネットHTTPSとあなたのメモの微妙な違いを認識します.メモを送る時、目的地との関係はほとんど対等です.あなたがウェブサイトを訪問する時、あなたの訪問の対象は通常比較的に大きいサービスプロバイダで、彼らは十分な資源があって、彼らの合法性を証明することができるかもしれません.
この時に第三者を紹介してCAといいます.CAはウェブサイトの合法性を認証するための非常に権威のある組織です.サービスプロバイダは、彼らが安全な接続を確立するときにCAの署名を持つことができる証明書を彼らに申請することができます.CAのセキュリティは、オペレーティングシステムまたはブラウザによって認証される.Windows、Mac、Linux、Chrome、Safariなどは、インストール時に彼らが安全だと思うCA証明書のリストを持ちます.あなたと安全に接続している人がこれらの人の署名を持っていると、この安全な接続は安全だと考えられ、仲介者の攻撃を受けられませんでした.
CA証明書は通常安全です.あるCAが発行した証明書が不正な用途に使用されると、ブラウザとオペレーティングシステムは通常、更新によってCA全体に与えられた証明書の全部を安全ではないと見なします.これにより、CAは一般的に証明書を発行する際に、より慎重になります.
したがって、対称暗号化+非対称暗号化+CA認証の3つの技術が混在していることにより、HTTPの後ろにS−Securityが付加されている.実はHTTPSの契約はここで説明したより複雑です.ここで言っているのは主に基本的な実現原理です.どちらかのリングが少し狂ってしまうと、暗号全体が不安定になります.これもなぜHTTPSの暗号化プロトコルがSSL 1.0からSSL 3.0にアップグレードされたのか、TLS 1.0によって現在TLS 1.2に取って代わられています.
それでも、あなたのHTTPSはできるだけあなたの転送の安全を保証していますが、このような安全は絶対的ではありません.例えば、CA証明書に問題があったら、中間者の攻撃に使われます.短期的には、ブラウザやオペレーティングシステムがあなたのCAリストを更新したり、手動でリストを調整したりするまで、あなたの安全は直接的なトラブルになります.しかし、多くの場合、取り越し苦労をしなくても大丈夫です.基本的には安全です.
もちろん、ルートも直接カバンをなくしてもいいです.見えないものも見えないです.