HTTPSの最も優れた説明

皆さんおはようございます。しばらく記事を更新していませんでした。

実は、私は流行中に1か月以上家にいて外出もできなかったので、時間がたくさんありました。この時間を利用して、いくつかの新しい記事を書きました。しかし、これらの書き下ろし記事のほとんどは新刊の内容に沿ったものであり、疫病の影響で新刊の刊行が遅れ、これらの記事も出版できず、大変不安を感じています。早くこの流行が終息し、皆様が一日も早く通常の生活に戻れるよう願っております。

そこで今日はAndroidとは全く関係のない技術記事を公開します。

https テクノロジーは現在広く使用されています。 AppleやGoogleなどの主要なインターネットリーダーが、自社のオペレーティングシステム、ブラウザ、その他の主流製品でhttpsの使用を義務付けているため、httpの廃止は正式にカウントダウンに入りました。

実際、コードは http リクエストの記述と変わらないため、クライアント開発者が https に関して注意する必要がある特別な点はありません。しかし、多くのクライアント開発者が https を理解していないのは、まさにこの理由からです。開発者は、https が安全な暗号化ネットワーク伝送であることは知っているものの、その具体的な動作原理については何も知りません。

では、クライアント開発者は本当に https を理解する必要があるのでしょうか?それはまだ必要だと思います。https の動作原理を習得すると、仕事で遭遇するいくつかの問題をより効果的に理解し、解決するのに役立ちます。さらに、多くの企業は面接中に https 関連の質問をいくつかするのが好きです。それについて何も知らない場合は、ここで簡単に排除されます。

https について学んでいたとき、私はオンラインで多くの情報を参照しましたが、ほとんどの記事は理解しにくく、多くの人が https を恐れていました。 https の仕組みを理解するには、必ずしもすべての詳細を知る必要はないと思います (インターネット上の多くの記事は詳細に書かれすぎていて理解しにくいです)。実際には、全体的なワークフローを把握し、それがなぜネットワーク通信のセキュリティを確保できるのかを理解するだけで十分です。そこで、今日は https について最も分かりやすく説明します。

https について正式に説明を始める前に、まず対称暗号化と非対称暗号化という 2 つの概念を明確にする必要があります。これら 2 つの概念は暗号化の基本的な知識であり、実際には非常に理解しやすいものです。

対称暗号化は比較的単純です。つまり、クライアントとサーバーは同じキーを共有し、そのキーを使用してコンテンツを暗号化したり、コンテンツを復号化したりすることができます。対称暗号化の利点は暗号化と復号化の効率が高いことですが、クライアントに保存されている鍵が盗まれるリスクがあるため、セキュリティの面で問題がある可能性があります。対称暗号化の代表的なアルゴリズムとしては、AES、DES などがあります。

非対称暗号化はもう少し複雑です。鍵を公開鍵と秘密鍵の 2 種類に分けます。公開鍵は通常クライアントに保存され、秘密鍵は通常サーバーに保存されます。公開鍵で暗号化されたデータは秘密鍵でのみ復号化でき、逆に秘密鍵で暗号化されたデータは公開鍵でのみ復号化できます。非対称暗号化の利点は、クライアントからサーバーに送信された暗号化された情報はサーバーの秘密鍵でのみ復号化できるため、他人に解読される心配がなく、より安全であることです。ただし、欠点は、暗号化と復号化の効率が対称暗号化よりもはるかに悪いことです。非対称暗号化の代表的なアルゴリズムとしては、RSA、ElGamal などがあります。

これら 2 つの概念を習得したら、https の学習を開始できます。ここで事前に質問しておきますが、これは面接でもよく聞かれる質問でもあります。データ転送のセキュリティを確保するために、https では対称暗号化と非対称暗号化のどちらが使用されていますか?

この記事を読めば答えが分かります。

まず、ネットワーク伝送中に従来の http 方式に存在する問題を見てみましょう。

