現在、おそらく、半分以上のサーバーがhttpプロトコルからhttpsプロトコルに移行しています。なんで？まあ、それはクールなセキュリティです。

このセキュリティとは何ですか？ Habréを含め、このトピックに関する多くの記事がすでに書かれています。しかし、もう1つ追加したいと思います。

私が書くことにした理由

私は一般に、職業別のAndroid開発者であり、暗号化と情報保護プロトコルについてはあまりうろつきません。したがって、これに直接対処しなければならなかったとき、理論的な知識の深さの大きさに少しショックを受けました。

私はさまざまなソースを調べ始めましたが、このトピックを理解するのはそれほど簡単ではなく、HabréまたはWikiの記事を読むだけでは不十分であることがわかりました。聖書です。」したがって、それを理解するのに少し時間がかかりました。だから、それを考え出して、私はこれを共有し、私と同じ新人のために、またはなぜhttpではなくhttpsがURLバーにあるのか疑問に思っている人々のために記事を書くことにしました。

安全な通信チャネルとはどういう意味ですか？

データチャネルを安全と見なすには、3つの基本原則に従う必要があります。

信頼 -接続を確立するときのサブスクライバーの相互認証。
暗号化 -不正アクセスからチャネルを介して送信されるメッセージの保護。つまり、対話中は、あなたとあなたの対談者だけが話し、聞くことができます。
整合性の確保（データ整合性） -チャネル上の着信メッセージの整合性の確認。メッセージは、情報の全部または一部を置き換えることはできません。

この記事では、信頼のメカニズムについてのみ詳しく説明したいと思います。

信頼とはどういう意味ですか？

相手が本人であると確信している場合にのみ、相手を信頼できます。

最も単純な例-あなたが話している人を知っている、より複雑な人-あなたが意図した人を個人的に知っている人を知っていて、この人はあなたが話している人を信頼できることを保証します。

人生の例

アパートを買いたいと想像してください。

これを行うには、アパートを販売する全米リアルター協会加入者を見つけます。

不動産業者は、彼が特定の開発者と協力し、この開発者からアパートを提供すると言います。

開発者は、彼が建てる住宅は貸し出され、 不動産業者にお金を支払った人はそれを不動産に入れ、州は建設の合法性と所有権を確保すると言います。

合計で、4つのエンティティ（ You 、 Realtor 、 Developer 、 State）があります。

トランザクションが正常に行われ、だれもだまされないようにするために、州はトランザクションの合法性を保証する文書を定義する法律と、これらの文書の信頼性を保証する印刷または署名メカニズムを作成しました。

これらの文書と印章の例があります。州から入手できます。

あなたには、元の建設書類を不動産業者に求める権利があります。

全米リアルター協会加入 者は、 開発者の文書を受け取ります。これは、州の文書によってサポートされており、アパートが販売できることを確認します-それらは合法です。

開発者は、国から文書を受け取ります。

つまりこれで、 開発者と国家の印で封印された彼の文書に基づいて、 不動産業者とのみ安全に対話を行うことができます！

HTTPSを信頼する

そして、Life Exampleからキャラクターの名前を変更しましょう。

あなた = クライアント

全米リアルター協会加入者 = サーバー

開発者 = 中間認証局（中間CA）

状態 = メイン認証局（ルートCA）

メイン認証局（CA）は有名な有名な会社であり、国際機関は証明書と署名を管理する権限を発行しています。つまり、誰もがこの会社を信頼しています。

それはIntermediate CAsに何らかの権威を与えるかもしれません、そして、彼らはMain Centerに代わってドキュメントに署名するでしょう。

数学に進む

言葉が言及された：署名、証明書など。これを実装する方法は？ 非対称暗号化が便利です。

詳細に入らないようにし、個別の数学と暗号化について説明しないために、いくつかのことを明確にします。

1）非対称暗号化に関する主なことについて簡単に説明します。

パブリックキーとプライベートキーの 2つのキーがあります。実際、キーは単なる大きな数字です。

メッセージがPublicで暗号化されている場合、それに対応する秘密鍵のみが復号化できます。

そしてその逆：

メッセージがPrivateで暗号化されている場合、対応する公開鍵のみが解読できます。

秘密鍵は誰にも与えられません。公開 -実際には公開です。

2） デジタル署名は、発行者の秘密鍵で暗号化されたドキュメントの一部です。サブスクライバーの公開キーを使用して暗号化を解除できる場合、それを暗号化したのはサブスクライバーであると自信を持って述べることができます。

3） 証明書（デジタル証明書）は通常ファイルであり、ほとんどの場合、拡張子は.cerまたは.pemです。

次のものが含まれます。

所有者情報（件名）
加入者情報（発行者）
署名情報（SSLバージョン、アルゴリズム）
署名ハッシュ（証明書の指紋）
公開鍵
デジタル署名
有効期限
また、バージョンによっては多くの情報がありますが、残りはまだ必要ありません。

証明書の例

COMODO認証局

アイデンティティ：COMODO認証局

検証者：COMODO認証局

有効期限：12/31/29

件名

C（国）：GB

ST（州）：大マンチェスター

