MITコース「コンピューターシステムのセキュリティ」。 講義14：「SSLおよびHTTPS」パート2

マサチューセッツ工科大学。 講義コース6.858。 「コンピューターシステムのセキュリティ。」 ニコライ・ゼルドヴィッチ、ジェームズ・ミケンズ。 2014年

コンピューターシステムセキュリティは、安全なコンピューターシステムの開発と実装に関するコースです。 講義では、脅威モデル、セキュリティを危険にさらす攻撃、および最近の科学的研究に基づいたセキュリティ技術を扱います。 トピックには、オペレーティングシステム（OS）セキュリティ、機能、情報フロー管理、言語セキュリティ、ネットワークプロトコル、ハードウェアセキュリティ、およびWebアプリケーションセキュリティが含まれます。



講義1：「はじめに：脅威モデル」 パート1 / パート2 / パート3

講義2：「ハッカー攻撃の制御」 パート1 / パート2 / パート3

講義3：「バッファオーバーフロー：エクスプロイトと保護」 パート1 / パート2 / パート3

講義4：「特権の共有」 パート1 / パート2 / パート3

講義5：「セキュリティシステムはどこから来たのか？」 パート1 / パート2

講義6：「機会」 パート1 / パート2 / パート3

講義7：「ネイティブクライアントサンドボックス」 パート1 / パート2 / パート3

講義8：「ネットワークセキュリティモデル」 パート1 / パート2 / パート3

講義9：「Webアプリケーションのセキュリティ」 パート1 / パート2 / パート3

講義10：「シンボリック実行」 パート1 / パート2 / パート3

講義11：「Ur / Webプログラミング言語」 パート1 / パート2 / パート3

講義12：ネットワークセキュリティパート1 / パート2 / パート3

講義13：「ネットワークプロトコル」 パート1 / パート2 / パート3

講義14：「SSLおよびHTTPS」 パート1 / パート2 / パート3



第1の理由は、OCSPプロトコルが行うすべての要求に遅延を追加することです。 サーバーに接続するたびに、まずOCSPに接続し、OCSPが応答するのを待ってから、別の操作を行う必要があります。 そのため、接続遅延は決してこのプロトコルの人気に寄与しません。



2番目の理由は、OCSPがWebを閲覧する能力に影響を与えたくないことです。 OSCPサーバーがダウンし、インターネットが完全に失われる可能性があるとします。プロトコルは誰かの証明書を検証できないため、インターネット上のすべてのサイトが不良であり、そこに行くことを許可されない可能性があるとプロトコルが考慮しているためです しかし、誰もこれを必要としないため、ほとんどの顧客はOCSPサーバーの非干渉を前向きな開発と見なしています。







これは、セキュリティの観点からは本当に悪いです。 あなたが攻撃者であり、正当な証明書を持っていることを誰かに納得させたいが、実際にはこの証明書が取り消された場合、あなたがする必要があるのはクライアントがOCSPサーバーと通信することを何らかの形で防ぐことだけだからです。



クライアントはこう言います：「必要なサイトの証明書検証を要求しようとしていますが、このOCSPは近くにないので、このサイトに行くだけです。」 したがって、OCSPを使用することは適切な計画ではありません。



実際には、顧客は単に重大な間違いを犯す傾向があるため、人々はこの代替案を作成しようとします。 そのため、たとえば、Chrome Webブラウザーはクライアントに配信され、Googleが本当に失効させたい証明書のリストを既に内部に持っています。 そのため、誰かがGmailやFacebookやAmazonなどの別の重要なサイトの証明書を誤って発行した場合、Chromeの次のバージョンには組み込みの検証リストにこの情報が既に含まれます。 したがって、CRLサーバーにアクセスしてOCSPと通信する必要はありません。 ブラウザが証明書が有効ではなくなったことを確認した場合、クライアントはそれを拒否します。



学生：すべての公開鍵が暗号化されているわけではないため、CA秘密鍵を盗んだとしましょう。



