HTTPSが接続セキュリティを提供する方法：すべてのWeb開発者が知っておくべきこと

とにかくHTTPSはどのように機能しますか？ これは、私のドラフトで数日間苦労してきた質問です。



Web開発者として、HTTPSを使用してユーザーデータを保護することは非常に良いアイデアであることに気付きましたが、HTTPSが実際にどのように機能するかについて明確に理解できたことはありませんでした。



データはどのように保護されますか？ 誰かがすでに自分のチャンネルを聞いている場合、クライアントとサーバーはどのようにして安全な接続を確立できますか？ セキュリティ証明書とは何ですか？また、なぜそれを取得するために誰かにお金を払わなければならないのですか？

パイプライン

これがどのように機能するかを説明する前に、インターネット接続を保護することが非常に重要である理由と、HTTPSが保護するものについて簡単に説明しましょう。



ブラウザがお気に入りのWebサイトにリクエストを送信する場合、このリクエストはさまざまなネットワークを経由する必要があります。これらのネットワークは、確立された接続をリッスンしたり、干渉したりする可能性があります。







自分のコンピューターからローカルネットワーク上の他のコンピューター、ルーターやスイッチ、プロバイダー、および他の多くの中間プロバイダーを介して、膨大な数の組織がデータを中継します。 攻撃者が少なくとも1つに自分自身を見つけた場合、送信されたデータを確認する機会があります。



原則として、要求は通常のHTTPを使用して送信され、クライアントの要求とサーバーの応答の両方がクリアテキストで送信されます。 また、HTTPがデフォルトの暗号化を使用しない理由はたくさんあります。



•これには、より多くの計算能力が必要です。

•より多くのデータが送信されています。

•キャッシングは使用できません



ただし、場合によっては、非常に重要な情報（パスワードやクレジットカードデータなど）が通信チャネルを介して送信される場合、そのような接続をリッスンしないように追加の対策を講じる必要があります。

トランスポート層セキュリティ（TLS）

これから暗号の世界に突入しますが、これには特別な経験は必要ありません。最も一般的な問題のみを検討します。 そのため、暗号化により、接続を操作したり、単に聞きたい攻撃者から接続を保護できます。



TLS （SSLの後継）は、安全なHTTP接続（HTTPSと呼ばれる）を提供するために最もよく使用されるプロトコルです。 TLSは、OSIモデルの HTTPプロトコルの下にあります。 指で説明すると、これは、要求の実行プロセスで、TLS接続に関連付けられたすべての「もの」が最初に発生し、次にHTTP接続に接続されたすべてが発生することを意味します。



TLSはハイブリッド暗号化システムです。 これは、いくつかの暗号化アプローチを使用することを意味します。これについてはさらに検討します。



1）共有秘密鍵と認証を生成するための非対称暗号化 （公開鍵暗号システム）（つまり、自分が本人であることを確認する）。

2）リクエストとレスポンスをさらに暗号化するための秘密鍵を使用した対称暗号化 。

公開鍵暗号システム

公開鍵暗号システムは、各側に公開鍵と秘密鍵の両方があり、数学的に関連する暗号システムの一種です。 公開キーはメッセージテキストを意味不明に暗号化するために使用され、秘密キーはソーステキストを解読および取得するために使用されます。



メッセージは公開鍵を使用して暗号化されているため、対応する秘密鍵でのみ復号化できます。 どのキーも両方の機能を実行できません。 公開キーは、システムを脅威にさらす危険を冒すことなくパブリックドメインで公開されますが、秘密キーは、データを解読する権利を持っていない人には届かないはずです。 したがって、公開鍵と秘密鍵があります。 非対称暗号化の最も印象的な利点の1つは、以前は相互に完全に認識していなかった2つのサイドが、安全な接続を確立でき、最初はオープンで安全でない接続でデータを交換できることです。

クライアントとサーバーは、独自の秘密鍵（それぞれ独自の）と公開された公開鍵を使用して、セッションの共有秘密鍵を作成します。



これは、誰かがクライアントとサーバーの間にいて接続を監視している場合でも、クライアントの秘密鍵、サーバーの秘密鍵、またはセッション秘密鍵を見つけることができないことを意味します。



これはどのように可能ですか？ 数学！

Diffie-Hellmanアルゴリズム