L（地域）：サルフォード

O（組織）：COMODO CA Limited

CN（共通名）：COMODO認証局

発行者名

C（国）：GB

ST（州）：大マンチェスター

L（地域）：サルフォード

O（組織）：COMODO CA Limited

CN（共通名）：COMODO認証局

発行された証明書

バージョン：3

シリアル番号：4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3D

以前は無効：2006-12-01

無効：2029-12-31

証明書の指紋

SHA1：66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7B

MD5：5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75

公開鍵情報

キーアルゴリズム：RSA

主なパラメータ：05 00

キーサイズ：2048

キーSHA1フィンガープリント：11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3

公開鍵：30 82 01 0A 02 82 01 01 00 D0 40 8B 8B 72 E3 91 1B F7 51 C1 1B 54 04 98 D3 A9 BF C1 E6 8A 5D 3B 87 FB BB 88 CE 0D E3 2F 3F 06 96 F0 A2 29 50 99 AE DB 3B A1 57 B0 74 51 71 CD ED 42 91 4D 41 FE A9 C8 D8 6A 86 77 44 BB 59 66 97 50 5E B4 D4 2C 70 44 CF DA 37 95 42 69 3C 30 C4 71 B3 52 F0 21 4D A1 D8 BA 39 7C 1C 9E A3 24 9D F2 83 16 98 AA 16 7C 43 9B 15 5B B7 AE 34 91 FE D4 62 26 18 46 9A 3F EB C1 F9 F1 90 57 EB AC 7A 0D 8B DB 72 30 6A 66 D5 E0 46 A3 70 DC 68 D9 FF 04 48 89 77 DE B5 E9 FB 67 6D 41 E9 BC 39 BD 32 D9 62 02 F1 B1 A8 3D 6E 37 9C E2 2F E2 D3 A2 26 8B C6 B8 55 43 88 E1 23 3E A5 D2 24 39 6A 47 AB 00 D4 A1 B3 A9 25 FE 0D 3F A7 1D BA D3 51 C1 0B A4 DA AC 38 EF 55 50 24 05 65 46 93 34 4F 2D 8D AD C6 D4 21 19 D2 8E CA 05 61 71 07 73 47 E5 8A 19 12 BD 04 4D CE 4E 9C A5 48 AC BB 26 F7 02 03 01 00 01

サブジェクトキー識別子

キー識別子：0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FF

クリティカル：いいえ

キーの使用法

用途：デジタル署名

クリティカル：はい

基本的な制約

認証局：はい

最大パス長：無制限

クリティカル：はい

延長

識別子：2.5.29.31

値：30 40 30 3E A0 3C A0 3A 86 38 68 74 74 70 3A 2F 2F 63 72 6C 2E 63 6F 6D 6F 64 6F 63 61 2E 63 6F 6D 2F 43 4F 4D 4F 44 4F 43 65 72 74 69 66 69 63 61 74 69 6F 6E 41 75 74 68 6F 72 69 74 79 2E 63 72 6C

クリティカル：いいえ

署名

署名アルゴリズム：RSAを使用するSHA1

署名パラメーター：05 00

署名：3E 98 9E 9B F6 1B E9 D7 39 B7 78 AE 1D 72 18 49 D3 87 E4 43 82 EB 3F C9 AA F5 A8 B5 EF 55 7C 21 52 65 F9 D5 0D E1 6C F4 3E 8C 93 73 91 2E 02 C4 4E 07 71 6F C0 8F 38 61 08 A8 1E 81 0A C0 2F 20 2F 41 8B 91 DC 48 45 BC F1 C6 DE BA 76 6B 33 C8 00 2D 31 46 4C ED E7 9D CF 88 94 FF 33 C0 56 E8 24 86 26 B8 D8 38 38 DF 2A 6B DD 12 CC C7 3F 47 17 4C A2 C2 06 96 09 D6 DB FE 3F 3C 46 41 DF 58 E2 56 0F 3C 3B C1 1C 93 35 D9 38 52 AC EE C8 EC 2E 30 4E 94 35 B4 24 1F 4B 78 69 DA F2 02 38 CC 95 52 93 F0 70 25 59 9C 20 67 C4 EE F9 8B 57 61 F4 92 76 7D 3F 84 8D 55 B7 E8 E5 AC D5 F1 F5 19 56 A6 5A FB 90 1C AF 93 EB E5 1C D4 67 97 5D 04 0E BE 0B 83 A6 17 83 B9 30 12 A0 C5 33 15 05 B9 0D FB C7 05 76 E3 D8 4A 8D FC 34 17 A3 C6 21 28 BE 30 45 31 1E C7 78 BE 58 61 38 AC 3B E2 01 65

各被験者で何が起こるか

1）ルートCAから始めましょう

生成された秘密鍵
公開鍵により生成
CA情報が追加され、有効期限が設定されます。
証明書はあなた自身の秘密鍵で署名されます：
- 暗号化するメッセージ（メッセージ）を選択します。正確に暗号化するものは、アルゴリズムとSSLのバージョンによって決まります。エンドユーザーにとって、これは重要ではありません。暗号化とハッシュのすべてのバージョンも証明書に配置され、復号化するときにこれらのバージョンも使用されるためです。
- メッセージは暗号化され、デジタル署名が取得されます。
- メッセージがハッシュされ、FingerPrintが取得されます。
  
  これはすべてヒープに収集され、いわゆる自己署名証明書になります。

