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

マサチューセッツ工科大学。 講義コース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



HTTPSの施行は、証明書を使用するかどうかを決定する際の裁量が多すぎるユーザーに対する懸念によるものだと思います。



実際に発生し、HTTPSの使用を強制する別の問題は、安全でない添付ファイルまたはWebページ上の混合コンテンツです。 この問題のポイントは、安全なサイトまたは任意のWebサイトが、そのほかのコンテンツをWebページに埋め込むことができるということです。



したがって、foo.com / index.htmlなどの何らかのWebサイトがある場合は、HTTPSプロトコルを使用して提供できますが、HTMLページ内には、ブラウザーを強制的にどこかに移動させ、その一部にするための多くのタグを含めることができますこのページには、ある種のエイリアンコンテンツがあります。







このシナリオのタグは次のようになります。

<script scr = «http://jquery.com/…”>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

jquery.comのソースを指します。 したがって、人気のあるJavaScriptライブラリーは、ブラウザー内の多くのものの相互作用を促進します。 しかし、多くのWeb開発者は、単に別のサイトのURLにリンクしています。 これは物事を簡単にしますが、何がキャッチになるのでしょうか？ 安全なサイトがあり、そこからjQueryをダウンロードするだけだとします。



学生：それは偽のjQueryかもしれません。



教授：はい、そうです。 実際には、受け取ることを期待していない間違ったものを取得する2つの方法があります。 1つの可能性は、jQuery自体が危険にさらされる可能性があることです。 あなたはあなたが要求したものに似た何かを得ました。 jQueryが危険にさらされている場合、これは非常に悪いことです。 別の可能性は、この要求が暗号化または認証なしでネットワークを介して送信されることです。 したがって、攻撃者がネットワーク接続を制御している場合、攻撃者はこのリクエストをインターセプトし、応答として別のJavaScriptコードを送信することができ、このJavaScriptコードはページの一部として機能します。 そして、彼はこのHTTPSドメインfoo.comで働いているため、保護されたcookie foo.comおよびこのページの他のすべてにアクセスできます。 これは本当に悪いことのように思えますので、注意してください。 また、Web開発者は、この種の間違いをしないように注意する必要があります。



したがって、1つのソリューションは、安全なページに埋め込まれたすべてのコンテンツのセキュリティを確保することです。 これは、多くのWeb開発者が従うべき優れたガイドラインです。 したがって、この行でjquery.comの代わりにjquery.comを使用する必要があります。 または、URLがオリジンポリシーをサポートしている場合、HTTPSの一部を省略して、このスクリプトのオリジンが//jquery.com/である、つまりscr = "//jquery.com / ..."とだけ言うことができることを意味します







つまり、このタグは、HTTPSページにある場合はjquery.comに 、HTTPSではなく通常のHTTP URLにある場合はjquery.comに送信することを意味します。 これは、このような問題を回避する1つの方法です。



ただし、人々は常にすべてを改善しようとしているため、この問題を解決する別の方法の1つは、おそらくタグにハッシュまたはインジケーターのようなものを含めることです。

 <script scr = «http://jquery.com/…”>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ダウンロードするコンテンツの種類がわかっている場合は、おそらくHTTPSプロトコルを使用して完全にダウンロードする必要はありません。 実際、特定のハッシュに一致する限り、このコンテンツをだれが提供するかは気にしません。



したがって、この種のタグのハッシュを構成できる新しい仕様があります。 そのため、HTTPS URLを使用してjquery.comにリンクする代わりに、スクリプトソースがjquery.comまたはHTTPであるとだけ言うこともできますが、スクリプトの最後に何らかの種類のタグ属性を追加します。たとえば、ハッシュはサーバーから取得したいと考えています。







学生：この仕様の名前は何ですか？



教授：複雑な名前を持ち、講義ノートのノートにあります。「サブリソースの整合性」、サブリソースの整合性などです。 実装はかなりゆっくりですが、近い将来、さまざまなブラウザに適用されることを願っています。 これは、ネットワークレベルでのデータ暗号化に依存せずにコンテンツを認証する別の方法に似ています。



したがって、SSLとTLSを使用して特定のサーバーへの接続を認証するこの非常に一般的な計画があります。 これは、ネットワーク接続を保護する代替方法です。 整合性を重視する場合、暗号化された安全なネットワークチャネルは必要ない場合があります。 必要なのは、最終的に何を取得するかを正確に指定することだけです。



学生：このSRCコードはクライアントからのものではありませんか？



教授：彼はクライアント側で働いていますが、クライアントはサーバーからこのコードを受け取ります。



学生： JavaScriptコードをページに入力することはできませんか？