教授：はい、これは悪い結果をもたらすでしょう。 この問題の解決策はないと思います。 もちろん、認証センターが侵害された状況もありました。たとえば、2011年には、GmailやFacebookなどの証明書を何らかの形で発行した2つの侵害されたCAがありました。 これがどのように起こったのかは明確ではありません。誰かが本当に自分の秘密鍵を盗んだのでしょう。 しかし、侵害の理由に関係なく、これらのCAはブラウザに組み込まれている信頼できる認証局のリストから削除されたため、Chromeの次のリリースには含まれていません。



実際、以前の証明書が無効になり、新しい証明書を取得する必要があったため、これらのセンターによって発行された証明書の正当な所有者に問題が発生しました。 したがって、実際には、証明書に関するこの大騒ぎはかなり混乱した問題です。



そのため、証明書の一般原則を検討しました。 常にオンラインである必要がないという意味で、Kerberosよりも優れています。 さらに、複数のKDCを使用でき、接続を確立するたびにKDCと通信する必要がないため、より拡張性があります。



このプロトコルのもう1つの興味深い機能は、Kerberosとは異なり、接続の両側を認証する必要がないことです。 自分用の証明書がなくてもWebサーバーに接続できます。これは常に発生します。 amazon.comにアクセスすると、Amazonが適切なサイトであることを確認することになりますが、Amazonはあなたが誰であるかわからず、サイトを認証するまでそのことを知りません。 したがって、暗号化プロトコルのレベルでは証明書はありませんが、Amazonには証明書があります。



Kerberosサービスに接続するには、データベースにエントリが必要なので、これはKerberosよりもはるかに優れています。 このプロトコルを使用する唯一の不便な点は、サーバーに証明書が必要なことです。 そのため、サーバーに接続して、「ちょっと、暗号化しましょう」と言うことはできません。 私はあなたが誰なのか分かりませんが、あなたは私が誰なのかわかりませんが、とにかくそれを暗号化しましょう。 これは日和見暗号化と呼ばれ、もちろん、中間者攻撃に対して脆弱です。 知らないうちに誰かと共通のものを暗号化することができます。その後、攻撃の準備をしている攻撃者は、後でパケットを暗号化し、himself索から身を守ることができます。



したがって、ここで検討しているこれらのプロトコル（SSL、TLS）がこの種の日和見暗号化を提供していないことは少し残念です。 しかし、それは人生です。







学生：私はただ興味があります。 年に一度、新しい名前でキーペアを作成するとします。 この特定のキーを1年間使用してみませんか？



教授：そうだと思います。 しかし、この回路には何か問題があるようです。 ここでは、Kerberosと同様に、人々は強力な暗号化を使用することから始めますが、時間の経過とともに悪化します。 コンピューターはより高速になり、この暗号化を正常に解読する新しいアルゴリズムが開発されています。 そして、人々が信頼性の向上を気にしないと、問題は大きくなります。 そのため、たとえば、膨大な数の証明書が署名されると発生します。



ここには2つのニュアンスがあります。 公開鍵署名スキームがあります。 さらに、暗号化された公開キーにはいくつかの制限があるため、実際にはメッセージに署名するとき、巨大なメッセージに署名することは困難ですが、コンパクトなハッシュに署名するのは簡単なので、このメッセージのハッシュのみが署名されます。



人々はMD5をハッシュ関数として使用し、巨大なメッセージの署名を暗号化された128ビットのものに変えたため、問題が発生しました。 MD5は20年前には良かったのかもしれませんが、やがて人々は攻撃者が悪用できる弱点を発見しました。



ある時点で、誰かが実際に特定のMD5ハッシュを持つ証明書を要求し、同じMD5値でハッシュされた別のメッセージを慎重に解析したとします。 その結果、彼はハッシュ化されたCA署名を取得し、別のメッセージが表示されたり、別のキーまたは別の名前が表示されたりしたため、正しい証明書で署名されていることを誰かに納得させることができました。 そして、これは本当に起こっています。 たとえば、1つのキーをクラックしようとして多くの時間を費やすと、最終的には成功します。 この証明書が暗号化を使用している場合、ブルートフォース方式を使用して解読できます。



