A、HTTPおよびHTTPS起源の欠点

我々はすべて知っているのHTTPプロトコルとしての転送Webコンテンツの誕生の礎として、ネットワークプロトコルTCPプロトコル、ある网络分层模型に属する应用层协议1。
セキュリティの観点からデータを転送するためのプロトコルに固有のセキュリティ問題の使用を探求します：
- （1）、平文（暗号化されていない）を使用して通信は、コンテンツが傍受されてもよいです。
- （2）通信相手を認証しないので、変装が発生することがあり、
- （3）は、それが改ざんされて、メッセージの完全なラインを証明することはできません。
SSLは、HTTPプロトコルのセキュリティ問題を解決するものであり、1990年代により、ネットスケープ（Netscapeは）設計されたSSL- （セキュアソケットレイヤー）プロトコル安全套接层プロトコルを。開発SSLの年は、インターネットで広く使用された後、名前を正規化の後に変更されましたTLS- （トランスポート層セキュリティ）传输层安全プロトコル。
それは呼ばHTTPSれているHTTP + SSL/TLS組み合わせて使用します。ソリューションは、データ伝送のためのHTTPプロトコルのセキュリティ上の問題です。
原理：でHTTP 协议层とTCP传输层の間に追加安全层のアプリケーション層データパケットが送信中にデータの整合性を保証するために、送信前に暗号化されているように、。
そのため、データ送信処理ではSSL / TLSは、データの整合性を確保するために暗号化を実装する方法ですか？
- ここでは、さらに契約の暗号化ロジックを模索する必要があります。：そこ2つの暗号化アルゴリズムがあり、すなわち、对称加密と非对称加密。

二、対称暗号化

「対称暗号」について「の逆数」数学的演算（一方向暗号化コントラスト、それは可逆暗号化アルゴリズムである）として理解することができます。暗号化されていること、それは解読が、ない暗号化や復号化処理が重要ですることができ、コンピューティングに関わる重要ないわゆる「キー」のものが存在しなければなりません。
対称暗号化最大の特徴は：暗号化と復号化が「同じ」キーを使用していることです。重要な問題だから、 -クライアントにサーバーを必要と暗号化通信に共通する「キー」を使用して、クライアントとサーバーの相互作用は、キーを転送しますが、そうすることは、どのように送信時に、そのキーを確保することができますセキュリティそれは？キーが送信中に、サードパーティの傍受を被った場合、手段はダブルエンドという通信は、通信とクリアテキストに差がないという点で第三者にあります。これは、対称暗号鍵のシナリオは、ネットワークを必要と適用されません。

このように、それが生まれました非对称加密！！！

三、非対称暗号化

暗号化と復号鍵のために使用されている、いわゆる「非対称暗号化は、」2端子の暗号化通信のための各生産両面通信、公開鍵と秘密鍵と公開鍵の交換異なっています。以下、クライアントとサーバの公開鍵は、データの通信に使用されるクライアントのパブリックキーが暗号化されたときに示されているように、たとえ復号鍵は常にサービスに保存されているので、送信中に第三者の公開鍵の出会い傍受、その切片への唯一の方法は、公開鍵でき解読されていないデータ、終了して、公開されることはありません。
しかし、これらのシナリオは、まだ盗聴のいくつかのリスクがあります。その後、クライアントの公開鍵をサーバーの応答を傍受する盗聴者として、サーバー、公共盗聴者にクライアントの応答のアイデンティティを偽造。暗号化データの盗聴に使用されるクライアント公開鍵た後、盗聴者は、暗号化データとサーバーの通信に、サーバの公開鍵を改ざんデータを取得するために平文データを復号化するために自分の秘密鍵を使ってデータメッセージをインターセプトします。クライアントは最後に自分のピア通信を認識していない通信の全体のプロセスは、盗聴者またはサーバーです。
观察下图中的图示模型，假设通信过程已被窃听。那么问题到底出在哪里?
盗聴のリスクは、次のように非対称暗号化がある示しています。
私たちは分析するための全体のプロセスを開始することができます。
- 最初のクライアントは、公開鍵、および応答で「ピア」から取得した公開鍵を要求します。その後、通信の「公開鍵」を使用して。問題は、このの一部である - 明らかに、クライアントではなく、「公開鍵」と検証を行っている「ソース」として。言い換えれば、クライアントは明確ではないが、「国民は、」サーバではなく、第三者の盗聴者から本当に本当です。
- その後、クライアントは、ダブルエンド通信の安全性を確保するために、公開鍵が本当に正当なサーバーからのものであることを決定するために、「公開鍵」の検証を行う必要があります。