教授：できると思います。 したがって、ハッシュの意味は、他のJavaScriptコードを入力しようとする侵入者からページのコンテンツを保護することです。 jQueryでは、jQueryソースコードを非表示にしようとしていないため、jQueryはよく知られているため、これは非常に重要です。 したがって、ネットワーク攻撃者が接続を傍受してjQueryの悪意のあるバージョンを挿入できないようにして、Cookieの漏洩の原因となるようにする必要があります。 誰もがこれらのもののハッシュを自分で理解できることは事実です。 したがって、これはプライバシーではなく整合性の問題の解決策です。



開発者は、ページを記述するか、HTMLページのコンテンツをHTTPS URLに含めるときに、これに注意を払う必要があると思います。 もう1つの懸念は、Cookieに関するものです。 これは、セキュリティフラグ付きのCookieと、オリジンオリジンのCookieの違いが関係するところです。 開発者がここで台無しにできる唯一のことは、そもそもクッキーにフラグを設定することを忘れることです、これは起こります。 おそらく、彼はHTTPS URLのみにアクセスするユーザーについてのみ考え、フラグを設定する必要はないと考えています。 これは問題ですか？ ユーザーが非常に慎重で、常にHTTPS URLにアクセスする場合、問題はありません。 この場合、Cookieにセキュリティフラグを残すことは理にかなっていると思いますか？



学生：攻撃者がURLに接続し、悪意のあるサイトにリダイレクトする可能性はありますか？



教授：はい。 ユーザーがプレーンテキスト形式のURLに明示的に手動でアクセスしなくても、攻撃者は安全でないサイトへのリンクを提供したり、HTTPS以外のURLの画像をダウンロードするように要求したりできます。 そして、安全でないCookieがネットワーク要求とともに送信されます。 したがって、これは問題であり、ユーザーとアプリケーションが非常に慎重であっても、本当にフラグが必要です。



学生：安全なHTTP URLがあると思います。

教授：はい、そうです。 ポート80をリッスンしていないサイトがあり、ポート80を介して接続する方法がないため、安全でないCookieを使用すると問題が発生する可能性があると仮定します。



学生：ブラウザーがCookieを別のドメインに送信できないため。



教授：まったくその通りです。ブラウザーは別のドメインにCookieを送信しませんが、攻撃者が自分のURLをダウンロードする危険性はまだあります。 したがって、amazon.comはSSLのみを使用し、ポート80でもリッスンしないと仮定します。その結果、Cookieにセキュアフラグを設定しません。 Amazonがポート80でリッスンしていなくても、ハッカーはどうやってクッキーを盗むことができますか？



学生：ブラウザはこれがHTTP接続であるとまだ考えることができますか？



教授：まあ、ポート443に接続してSSLまたはTLSを使用する場合、接続は常に暗号化されるため、これは問題ではありません。



学生：攻撃者が接続を傍受する可能性があります。



教授：はい、攻撃者はポート80を介してAmazonに接続しようとしているパケットを傍受し、サイトに正常に接続したふりをすることができます。 したがって、攻撃者がネットワークを制御している場合、Amazon宛てのパケットを自分のマシンのポート80にリダイレクトすることができ、クライアントはその違いを見ることはできません。 Amazonがポート80でリッスンしているように見えますが、実際には、CookieはこのハッカーのWebサーバーに送信されます。



学生：クライアントが不明なため。



教授：そうです。HTTPには、接続しているホストの信頼性を検証する方法がないからです。 これはまさに起こっていることです。 HTTPには認証がありません。 したがって、ネットワークの敵がいると想定する場合、このHTTP接続の宛先がわからないため、最初にCookieがHTTP経由で送信されないようにする必要があります。



学生：このためには、ネットワークを制御する必要があります。



教授：はい、もちろん。 ネットワークを完全に制御できる場合、相手はパケットを傍受できないことがわかります。 ただし、ネットワークを完全に制御している場合でも、トラブルが発生する可能性があります。TCPの講義の資料を見て、さまざまな種類のネットワーク攻撃を調べました。



対象者：しかし、この場合、リダイレクト攻撃を防ぐことはできませんか？



教授：ハッカーは、 amazon.comでのクライアントのhttpリクエストを傍受する可能性が高く、このリクエストには、amazon.comのすべてのCookie、またはリクエストを送信する他のドメインのCookieが含まれます。 したがって、これらのCookieを安全としてマークしない場合、暗号化された接続と暗号化されていない接続の両方で送信できます。



学生：このリクエストはどのように開始されますか？



教授：たぶん、ユーザーにnewyorktimes.comにアクセスしてもらうことができます。newyorktimes.comでは、 amazon.comから画像をアップロードする広告の支払いをしました。 また、ユーザーが「このURLから画像をダウンロードしてください」という質問を防ぐことはできません。 ただし、ブラウザがサイトに接続しようとすると、接続が成功した場合、Cookieが送信されます。