最も一般的なアプローチの1つは、Diffie-Hellman （DH） 鍵交換アルゴリズムです。 このアルゴリズムにより、クライアントとサーバーは、共有キーを接続上で渡す必要なく、共有秘密キーについて合意できます。 したがって、例外なくすべてのデータパケットを傍受した場合でも、チャネルでリッスンしている攻撃者は秘密キーを特定できません。



DHアルゴリズムを使用したキー交換が行われるとすぐに、取得した秘密キーを使用して、より単純な対称暗号化を使用して、このセッション内のさらなる接続を暗号化できます。

ちょっとした数学...

このアルゴリズムの基礎となる数学関数には重要な特徴があります-順方向では比較的簡単に計算できますが、実際には逆方向では計算されません。 これはまさに、非常に大きな素数が作用する領域です。



アリスとボブを、DHアルゴリズムを使用してキーを交換する2つのパーティとします。 最初に、それらは何らかのルートベース（通常は2,3または5などの小さな数）と非常に大きな素数 （300桁以上）で一致します。 どちらの値も、接続を危険にさらすことなく、通信チャネルを介してクリアテキストで送信されます。



アリスとボブの両方が独自の秘密鍵（100桁を超える）を持っていることを思い出してください。これらの秘密鍵は通信チャネルを介して送信されることはありません。



primeおよびrootの値と同様に秘密鍵から取得した混合物は、通信チャネルを介して送信されます。



このように：

アリスの混合物=（ルート^アリスの秘密）％素数

ボブの混合=（ルート^ボブの秘密）％プライム

ここで、％は除算の残りです。



したがって、アリスは承認された定数値（ rootとprime ）に基づいて混合物を作成します。ボブも同様です。 相互の混合値を受け取るとすぐに、追加の数学的操作を実行してセッションの秘密鍵を取得します。 すなわち：



アリスの計算

（ボブの混合物^アリスの秘密）％prime



ボブの計算

（アリスの混合物^ボブの秘密）％prime



これらの操作の結果は、アリスとボブの両方で同じ番号になり、この番号がこのセッションの秘密鍵になります。 いずれの当事者も通信チャネルを介して秘密鍵を送信してはならず、受信した秘密鍵もオープン接続を介して送信されなかったことに注意してください。 いいね！



数学的にあまり知識のない人のために、ウィキペディアは色の混合を例として使用してこのプロセスを説明する素晴らしい写真を提供しています。







最初の色（黄色）が最終的にボブとアリスの両方で同じ「混合」色に変わることに注意してください。 オープンな通信チャネルを介して送信されるのは半分混合された色のみであり、通信チャネルを聞いている人にとっては実際には無意味です。

対称暗号化

キーの交換は、接続の確立中にセッションごとに1回のみ行われます。 関係者が秘密鍵についてすでに合意している場合、追加の確認コストが必要ないため、情報の送信にははるかに効率的な対称暗号化を使用してクライアントとサーバーの対話が行われます。



以前に取得した秘密キーを使用し、暗号化モードに同意すると、クライアントとサーバーは安全にデータを交換し、秘密キーを使用して互いに受信したメッセージを暗号化および復号化できます。 チャネルに接続する攻撃者は、ネットワークをあちこち歩き回っている「ゴミ」を見るだけです。

認証

Diffie-Hellmanアルゴリズムにより、2者が秘密の秘密鍵を取得できます。 しかし、どのようにして双方が実際に互いに話し合っていることを確認できますか？ 認証についてはまだ話していません。



友人に電話したら、DHキー交換を実行しますが、突然電話が傍受され、実際に他の人と話をしていることがわかりました。 私はまだこの人と安全に通信できます-誰も私たちの話を聞くことはできません-しかし、それは私が話していると思う人ではありません。 これはあまり安全ではありません！



認証の問題を解決するには、サブジェクトが自分の言うとおりの人物であることを確認できる公開鍵インフラストラクチャが必要です。 このインフラストラクチャは、デジタル証明書を作成、管理、配布、および失効するように設計されています。 証明書は、サイトがHTTPSで動作するために支払う必要がある迷惑なものです。



しかし、実際には、この証明書は何であり、どのようにセキュリティを提供しますか？

認証

最も大まかな概算では、デジタル証明書は電子デジタル署名（詳細は1分）を使用し、コンピューターの公開（公開）キーをその所属に関連付けるファイルです。 証明書にデジタル署名するとは、特定の公開キーが特定の個人または組織に属しているという事実を誰かが証明していることを意味します。



基本的に、証明書はドメイン名を特定の公開キーに関連付けます。 これにより、クライアントがアクセスしているサーバーを装うことにより、攻撃者が公開鍵を提供することを防ぎます。



