オリジナル：bestswifter https://juejin.im/post/58c5268a61ff4b005d99652a
Q1：HTTPSとは何ですか？
BS：HTTPS安全であるHTTP
HTTPプロトコルの内容を明確に伝達され、HTTPSの目的は、情報伝送のセキュリティを確保するために、コンテンツを暗号化することです。最後に、文字Sは、HTTPプロトコルおよびTCP / IPプロトコルの中央に位置しているSSL / TLSプロトコルを指します。
Q2：あなたは、情報伝送のセキュリティの意味は何かと言います
BS：4つの分野の情報を安全に送信：
直接通信、クライアントとサーバのみ
2、あなたは、サードパーティのデータも本当の意味での情報を理解していない見ることができたとしても、理解することができます。
3、第三者がデータを読み取ることはできませんが、クライアントとサーバは、データが変更されているかどうかを決定する能力を持っている必要がありますので、変更をXJBことができますが。
4、クライアントは、実サーバのほかに、第三者がサーバを偽装することはできません仲介攻撃を回避しなければなりません。
現在のHTTPプロトコルは3上記請求項のいずれかを満たしていないことを私たちに後悔。
Q3：非常に多くの要件満たすために一つ一つは疲れてないですか？
BS：疲れていない、第3の要件を制御することはできません。
はい、私はそれが実際には最初の要件に属しているので、あなたは一時的に、第3の要件を制御していないことができ、冗談ではありません。私たちは、暗号化パスワードを知っているすべての必要性は、世界が下降されていない、あなたが通信するための相互協議の必要性を通って来ています。だから、うまく設計された暗号化機構が第三者と偽造の干渉を防ぐためにバインドされています。この要件を「第三者がサーバを偽装することはできません」：だから徹底的に暗号化の具体的な原則を理解し、私たちは自然にそれが満たしていることを確認することができます。
Q4：どのような情報を暗号化します
BS：対称暗号化技術
対称暗号化は、生データの可逆変換が理解されるべきです。こんにちはがIfmmpに変換することが可能なように、各ルールは、他のこんにちはIfmmpは、元の情報に削減取得することができ、秘密鍵があり、それはアルファベットの文字の後の文字になることです。
対称暗号化を導入した後、HTTPSハンドシェイクは、対称暗号化キーを送信するための複数の2段階のプロセスになります。
1.クライアント：こんにちは、私はHTTPS要求を開始する必要があります
1は、サーバー：まあ、あなたの秘密鍵が1です。
対称暗号化を述べたので、自然に非対称暗号化があります。そのアイデアは単純で、2つの素数の積は簡単で計算するのですが、2つの素数の積に分解する順番に、非常に複雑な操作を通過することは困難です。二つの鍵、1つの公共と民間1と非対称暗号化。公開鍵暗号化コンテンツを復号化できる唯一の秘密鍵である、唯一の秘密鍵暗号、公開鍵は、コンテンツを復号化することができます。一般的に、我々は秘密鍵と呼ばれる鍵を発表していない、私の所持してサーバーを置く、誰でも公開鍵と呼ばれて得ることができます。クリックして表示する httpsで認証プロセスのグラフィック詳細を。
通常、対称暗号化を使用すると、はるかに高速非対称暗号化よりも、はるかに少ない圧力を計算するサーバー。
Q5：どのように対称鍵を転送します
ダイレクトサーバリターンは平文対称暗号鍵は安全ではありません。キーを取得するリスナーがある場合、あなたはまだ、その後の通信クライアントとサーバの内容を知らないのか？
BS：非対称暗号化を使用して
だから、それはそうでない場合は、これはの鶏・卵のパラドックス同じ缶が転送されていない新たな対称鍵である、クリアテキスト対称鍵で渡されていない、とも新しい対称暗号化アルゴリズムは、元の対称秘密鍵を暗号化するためにすることができますオン。
ここでは、非対称暗号化方式を導入し、非対称暗号化特性は、内容を暗号化するために、サーバの秘密鍵の暗号化を決定し、誰もが公開鍵を持っているので、真実ではないが、暗号文は、サーバーのすべてを解決することができます。二つの大きな利点をもたらすサーバーの手の中にだけ秘密鍵嘘：
サーバーのコンテンツによって送られた1は、他の人はプライベートではありませんので、それが暗号化されていない、偽造することはできません。公開鍵で暗号化された結果として強制することは、クライアントが解けことができないということです。
サーバのみが唯一の真のサーバが暗号化されたテキストを見ることができている秘密鍵を持っているので2は、内容を暗号化する公開鍵を持つ人は、絶対に安全です。
対称秘密鍵伝送問題が解決されるように：秘密鍵はサーバーによって配信が、クライアントによって生成され、サーバーに伝えるためのイニシアチブを取ることはありません。
非対称暗号化の導入は、HTTPSハンドシェイクがまだ2段階のプロセスであるが、詳細は多少異なるときに：
クライアントは：こんにちは、私はHTTPS要求を開始する必要があり、これが私の（使用して公開鍵暗号）キーです。
サーバー：はい、私はあなたの秘密鍵を知っている、そしてそれに続く転送はそれを使用します。
Q5：どのように公共交通機関
あなたはまだ鶏、鶏と卵の問題を解決していないように見えます。あなたは、クライアントが要求を送信するとき、それは、その後どのように公共交通機関、公開鍵暗号化対称鍵を使用するように言いましたか？
BS：ライン上で公開鍵暗号。。。
それぞれの使用はサーバが認証局の証明書を登録する特別に行かなければならないHTTPS、認証局は、公開鍵と秘密鍵の暗号化を保存します。だから、上の復号化機関にクライアントの公開鍵という。
4つのステップに今はハンドシェークフェーズHTTPSプロトコル：
1.クライアント：こんにちは、私はHTTPS要求を開始したいと思いますが、私の公開鍵を与えてください
2、サーバー：OK、これは暗号化された公開鍵を持っている私の証明書であり、
3、クライアント：成功した復号化した後は、サーバーに指示します：これは私の対称鍵を（公開鍵暗号化を使用して）されます。
4、サーバー：OK、私はあなたの秘密鍵を知っている、そしてそれに続く転送はそれを使用します。
Q6：あなたはあなたと私をからかっています。。。。
その公共交通機関、どのように？
BS：コンピュータに保存されています
公共の交通機関を持っていない、それが工場出荷時の設定では、主要なオペレーティング・システム（またはブラウザ）に直接構築されます。一方では理由の各サーバの内蔵コンピュータの理由がない公開鍵、サーバーが多すぎるので、しかし、保存してください。一方のオペレーティングシステムでは、あなたは、これが百度/証明書淘宝網、それであると言うことができますどのように、あなたを信頼しないのですか？
各企業は、最初の証明書を申請し、認証局に行かなければならないので、その後、オペレーティングシステムは、唯一の公共機関を格納します。そのための権限の限られた数のため、オペレーティングシステムのベンダーが管理することが比較的容易です。権限が十分な権限でない場合は、XJBは、証明書を発行し、我々は、このような貧しいVorthongとして、彼の資格を取り消します。。。。
Q7：どのように証明書が改ざんされていない知っているのですか？
あなたは、最初のサーバーは、私はこの証明書が信頼できることを知っていますか、後で公開鍵暗号である証明書を返すと言いましたか？
BS：情報とともに送信されたハッシュ値の情報
我々は、すべてのビューの機能のポイントは、どのように複雑なデータに関係なく（カスタムフィールドは非常に大きなものとなります）場合、それは値を取得するハッシュアルゴリズムの後に、データを圧縮することができ、ハッシュアルゴリズムの特性を知って、特にこの値値の範囲（範囲ドメインよりもはるかに小さいです）。同じデータのハッシュ結果は必ずしも同じハッシュ結果は同じデータが一般的に異なっているが、また、小さな確率が、これはハッシュ衝突と呼ばれ、繰り返されているされていません。
元の証明書が改ざんされていないことを確実にするために、我々は同じ時間譲渡証明書で証明書のハッシュ値を渡すことができます。サードパーティのデータを解決できないので、唯一のXJBが変更され、その後、変更されたデータの復号した後、ハッシュを渡すことは不可能です。
例えば、公開鍵は、こんにちは前の例である暗号化された文字列がIfmmppあるので、我々は、ハッシュ値がOであるこんにちは、ハッシュアルゴリズムは、文字の最後の文字列を取得することであることを前提としています。すべての人に知られている公開鍵を解読することができますが、暗号解読、改ざん行うことができますが、何の秘密鍵がないので、それが正しい暗号化ではありません。それは、クライアントのデータに戻っているので、公開して解析された無効なデータが、文字化けしますです。攻撃者が偶然、またハッシュチェックで繰り返し試みを通じて解決できる場合でも。
Q8：それはポーズこれを防ぎ、サードパーティ製のサーバー
BS：たぶんすることができます
まず、実サーバは、他人に改ざんすることができないコンテンツを配信します。それが解読することができるように彼らは、公共の権威を持っていますが、そこには、秘密鍵がないので、情報は後で復号化を暗号化することはできませんので。暗号化しないか、エラー情報は必ずしもハッシュチェックを通じて、後でクライアントを復号化する公開鍵で暗号化されていません。クリックして表示する httpsで認証プロセスのグラフィック詳細を。
しかし、あなたがサーバ要求を開始した場合、真ではありませんが、攻撃者は、この時間は、彼が仲介攻撃を実行する機会がありました。私たちは、サーバ証明書は、自分の身元を証明するために発行されるときに最初のハンドシェイクは、この証明書は、復号化するためのデバイス公開鍵のデフォルトを使用することを知っています。だから、どちらかの証明書認証を通り、その後、復号化権限当局に秘密鍵で暗号化し、いずれかの秘密鍵の権限で非暗号化され、その後、復号化するための公開鍵を見つけることができません。
だから、あなたは、非ルート証明機関がインストールされて慎重にされていない場合は、そのような複数のプリセット公開鍵のデバイス上の悪意のあるハッカーの証明書が、今回のように、暗号化を適切に解析することができ、悪質な証明書の秘密鍵を使用しています。だから、悪質な証明書のドアを残すことに等しいルート証明書をインストールしないでください。
もちろん、二つの側面を持っている人。私たちは、チャールズがデバッグHTTPSトラフィックが、その原理は、ルート証明書チャールズをインストールするには、ユーザーの必要性があることを知っている、と我々はチャールズにプロキシサーバーを要求されますが、チャールズは正しく解決するために、その証明書を発行しました。一方、チャールズは、右のHTTPS証明書を取得するには、真のサーバから、その後の通信のために、クライアントのようになります。漏洩した後は幸いなことに、チャールズは意志のユーザーに大きな影響を引き起こし、不正なソフトウェア、またはその秘密鍵ではありません。クリックして表示する httpsで認証プロセスのグラフィック詳細を。
私は最も高価なのEV（バリデーションを拡張）と呼ばれている証明書、複数の種類があり、あなたの例を与えることができ、それは、利点は明白です手動審査を申請するいくつかのビジネスライセンスおよび他の文書を必要とし、それがブラウザのアドレスバーの左に正確であることができますこのようのBitbucketの公式サイトとして、会社名、：
クライアントが直接接続されているとき、これは正常です。プロキシチャールズ、チャールズ・クライアントが証明書を持って使用している場合でも、それはなります：
Q9：HTTPS握手それがパフォーマンスに影響します
そこTCP 3ウェイハンドシェイクに加え、HTTPS 4ウェイハンドシェイクは、それがパフォーマンスに影響を与えないのだろうか？
BS：確かに影響を与えるが、許容されています
少し遅くなることが第一には、HTTPSは確かに、時間は主に、暗号化と復号化時間対称アルゴリズムはほとんど無視できる、読み、SSLの2つのセットの間の証明書の時間のかかる検証に費やされます。
そして、最初のハンドシェイクでない場合、後続の要求は、ハンドシェイクを完了する必要はありません。クライアントはすぐに、あなたがクリックすることができます詳細回復する最後のサーバーの場合に直接暗号化送信することができます表示するには、httpsで認証プロセスのグラフィック詳細を。。
また、SSLハンドシェイク時にのみ暗号化された情報を送信するために使用されていない、あなたはまた、クライアントとサーバがHTTP2非互換タスクを伝える取ることができます。したがって、HTTP2.0にHTTPSからの切り替えは、オーバーヘッドどんなパフォーマンスを持っていないのではなく、多重化技術HTTP2.0のために、それ以降は、多くの時間を節約することができます。
HTTPS2.0場合の目標としては、HTTPSパフォーマンスの損失にも小さい方が、はるかに少ないそれはセキュリティのアップグレードをもたらしますより。
エピローグ
私は、ヘルプ新規参入者への9つの以上の質問が十分HTTPSを理解すると信じていますが、これは、（iOSのいくつかの特定の問題など）HTTPSの使用に関する基本的な概念だけでも試してみて、研究を継続する必要があります。