データを送信する際、情報はプレーンテキストで送信されるため、データが監視され、盗まれる可能性が高くなります。概略図は以下のとおりです。

さらに、送信されたデータは悪意のある人物によって改ざんされる可能性があり、その結果、ブラウザと Web サイトが送受信するコンテンツに不一致が生じる可能性があります。概略図は以下のとおりです。

つまり、http を使用してデータを送信すると、データが監視され、データが改ざんされるという少なくとも 2 つの大きなリスクがあります。したがって、http は安全でない送信プロトコルです。

さて、解決策は https を使用することだということは誰もが知っているはずですが、まずは http 送信のセキュリティを確保する方法について考えてみましょう。そうすれば、https の動作原理を段階的に理解できるようになります。

ネットワーク上でプレーンテキストでデータを送信するのは安全ではないため、当然データを暗号化する必要があります。前述したように、暗号化には主に対称暗号化と非対称暗号化の 2 つの方法があります。対称暗号化の利点は、暗号化と復号化の効率が高いことです。インターネット上でデータを送信する場合、効率性に非常にこだわるため、ここで対称暗号化を使用する必要があるのは明らかです。概略図は以下のとおりです。

ご覧のとおり、インターネット上で送信されるデータはすべて暗号化されているため、盗聴者は元のテキストが何であるかを知ることができないため、盗聴される心配はありません。ブラウザは暗号文を受け取った後、Web サイトと同じキーを使用してデータを復号化するだけです。

この動作メカニズムはデータ転送のセキュリティを確保するように見えますが、大きな抜け穴があります。ブラウザと Web サイトは、どのキーを使用するかについてどのように合意するのでしょうか?

これはコンピュータの世界では間違いなく難しい問題です。通常、ブラウザと Web サイトは同じキーを使用してデータを暗号化および復号化する必要がありますが、そのキーを 2 つだけが知り、盗聴者に知られないようにするにはどうすればよいでしょうか。どのような合意がなされたとしても、ブラウザと Web サイト間の最初の通信プロセスはプレーンテキストで行われなければならないことがわかります。つまり、上記のワークフローに従っても、安全な対称暗号化キーを作成することはできません。

したがって、対称暗号化のみを使用しても、この問題は解決されないと思われます。現時点では、対称暗号化キーを安全に作成できないという問題を解決するために、非対称暗号化を導入する必要があります。

では、なぜ非対称暗号化がこの問題を解決できるのでしょうか?概略図で理解してみましょう。

ご覧のとおり、対称暗号化キーを安全に作成したい場合は、ブラウザにランダムに生成させることができますが、生成されたキーをネットワーク上で直接送信することはできません。代わりに、Web サイトが提供する公開キーを使用して非対称暗号化する必要があります。公開鍵で暗号化されたデータは秘密鍵でのみ復号化できるため、ネットワーク経由でのこのデータの送信は完全に安全です。メッセージを受信した後、Web サイトは秘密鍵を使用してメッセージを復号化し、ブラウザーによって生成されたキーを取得するだけです。

また、この方法を使用する場合、非対称暗号化は、ブラウザとウェブサイトが最初にキーに同意するときにのみ必要です。ウェブサイトがブラウザによってランダムに生成されたキーを受信すると、両者は対称暗号化を使用して通信できるため、作業効率が非常に高くなります。

さて、上記の動作メカニズムは完璧だと思いますか?実はそうではありません。まだ非常に重要なステップが欠けているからです。ブラウザはどのようにして Web サイトの公開鍵を取得できるのでしょうか?公開鍵は公開データであり、他人に盗聴される心配なくインターネット経由で送信できますが、公開鍵が他人に改ざんされたらどうなるでしょうか?概略図は以下のとおりです。

つまり、インターネットからどのウェブサイトの公開鍵を取得するかに関係なく、その公開鍵が改ざんされるリスクが存在します。偽の公開鍵を使用してデータを暗号化すると、偽の秘密鍵を持つ他者によって復号化され、悲惨な結果を招く可能性があります。