暗号化の使用に失敗する別の例は、RSAアルゴリズムです。 RSAについては説明しませんでしたが、RSAはこれらの公開キー暗号化システムの1つであり、メッセージの暗号化と署名を可能にします。 最近では、多くのお金を使うことができますが、最終的には1000ビットのRSAキーを解読します。 膨大な量の作業が必要になる場合がありますが、これは年間を通じて簡単に実行できます。 認証局にメッセージに署名するよう依頼するか、誰かの既存の公開鍵を取得するか、適切な秘密鍵を見つけるか、手動でハッキングすることができます。

したがって、攻撃者についていく必要があり、より大きなRSAキーを使用するか、別の暗号化スキームを使用する必要があります。



たとえば、現在、人々はMD5ハッシュと証明書を使用していません。 彼らはSHA-1暗号ハッシュアルゴリズムを使用します。 しばらくの間、それは必要なセキュリティを提供しましたが、今日では弱い防御です。 現在、GoogleはWeb開発者とブラウザー開発者にSHA-1の使用を放棄し、別のハッシュ関数を使用するように積極的に試みています。おそらく、5年または10年後、SHA-1の攻撃に成功することは難しくないからです。 彼の弱さはすでに証明されています。



ですから、魔法のような弾丸は存在しません。 ハッカーと並行して開発を続けることを確認する必要があります。 もちろん、問題は存在します。 したがって、私たちが話したすべてのことは、適切な暗号化、またはクラッキングするのが非常に難しいという事実に基づいている必要があります。 したがって、適切なオプションを選択する必要があります。 少なくとも有効期限があるため、10年ではなく1年の有効期限を選択することをお勧めします。







有効期限がないため、この鍵CAはより深刻な問題を引き起こします。 したがって、4000または6000ビットのRSAキーなど、より積極的なセキュリティ設定を選択する必要があります。 または、別の暗号化スキーム、またはすべて一緒ですが、ここではSHA-1を使用しないでください。



次に、このプロトコルを特定のアプリケーション、つまりWebブラウザに統合する方法を見てみましょう。 ネットワーク通信または暗号化を使用するサイトとの通信を提供する場合、ブラウザーには3つの保護が必要です。



まず、Aはネットワーク上のデータ保護です。 これは比較的簡単です。これまで説明したプロトコルと非常によく似たプロトコルを実行するだけだからです。 すべてのメッセージを暗号化し、署名し、改ざんされていないことを確認します。一般に、これらすべてのすばらしいことを行います。 これがデータを保護する方法です。



しかし、Webブラウザーには、さらに心配する必要がある2つのことがあります。 そのため、最初のBはブラウザで使用されるコードです。たとえば、JavaScriptやブラウザに保存される重要なデータ、Cookie、ローカルストレージなど、これらはすべて何らかの方法でハッカーから保護する必要があります。 すぐにそれらを保護する方法を説明します。



最後の1つであるCは、よく考えませんが、実際には実際の問題になる可能性があるのは、ユーザーインターフェイスの保護です。 そして、その理由は、最終的に、私たちが保護に関心を寄せる機密データのほとんどはユーザーからのものだからです。 そのため、ユーザーはあるサイトにデータを印刷し、おそらく異なるサイトの複数のタブを同時に開いているため、いつでも実際に操作しているサイトを区別できる必要があります。







彼が何らかのWebフォーラムでAmazonパスワードを誤って入力した場合、Amazonパスワードをどの程度気にするかによって悲惨な結果につながることはありませんが、それでも不快です。 したがって、適切なサイトに機密データを印刷するかどうか、および送信後にこのデータに何かが発生したかどうか、ユーザーが何をしているかを理解するのに役立つ優れたユーザーインターフェイスが必要です。 したがって、これはWebアプリケーションを保護するための非常に重要な問題であることが判明しました。