HTTPS Everywhere拡張機能があります。これは、強制HTTPSまたは強制HTTPSに非常に似ており、この種のエラーを防止しようとします。 強制HTTPSモードでサイトを選択すると、ブラウザは主にこのホストへのHTTP接続を阻止します。







したがって、Cookieを安全とマークしない、または同様の間違いをする方法はありません。 開発者がCookieにセキュリティフラグを設定するのを忘れた場合、この場合の解決策は明白です。彼は間違いを修正するだけです。 ただし、さらに微妙な問題があります。安全なウェブサーバーがクライアントのCookieを受信すると、このCookieが暗号化接続またはプレーンテキスト接続のどちらで送信されたかはわかりません。 実際、サーバーはCookieのキー値を2、3しか受信しないためです。



上記のアクションプランから、リクエストを安全なサーバーに送信する場合、ブラウザーには安全なCookieと安全でないCookieの両方が含まれることになります。 ただし、サーバー側では、機密性は保証されません。また、サーバーがユーザーCookieを受信すると、暗号化接続とテキスト接続の両方で送信できます。 これは、セッション固定などの攻撃の可能性につながります。



これは、たとえば、攻撃者が送信する電子メールを見たいことを意味します。 これを行うために、彼は自分のCookieを設定します。これは、GmailアカウントのCookieのコピーです。 また、レターを送信すると、フォルダーではなく、送信済みアイテムフォルダーに表示されます。 攻撃者のアカウントを使用しているかのようになり、攻撃者はメールボックスから通信を抽出できます。 そのため、ハッカーがセッションCookieをブラウザに強制的に入れた場合、彼は自分のアカウントを使用するように強制します。 これは、HTTP CookieとHTTPS Cookieの不完全な分離に関する誤解が原因で発生する別の問題です。



学生：ただし、Cookieを他の誰かのブラウザに挿入するには、そこに脆弱性が必要です。



教授：いいえ、Cookieを設定するために、脆弱性は必要ありません。 ブラウザをだまして通常のHTTPホストURLに接続するだけです。 また、ブラウザにForce HTTPSやHTTPS Everywhereなどの拡張機能がない場合、攻撃者はユーザーのブラウザにキーを設定できます。 これは安全でないCookieですが、安全な要求であっても送り返されます。



学生：このドメインが同じドメインであるとブラウザに思わせるにはどうすればよいですか？

教授：このためには、ネットワーク接続をインターセプトし、数分前に話したタイプの攻撃の1つを実行する必要があります。



では、強制HTTPSは実際に何をしますか？ 彼は多くの問題のいくつかを防ごうとしています。 Force HTTPSプロトコルに関する研究は、5年または6年前に公開されました。 それ以来、標準化され、実際に採用されています。 いくつかのものといくつかのクッキーを保存する大ざっぱなプラグインのように見えます。 今日、ほとんどのブラウザ開発者は、それを作成することは良いアイデアだと信じています。 ブラウザに直接統合することをお勧めします。 HTTP Strict Transport Security（HSTS）と呼ばれるものがあります。これは、HTTPSプロトコルを介した安全な接続を強制するメカニズムです。 これは、科学研究がWebアプリケーションとブラウザのセキュリティにどのように影響するかの良い例です。



Force HTTPSがWebサイトに対して行うことを見てみましょう。 強制HTTPSを使用すると、Webサイトは特定のホスト名に対してこのビットを設定できます。また、HTTPSがブラウザーの動作に影響を与える3つのことがあります。



1つ目は、証明書のエラーは常に致命的であることです。 したがって、ユーザーは、間違ったホスト名や期限切れなどの間違った証明書を受け入れる機会がありません。 これは、ブラウザーを変更する1つのことです。



2つ目は、強制HTTPSはすべてのHTTP要求をHTTPSにリダイレクトすることです。 これはかなり良い考えです。 サイトが常に合法的にHTTPSを使用していることがわかっている場合は、通常のHTTPリクエストを拒否する必要があります。これは、何らかのエラーの兆候または攻撃者が暗号化せずにサイトへの接続を提案しようとしている証拠である可能性があるためです。 HTTPリクエストが実行される前にこれが実際に発生することを確認する必要があります。そうしないと、HTTPリクエストはすでにネットワークに送信されます。



そして、HTTPSがブラウザに強制する最後のことは、以前に検討した安全でない埋め込みプランを禁止することです。これは、HTTPSサイトにHTTP URLを埋め込むときです。