このソリューションの設計はここで行き詰まっているようです。なぜなら、どうやってもウェブサイトの公開鍵を安全に取得することはできず、世界中のすべてのウェブサイトの公開鍵をオペレーティングシステムに事前に設定することは明らかに不可能だからです。

このとき、行き詰まりを打破するために、CA エージェンシーという新しい概念を導入する必要があります。

CA 組織は、さまざまな Web サイトにデジタル証明書を発行するために特別に使用され、ブラウザーがさまざまな Web サイトの公開キーを安全に取得できるようにします。では、CA 組織はこの困難なタスクをどのように達成するのでしょうか?段階的に分析を始めましょう。

まず、ウェブサイト管理者として、CA 機関に申請し、公開鍵を CA 機関に提出する必要があります。 CA 組織は、私たちが提出した公開鍵と、Web サイトのドメイン名、有効期間などの一連の他の情報を使用して証明書を作成します。

証明書が生成されると、CA はそれを独自の秘密鍵で暗号化し、暗号化されたデータを当社に返します。当社は、取得した暗号化データを Web サイトサーバー上で設定するだけです。

その後、ブラウザが当社の Web サイトをリクエストするたびに、暗号化されたデータがまずブラウザに返され、ブラウザは CA の公開キーを使用してデータを復号化します。

復号化が成功すると、CA 組織が Web サイト用に発行した証明書を取得できます。もちろん、これには Web サイトの公開キーも含まれます。下の図に示すように、ブラウザのアドレスバーの URL の左側にある小さなロックアイコンをクリックすると、証明書の詳細情報を表示できます。

公開鍵を取得した後のプロセスは、先ほどの図で説明したものと同じです。

復号化に失敗した場合、この暗号化データは正当な CA 組織によって秘密鍵を使用して暗号化されておらず、改ざんされている可能性があることを意味します。その場合、下の図に示すように、ブラウザに有名な異常なインターフェイスが表示されます。

では、CA 代理店なら本当に安全なのかと疑問に思うかもしれません。ブラウザ側でデータを復号化するには CA の公開鍵を使用する必要がありますが、CA の公開鍵を安全に取得するにはどうすればよいでしょうか?

この問題は、世の中にウェブサイトは無数にあるのに、CA 代理店は数えるほどしかないため、簡単に解決できます。正規のオペレーティングシステムには、すべての主要な CA 組織の公開キーがオペレーティングシステムに組み込まれているため、個別に取得する必要はありません。復号化の際には、システムに組み込まれているすべての CA 組織の公開キーを走査するだけで済みます。どの公開キーでもデータを正常に復号化できる限り、合法であることを意味します。

Windows システムに組み込まれている証明書は次のとおりです。

しかし、CA の公開鍵を使用してデータを正常に復号化できたとしても、現在のプロセスには依然として問題が残っています。各 CA 機関は何千もの Web サイトに証明書を発行するため、abc.com が特定の CA 機関の証明書を使用していることを攻撃者が知っていれば、その CA 機関にアクセスして正当な証明書を申請し、ブラウザーが abc.com を要求したときに返された暗号化された証明書データを置き換えることもできます。概略図は以下のとおりです。

攻撃者が申請した証明書も正規の CA 組織によって作成されたものであるため、この暗号化されたデータは当然正常に復号化できることがわかります。

このため、すべての CA 組織は、Web サイトの公開キーに加えて、検証を支援するために作成する証明書に他の多くのデータも含める必要があります。たとえば、Web サイトのドメイン名は重要なデータの 1 つです。

同じ例で、Web サイトのドメイン名が証明書に追加された場合、攻撃者は何も得られません。暗号化されたデータが正常に復号化されたとしても、最終的に復号化された証明書に含まれるドメイン名がブラウザが要求しているドメイン名と一致しないため、ブラウザには異常なインターフェイスが表示されます。概略図は以下のとおりです。