それでは、これらのA、B、Cを使って最新のブラウザが何をするかについて話しましょう。 前述したように、ネットワーク上のデータを保護するために、暗号化と認証が使用される場合、SSLまたはTLSと呼ばれるこのプロトコルを使用します。







これは、説明した内容と非常によく似ており、認証局などが含まれます。 そして、もちろん、さらに多くの詳細があります。 たとえば、TLSは非常に複雑ですが、この観点からは考慮しません。 ブラウザーの保護に焦点を当てますが、これはさらに興味深いものです。 私たちの脅威モデルは、ネットワーク上の攻撃者によってすべての暗号化されていないデータが改ざんされる可能性があるため、暗号化されていない接続を介して配信されるコードまたはデータが暗号化された接続から受信したコードとデータを変更できないことを確認する必要があります。



そのため、ブラウザで何らかの暗号化されていないJavaScriptコードを実行している場合、暗号化されていないため、攻撃者によって改ざんされた可能性があると想定する必要があります。 ネットワーク経由で認証されませんでした。 したがって、暗号化されていない接続を介して配信されたページからの干渉を防ぐ必要があります。



したがって、一般的な計画では、このためにHTTPSと呼ばれる新しいURLスキームを導入する予定です。 これはURLでよく見られます。 新しいURLスキームは、これらのURLがHTTPアドレスとは単に異なるということです。 したがって、このHTTPS：//のURLがある場合、通常のHTTP URLとは異なる発信元ソースがあります。後者は暗号化されていないパッチを通過するため、SSL / TLSを通過します。 このように、同じ発信元ポリシーが正しく機能する場合、これらのタイプのアドレスを混同することはありません。



したがって、これはパズルの一部です。 しかし、その後、暗号化されたサイトを相互に正しく区別することも確認する必要があります。これは、歴史的な理由で異なるCookieポリシーを使用しているためです。 それでは、まず、異なる暗号化サイトをどのように区別するかについてお話ししましょう。



計画では、URLを介したホスト名を証明書の名前にする必要があります。 実際、証明機関がホスト名に署名しようとしていることがわかります。ホスト名は、Webサーバーの公開キーの名前としてURLに表示されます。 そのため、Amazonにはwww.amazon.comの証明書があると言われています。 これは、プライベートキーに対応するパブリックキーを持つテーブル内の名前です。







これはブラウザが探すものです。 したがって、証明書を受信した場合、 foo.com URLに接続または取得しようとすると、サーバーは本物のfoo.com証明書を正確に表します。 それ以外の場合、たとえば、接続した証明書の名前が完全に異なるため、ある人と連絡を取り、別の人と連絡を取ろうとしました。 これは証明書の不一致です。



CAは適切なネットワークメンバーにのみ証明書を発行することを約束するため、CAをこのサイトに相互に区別できるようにするために、CAを導入します。 したがって、これは同じ生成元ポリシーの一部であり、コードを複数の部分に分割します。 お気づきのとおり、Cookieのポリシーはわずかに異なります。 それらはほとんど同じ起源のものですが、完全ではありませんが、Cookieの計画はわずかに異なります。 Cookieには、セキュリティフラグと呼ばれるセキュリティフラグがあります。 ルールは、Cookieにこのフラグがある場合、HTTPS要求への応答でのみ送信されるか、HTTPS要求と共に送信されるというものです。 セキュリティフラグのあるクッキーとないフラグは、httpsおよびhttpリクエストとして相互に関連しています。







これは少し複雑です。 CookieがHTTPSホストのCookieであり、HTTPホストのCookieであることが単に示されていて、それらが完全に異なっていた場合、それは簡単です。 これは、安全なサイトを安全でないサイトから分離するという点で非常に明確です。 残念ながら、歴史的な理由から、Cookieはこの奇妙な種類の対話を使用します。