上記の電話の例では、ハッカーは私の友人を装って彼の公開鍵を見せようとするかもしれませんが、彼の証明書の署名は私が信頼する人のものではありません。



Webブラウザーが証明書を信頼するには、認定された証明機関（Certificate Authority、CA）によって署名されている必要があります。 CAは、証明書を取得しようとしている人が次の2つの条件を満たすことを手動で検証する会社です。



1.本当に存在する;

2.証明書を取得しようとしているドメインにアクセスできます。



CAは、申請者が本物であり、ドメインを本当に制御していることを確認するとすぐに、CAはこのサイトの証明書に署名し、実際に、サイトの公開キーが本当に彼に属し、信頼できるという事実に確認スタンプを設定します。



認定されたCAのリストは、ブラウザから既にプリロードされています。 サーバーが認定CAによって署名されていない証明書を返した場合、大きな赤い警告が表示されます。 それ以外の場合は、誰もがダミー証明書に署名できます。







したがって、ハッカーがサーバーの公開鍵を取得し、この公開鍵がfacebook.comに関連付けられていることを確認するデジタル証明書を生成した場合でも、証明書は認定CAによって署名されていないため、ブラウザーはこれを信じません。

証明書に関するその他の注意事項

拡張検証

通常のX.509証明書に加えて、より高いレベルの信頼を提供する拡張検証証明書があります。 このような証明書を発行することにより、CAは証明書を受け取る人に対してさらに多くのチェックを実行します（通常はパスポートの詳細またはアカウントを使用）。



このような証明書を受け取ると、ブラウザは通常のロックアイコンに加えて、アドレスバーに緑色のバーを表示します。

1つのサーバーで複数のWebサイトを提供する

TLSプロトコルを介したデータの交換はHTTP接続の開始前でも行われるため、複数のWebサイトが同じIPアドレスの同じWebサーバーにある場合、問題が発生する可能性があります。 仮想ホストはWebサーバーによってルーティングされますが、TLS接続はさらに早く発生します。 サーバー上にあるサイトへのリクエストには、サーバー全体の単一の証明書が使用されます。これにより、複数のホストを持つサーバーで問題が発生する可能性があります 。



Webホスティングサービスを使用している場合、ほとんどの場合、HTTPSを使用するには専用のIPアドレスを購入する必要があります。 それ以外の場合は、サイトが更新されるたびに新しい証明書を常に受信（および検証）する必要があります。



ウィキペディアにはこのトピックに関する多くのデータがあり、 コースラにはコースがあります。 今朝私の質問に答えてくれたsecurity.stackexchange.comのチャットの人たちに特に感謝します。



翻訳者のメモ：



1）トピックに関する素晴らしいリンクを提供してくれたwowkin habrayuzerに感謝します（ビデオはfreetonik habrayuzerが翻訳し、声を出しています ）：







2）コメントで展開した議論の結果に基づいて（habrayuzer a5b 、 Foggy4およびAllenの参加に感謝）、メイン記事に次の情報を補足します。



最新のSSL調査（240万のSSLサイト、2013年6月）に基づくネットクラフトによると 、ほとんどのSSL接続はPerfect Forward Secrecyアルゴリズムを使用していません： news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted- tomorrow.html



IE（バージョン10でさえ）の場合、状況は特に悪いです。IEでは、楕円曲線（RSAおよびECDSA証明書）でのみDiffie-Hellmanをサポートします。

netcraftの推定によると、IEへの接続の99.7％、Chrome、Opera、Firefoxへの接続の66％はDiffie-Hellmanを使用しません。



ディスカッションの Hacker Newsで、これも注目されました。

また、（私は私の話で同じ間違いをしました...）、はい、DHを説明することは重要ですが、今ではTLSで両方がDHを使用してマスターシークレットを把握しているように聞こえます（そして、あなたの話では、具体的には、実際には暗号スイートに依存する通常のDH（ECベースのDHではありません）、およびTLS接続の大部分はそのようには機能しません。 野生ではほとんどのTLS構成であると私が理解していることから、プリマスターシークレットはサーバーの公開キーを使用して暗号化されます。 （RFC 5246：7.4.7.1、8.1.1）

それは重要で興味深いことですが、誰もが実際にはそれほど頻繁に使用されないことを理解しているわけではありません。 ほとんどのSSLおよびTLSセッションでは、RSAを使用して暗号化することによりキー交換が行われます。