2）この自己署名証明書は顧客に配布されます

クライアントの例はブラウザーです。どのブラウザーでも、証明書のリストを表示できます。

たとえば、Chromeの場合：[設定]-> [証明書の管理]-> [権限]。

これで、クライアントはCAの存在を認識しました。

3）真正性の確認

詳細に触れない場合、この項目はサーバーと中間認証センターで同じです

生成された秘密鍵
公開鍵により生成
CA情報が追加され、有効期限が決定されます
いわゆる証明書署名要求（CSR ）が生成されます。
CSRは 、最も近い認証局チェーンの秘密鍵によって署名されます。実際、これは、証明機関が次の証明書に次々と署名するときに、最後の証明書であるサーバー証明書と呼ばれるものです。

その結果、クライアントに自己署名証明 書があり、サーバーに署名済みサーバー証明書があります。クライアントはCAを認識および信頼しており、CAはサーバーの信頼性を保証しています。

4）直接対話

次に、クライアントがサーバーにアクセスしたときに何が起こるか見てみましょう。これを行うには、 Wiresharkのネットワークダンプを使用します。

TCP 3ウェイハンドシェイク-TCPプロトコルを使用して接続を開始するメカニズム。ダンプから、クライアントがポート33311から、ポート8443で実行されているサーバーとの接続を開始したことがわかります。
安全なデータ伝送-これは、暗号化されたチャネルを介したデータの直接転送です。
TLSハンドシェイクが私たちの関心事です。詳細についてはこちらをご覧ください。ただし、証明書の使用のみを検討します。

メッセージが表示されます：

クライアントHello、サーバーHello、暗号仕様の変更、暗号化されたハンドシェイクメッセージ

以下は、これらのメッセージが携帯されていることを示しています。

ご覧のとおり、 Server Helloと共に、サーバーはサーバー証明書チェーンを受け取ります。

クライアントが証明書を認証する方法。これはどのように起こりますか：

1） クライアントは、チェーンのトップ証明書のルートCAがあるかどうかを確認します。

そうでない場合は、下のチェーンをたどり、証明書がチェーン内の前の証明書によって本当に署名されているかどうかを再確認するたびに。（簡単です-下位のデジタル署名は、上位の公開鍵で復号化する必要があります）。

見つからなかった場合、クライアントとサーバーに共通のCA友人がいないことを意味し、サーバーを信頼できません。

2）存在する場合- クライアントは証明書の公開鍵を取得し、サーバーから送信された証明書の署名を復号化しようとします。

動作しない場合、サーバーはCA証明書を置き換えており、信頼できない
そして最後に、すべてが正常で、すべてが復号化され、すべての証明書の有効期限が有効であり、SSLバージョンによって決定されるその他の条件が満たされている場合、サーバーは信頼できます。

ご注意

TLSプロトコルは、クライアントのサーバー信頼メカニズムもサポートします。図5からわかるように、Server Helloへの応答で、クライアント証明書が届く場合があり、サーバーはCAが信頼性を保証したことを確認することもできます。

おわりに

だから、双方が彼らの対談者が自分自身であると主張する者であると確信したとき、あなたは対話を始めることができます。さらに、メッセージをさらに暗号化するためのすべてがすぐにあります。サーバー側の秘密鍵と、サーバー証明書とともに送信されたクライアントの公開鍵です。ただし、将来、クライアントがサーバーの公開キーでパスワードを暗号化し、サーバーに送信するときに-KlientKeyExchange 、非対称暗号化が1回だけ使用されます。さらに、このパスワードは非対称メッセージ暗号化にすでに使用されています。これは、非対称パスワードよりもはるかに高速で簡単だからです。暗号化プロトコルを選択し、メッセージの整合性を保証するメカニズムは、数学と暗号化の大きな分野ですが、ユーザーにとって幸いなことに、SSLの裏ですでに実装されています。必要なのは、クライアントとサーバーが互換性のあるバージョンのSLL、暗号、暗号化プロバイダーを持つことだけです。

最後に、安全な通信プロトコルと言いたいと思います。

非常に複雑で紛らわしい-バージョン、プロトコル、暗号の海があり、メッセージをいつ受け取るかわからない-「NoSuchAlgorithmException-互換性のないバージョン」または「IllegalBlockSizeException-大きすぎるまたは小さすぎる」
一貫性のない-今日、ブラウザは通常サーバーにアクセスしますが、明日はすでに2048はキーの長さが小さすぎると言っており、安全ではないと言って、入りません
コンピューティング、特に非対称暗号化では、リソースを大量に消費します。5〜7歳のシステムでは、TLSハンドシェイクプロセスに10〜20秒かかります。

しかし、それに対する主な、そしておそらく十分な議論は、HTTPSとTLSは可能な限り真に安全であるということです。

HTTPSの信頼原則