HTTP我々はそれに触れるようにしてください、インターネットに、すべての後、どのくらいのいくつかを理解しています。HTTP非常に安全、平文で送信され、非常に明らかな欠点があります。このような状況に対処するために、我々は、http + SSL / TLS、あること、HTTPSを開始しました。
明示的に危険な質問については、私はそれが暗号化されていることを確認思いました。それでは、どのようにそれを暗号化するには？
対称暗号化を使用して第一の方法、。クライアントがサーバーへの接続を開始すると、サーバーは、我々はすべて暗号化と復号化は、このキーを使用した後、最初のクライアントにキーを送信します。問題は、ここで発生するキーを送信する際に、仲介者によってそこに傍受される可能性がサーバーである場合、暗号化は何の意味もないだろう。
非対称暗号方式の暗号化キーを使用して第二の方法は、第1の追加の層です。接続開始は、サーバがクライアントに公開鍵を送信すると、対称鍵は、秘密鍵とサーバが送信用の対称鍵を持つ、我々は満足して、それを解読するために、この公開鍵暗号化を使用するようにクライアントを必要とします。この安全なの？すべてではありませんで。仲介サーバ公開鍵が傍受送信することができるので、（Aと呼ぶ）を自己生成し、クライアントにクライアントが公開鍵Bで暗号化送信する対称鍵を送信した公開鍵（Bと呼びます）その秘密鍵を持つ最初の中間の対称鍵が解かれ、その仲介にも成功し、対称鍵を得て、その後、サーバーに公開鍵暗号を送信します。だから、これは安全ではありません。
今回は、クライアントとサーバーの両方、接続を確保することができない場合にのみ見られます。そして、あるサードパーティ製の権限の導入は、私たちはしばしば、認証局と言います。
認証局は、以下の情報を発表しました。
1.認証局
2.サーバーのURL
秘密鍵暗号化メカニズムによって発行されたサーバの公開鍵証明書の後に3
認証局の証明書の秘密鍵暗号署名した後、4
次に、証明書の導入後の接続プロセスについて話：
1.サービス機関は、自分の公開鍵を提出し、独自の証明書を生成終了します。
2.クライアントがサーバーへの接続を開始すると、サーバーはクライアントに証明書を送信します。
3.クライアントは、証明書の受領後、最初の証明書の信頼性を確認することです。ので、すべての主要なブラウザとオペレーティングシステムのすべての権限と公開鍵認証局の名前を維持しています。限り、我々は機関によって発行された証明書が何であるかを知っているように、それは証明書の署名とサーバの公開鍵を復号化することができます。クライアントの署名は、証明書、署名の規則に従って生成され、一貫性のある、一貫性のある、そしてあなたは、公開鍵の使用が送ってくれたので安心できるかどうかを確認するために私を送りました。
4.認証が成功すると、クライアントは対称鍵がサーバーに、使用、公開鍵暗号に渡す使用しています。
対称鍵サーバは解かれ、両方のスタートは、対称鍵暗号解読相互作用を利用して。
仲介が自然に民間機関を得ることができない証明書を偽造することはできませんので、安全性を確保します。実際には、これは上記の検証プロセスが完了するSSL層上のセキュリティSSLの追加層上の合意に基づいて、HTTPS、HTTP、HTTPSの主なアイデアです。