四、CA認証機構

これは、第三者機関の導入する必要があります：
- 证书颁发机构CA（認証局）：すなわち颁发数字证书的机构。これは、公共システムにおける公衆の閲覧の正当性に責任を信頼できるサードパーティとして、電子商取引をデジタル証明書を発行し、管理する責任を負う機関です。
- CAセンターは、公開鍵、証明書に記載されているユーザーの公開鍵の正当性を証明するデジタル証明書の役割を使用して、各ユーザーのためのデジタル証明書が発行されます。CAのデジタル署名メカニズムは、攻撃者が偽造し、証明書を改ざんすることはできないことができます。言い換えれば、証明書は、証明書の公開鍵が有効であり、正当なものである限り、証明書が有効かつ合法であるとして、改ざんすることはできません！
- サーバはCA機関がCA証明書（証明書サーバの公開鍵が格納されている）サーバーへ戻った後、自身の秘密鍵、公開鍵暗号化サーバを使用して、CAの公開鍵を提供します。一般的なオペレーティングシステムまたはブラウザがCAのルート証明書を構築されます。ときにクライアントが使用する（ブラウザなど）の後に、サーバへのリクエストは、サーバーのCA証明書がクライアントに提供されるとき、クライアントは、間接的なルートCA証明書CA証明書のローカル認証（が意味の正当サーバーCA証明書による検証になります）公開鍵の正当性の源を示しています。

第五に、達成するための自己署名証明書ジャンゴ+ HTTP + SSL

CA証明書への正式なアプリケーションは、この中で、金融機関を必要とするので、私は簡単な構成の形でHTTPS自己署名証明書を介したジャンゴ・サーバベースの通信です。

（1）は、CAさんのプロフィールによって発行されたルート証明書を作成します。 MyCompanyCA.cnf

（2）は、（サーバーCA証明書を作成するための）プロファイルを拡張作成しますMyCompanyLocalhost.ext

（3）CA証明書とキーを作成します（使用opensslのに必要性を、パッケージ管理ツールを使ってインストールすることができます）

（4）、SSL証明書とキーの申請書類を作成します

（5）SSL証明書を発行します
上記の手順の後、OpenSSLは、自己署名証明書、請求MyCompanyCAによって達成しました。CAのルート証明書のためのCERは、（これは、私たちの自己署名、システムまたはブラウザのものであり、ルート証明書が組み込まれていない、我々は手動で追加する必要があります）。SSL証明書ファイルMyCompanyLocalhostです。CERは、SSL証明書キーファイルがMyCompanyLocalhost.pvkです。

六、Djangoのテストサーバは、HTTPSを開始します

スタートテストHTTPSサーバ次のように：

（1）、インストール依存性

（2）設定ファイルを変更するジャンゴ

（3）は、HTTPSサービスを開始ジャンゴ
以来DjangoはサービスHTTPSを開始しましたが、それでも（サーバー証明書が信頼されていません）アクセスHTTPSにブラウザを使用することはできません。

七、CAのルート証明書をインストールします

CAは、アクセス・クライアントへのHTTPSの使用を必要とするように設置されるように、自己署名ルート証明書を必要とします。以下は、証明書図示のMacOSオペレーティングシステム（Windowsのは、操作インタフェースに関するものである）に添加します。

（1）、ルート証明書を追加

（2）、証明書を信頼するようにシステムを設定します
それ以来、クライアント（ブラウザ）添加が完了したのは、サーバーにアクセスするためにhttpsを使用することができます。