したがって、Cookieが安全とマークされている場合、HTTPSサイトにのみ適用されます。つまり、正しいホストを持ちます。 安全なCookieはHTTPSホストURLにのみ適用されますが、安全でないCookieはhttpsとhttpの両方のURLの両方のタイプに適用されるため、すぐにこれが問題の原因になります。



そして、この点で私たちを助けるためにウェブブラウザが行う最後のタッチは、ユーザーがそれを見ることができるように何らかの種類のロックアイコンを入力するユーザーインターフェイスの側面です。 したがって、ブラウザのアドレスバーのロックアイコンとURLに注意して、実際にどのサイトにいるかを確認する必要があります。



Webブラウザーの開発者は、このように振る舞うことを期待しています。Webサイトにアクセスしたら、まずURLを見て、これが話したいホストの名前であることを確認すると、ロックアイコンとすべてがうまくいくことを理解してください。 これは、ブラウザのユーザーインターフェイスの一面です。



ただし、これでは十分ではありません。 多くのフィッシングサイトでは、サイト自体にロックアイコンの画像が含まれているだけですが、別のURLを使用していることがわかります。 そして、あなたがこのサイトのアドレスがどうあるべきかを知らなければ、あなたはだまされるかもしれません。 この意味で、ユーザーインターフェースのこちら側は少し混乱します。これは、ユーザー自身がしばしば混乱するためです。 だからここに何があるのか​​言うのは難しい。 したがって、主に2番目の側面であるBに焦点を当てます。 これについて質問がありますか？







学生：一部のサイトは、時間の経過とともにHTTPからHTTPSに変わることに気付きました。



教授：はい、ブラウザーは時間とともに進化します。これは、ロックアイコンが表示されるという事実によって確認されます。 一部のブラウザは、ページ上のすべてのコンテンツまたはすべてのリソースもhttps経由で送信される場合にのみロックアイコンを設定します。 HTTPSが強制的に解決しようとしている問題の1つは、混合コンテンツまたはページに埋め込まれた安全でないタイプのコンテンツの問題です。 したがって、このチェックのためにロックアイコンを取得できない場合があります。 Chromeブラウザがサイト証明書が十分ではないと判断し、弱い暗号化を使用している場合、ロックアイコンは表示されません。 ただし、ブラウザによって動作が異なり、Chromeでロックアイコンが表示されない場合は、Firefoxでも可能です。 したがって、このロックアイコンの意味の明確な定義はありません。



, . HTTP DNS, IP- . DNS HTTPS URL-? DNS DNS?



: , , , IP-.



: , , , amazon.com.



: , - amazon.com, IP-.



: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?



: , HTTPS?



: , , .



: , HTTP URL.



: , HTTPS, .



: .



: , . . , CA, , , , - , .



, - https , - , , , , , , .



HTTPS , - . , . , , , . -. « , ». , , , - , . , - .



, , , . , amazon.com www.amazon.com , , , .



-, , , . , : „ , , , , ». , - , . .



, DNS, , , .



, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .



, — , ? , , ? , ?







: , - , . , .



: , , , , , , : « »! , , - , , , , . , .



: , .



: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .



, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .



52:10



MITコース「コンピューターシステムのセキュリティ」。 14: «SSL HTTPS», 3





コースの完全版はこちらから入手できます 。



ご滞在いただきありがとうございます。 ? より興味深い資料を見たいですか？ , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? （オプションはRAID1およびRAID10、最大24コア、最大40GB DDR4で利用可能です）。



VPS（KVM）E5-2650 v4（6コア）10GB DDR4 240GB SSD 1Gbpsまで 6か月の期間を支払う場合は12月まで無料で 、 ここで注文できます 。



Dell R730xdは2倍安いですか？ オランダと米国で249ドルからIntel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TVを2台持っているだけです！ インフラストラクチャの構築方法について読む クラスRは、1米ドルで9,000ユーロのDell R730xd E5-2650 v4サーバーを使用していますか？