そのため、これがForce HTTPS拡張機能の機能です。 現在使用されている用語に基づいて、HSTSプロトコルでも同じことが行われます。 現在、ほとんどのブラウザはデフォルトで安全でない埋め込みを禁止しています。 多くの開発者がForce HTTPSによる問題を抱えていたため、これは議論の余地がありましたが、Firefox、Chrome、IEはデフォルトで安全でないコンポーネント、または少なくとも安全でないJavaScriptとCSSをページにロードすることを拒否すると思いますそれは間違っています。



学生：行動の実行に関してユーザーに質問しませんか？



教授：彼らは通常、ユーザーが同意するという事実に慣れています。 たとえば、IEはポップアップダイアログを使用して、追加のコンテンツまたはそのようなものをダウンロードするかどうかを尋ねます。 試してみると、これらすべてのセキュリティ対策を回避できると思いますが、これを行うことはお勧めしません。 そのため、最新のブラウザはForce HTTPSおよびHSTSを使用していくつかの問題を解決しようとします。



学生：サイトがHTTPSをサポートしていない場合はどうなりますか？



教授：どういう意味ですか？



学生：ブラウザがHTTPS経由でサイトに接続しないこと。



教授： HTTPSをサポートしないがこれらのCookieを設定するWebサイトがある場合はどうなりますか？ 実際、ブラウザでこのオプションを使用すると、HTTPSを使用しないため、ほとんどのインターネットと通信できなくなります。 したがって、ブラウザは、そのような保護を本当に必要とするサイトとHTTPSを介して通信できる必要があります。



学生：私の記憶が正しければ、サイトが許可するまでクッキーを設定できません。



教授：はい、そうです。 これらの人たちは、このプラグインを使用して他のサイトに問題を引き起こすDoS攻撃を心配しています。 たとえば、疑いを持たないWebサイトに強制HTTPSビットを設定すると、サポートされていないHTTPS経由で誰もがそれらに接続しようとするため、突然動作が停止します。 これは、これを当てにしないサイトに強制HTTPSを使用することでDoS攻撃を使用する可能性を心配させる1つの例です。



もう1つのことは、このプロトコルがドメイン全体での強制HTTPSの使用をサポートしていないことです。 たとえば、私はユーザーmit.eduであり、すべてのブラウザーでHTTPS Cookieを強制するように設定されており、MITではHTTPS接続のみが機能します。 これは少し壊滅的であるように思われるので、おそらく同様の状況を避けたいでしょう。



一方、HSTSプロトコルはこれに戻り、サブドメイン全体に強制HTTPSを設定できると述べました。これは、元の送信元がわからない場合、リクエストとともに送信される安全でないCookieに役立つことが判明したためです。 これらの設定には最も低いレベルの設定が多数ありますが、この場合の正しい選択が何を意味するのかはまだ明確ではありません。



興味深い質問があります。これらの改善は基本的なものですか、それとも開発者が間違いを避けるのを助けることだけを目的としているのですか 危険なアクションをとらず、証明書を時間通りに更新し、新しい証明書を作成する非常に責任ある開発者がいるとします。ForceHTTPSを使用する必要がありますか？



学生：もちろん、ハッカーを止めるものは何もないので、ハッカーはユーザーにHTTP経由で何かをダウンロードさせてから、接続をインターセプトします。



教授：本当です。 しかし、彼が非常に勤勉で、すべてのCookieが安全とマークされていると感じた場合、誰かがあなたのサイトのHTTPバージョンにアクセスしても、これは問題になりません。







ただし、おそらく、Cookieの上書きやインジェクション攻撃から防御する必要があります。 これは骨の折れる作業ですが、おそらくあなたはそれについて何かをすることができます。



学生：どんな場合でも、開発者は証明書の信頼性を確認できないと思いますよね？



教授：はい、これは私たちの最初の原則に直接関係しています：「証明書に誤りがあると致命的な結果につながります。」最も重要な点は、他のすべてから身を守ることができるということですが、開発者は、この証明機関によって署名されたサーバーにのみCookieが送信されることを確認できません。そして、ユーザーが「ああ、これで十分です！」と言う機会がある場合、開発者は、一部のユーザーが間違ったサーバーにそれらをリークしたため、自分のCookieがどこに行くのかを知る方法がありません。したがって、これは開発者にとってこのプロトコルの主な利点だと思います。



学生： , , HTTP HTTPS, , , .



: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.







– Force HTTPS ? ?



: , .



: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.



: Force HTTPS?



: , , , . , , , , , , , Force HTTPS .



, amazon.com Force HTTPS, , , , amazon.com, .







. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .



Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .



, Google , , , , , Google . , Chrome , URL- Force HTTPS.





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



ご滞在いただきありがとうございます。 ? より興味深い資料を見たいですか？ , 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サーバーを使用していますか？