Robert Heaton

by admin Leave Comment

HTTPS は、単に標準の HTTP プロトコルにおいしい SSL/TLS 暗号化の層をたっぷりとかぶせただけのものです。 何かひどいことにならない限り（そしてなりうることですが）、悪名高いイブのような人々が、あなたのブラウジング体験を構成するリクエストを見たり変更したりするのを防ぎます。これは、あなたのコンピュータとあなたがデータを送りたいサーバとの間のワイヤ上でパスワード、通信、クレジットカードの詳細を安全に保つためのものです。 アドレスバーに小さな緑の南京錠と「https」の文字が表示されていても、あなたと閲覧中の Web サイトの両方が別の場所にぶら下がるための十分なロープがないわけではありませんが、少なくとも、そうしている間に安全に通信できるようにするものなのです。 サーバとクライアントは互いにまったく同じ HTTP を話しますが、リクエストとレスポンスを暗号化および復号化する安全な SSL 接続を経由します。 SSL層は主に2つの目的を持っています。

  • 自分が話していると思っているサーバーと直接話していることを確認する
  • サーバーだけが自分が送ったものを読むことができ、自分が返したものを読むこともできる

本当に、本当に賢い部分は、誰でもサーバーとやりとりするすべてのメッセージを傍受できることで、使うキーや暗号化戦略について同意するものも含みますが、自分が送る実際のデータを読むことはできない、ということです。

SSL接続の確立方法

クライアントとサーバ間のSSL接続はハンドシェイクによって確立されるが、その目的は以下のとおりである。

  • クライアントが正しいサーバと通信していると確信すること (そしてオプションでその逆も)
  • 当事者が “cipher suite” に合意すること。
  • データ交換に使用する暗号化アルゴリズムを含む

接続が確立すると、両当事者は合意したアルゴリズムとキーを使用して、互いにメッセージを安全に送信することができます。

  1. Hello – ハンドシェイクは、クライアントがClientHelloメッセージを送信することから始まります。 これにはサーバが SSL 経由でクライアントに接続するために必要な全ての情報が含まれており、様々な暗号スイートやサポートする最大 SSL バージョンが含まれています。 サーバはServerHelloで応答し、これにはどの暗号スイートとSSLバージョンを使用するかというクライアントの設定に基づいた決定を含む、クライアントが必要とする同様の情報が含まれています。

  2. 証明書の交換 – これでコンタクトが確立したので、サーバはクライアントに自分の身元を証明しなければなりません。 これは、パスポートのようなものであるSSL証明書を使うことで実現されます。 SSL証明書には所有者の名前、ドメイン名、証明書の公開鍵、電子署名、証明書の有効期限など様々なデータが含まれています。 クライアントは、その証明書を暗黙のうちに信頼しているか、あるいは、暗黙のうちに信頼しているいくつかの認証局（CA）のうちの一つによって検証され信頼されているかをチェックします。 これについては、後ほど詳しく説明します。

  3. Key Exchange – クライアントとサーバによって交換される実際のメッセージデータの暗号化は、対称的なアルゴリズムを用いて行われます（その正確な性質はHelloフェーズで既に合意されています）。 対称型アルゴリズムは、公開鍵/秘密鍵のペアを必要とする非対称型アルゴリズムとは対照的に、暗号化と復号化の両方に単一の鍵を使用します。 両当事者はこの単一の対称鍵に合意する必要があり、このプロセスは非対称暗号とサーバの公開鍵/秘密鍵を使用して安全に達成されます。 Helloフェーズで合意されたアルゴリズムとサーバの公開鍵(SSL証明書に記載)を用いて暗号化する。 この暗号化された鍵をサーバに送信し、サーバの秘密鍵を用いて復号化されると、ハンドシェイクの興味深い部分が完了します。 そして、お互いにこれから送るデータを対称的に暗号化する鍵について、密かに合意したのです。 HTTP のリクエストとレスポンスは、平文のメッセージを形成し、それを暗号化して送信することで送信できるようになりました。 このメッセージを解読する方法を知っているのは相手だけなので、Man In The Middle Attackers は傍受したリクエストを読んだり変更したりすることができません。

    Certificates

    最も基本的なレベルで、 SSL 証明書は単にテキストファイルであり、テキスト エディタがあれば誰でも作ることができます。 実際、あなたが Google Inc. であり、gmail.com というドメインを管理していると主張する証明書を簡単に作成することができます。 もしこれがすべてなら、SSLは冗談のようなものです。ID認証は本質的に、クライアントがサーバーに「あなたはGoogleですか」と尋ね、サーバーが「ええ、まったくです。ここに『I am Google』と書かれた紙があります」と答え、クライアントが「OK素晴らしい、これが私のすべてのデータです」と言うものでしょう。 この茶番劇を防ぐ魔法は、デジタル署名にあり、当事者が他の当事者の紙切れが本当に合法であることを確認することができるのです。

    • 暗黙のうちに信頼する証明書のリストにある場合
    • 上記のリストにある証明書のコントローラによって信頼されていることを証明できる場合

    最初の基準は簡単にチェックできます。 あなたのブラウザには、認証局（CA）の信頼できるSSL証明書のリストがあらかじめインストールされており、それを見たり、追加したり、削除したりすることができます。 これらの証明書は、Symantec、Comodo、GoDaddy などの、（理論的にも、一般的にも）非常に安全で信頼できる、信用できる組織の中央グループによって管理されています。 サーバーがこのリストの証明書を提示すれば、信頼できることがわかります。

    2 番目の基準ははるかに困難です。 サーバーが「ああ、私の名前はマイクロソフトで、あなたはシマンテックを信頼しているし、彼らも私を完全に信頼しているから、すべて問題ない」と言うのは簡単です。 ちょっと賢いクライアントなら、シマンテックに「マイクロソフトがここにいて、あなたは彼らを信頼していると言っていますが、本当ですか」と聞いてくるかもしれません。 しかし、シマンテックが「そうだ、我々は彼らを知っている、マイクロソフトは合法だ」と言ったとしても、マイクロソフトと名乗るサーバーが実際にマイクロソフトなのか、もっと悪いものなのか、まだわからないのです。

    3.2 デジタル署名

    すでに述べたように、SSL証明書には関連する公開鍵/秘密鍵のペアがあります。 公開鍵は証明書の一部として配布され、秘密鍵は信じられないほど安全に保管されます。 この非対称鍵のペアは SSL のハンドシェイクで使われ、両者が対称的にデータを暗号化・復号化するためのさらなる鍵を交換するために使われます。 クライアントはサーバーの公開鍵を使って対称鍵を暗号化してサーバーに安全に送信し、サーバーはその秘密鍵を使って復号化します。 誰でも公開鍵を使って暗号化できますが、秘密鍵を使って復号化できるのはサーバーだけです。

    デジタル署名の場合は、その逆が当てはまります。 証明書は他の機関によって「署名」されることがあり、それによってその機関は「この証明書の管理者も証明書に記載されているプロパティ（ドメイン）を管理していることを確認した」と事実上記録することになります。 この場合、当局はその秘密鍵を用いて証明書の内容を（広義には）暗号化し、この暗号文を電子署名として証明書に添付する。 この署名は、誰でも権威者の公開鍵を用いて復号化し、期待通りの復号化された値になることを確認することができます。

    ですから、Symantec（または他の CA）によって署名された Microsoft.com の証明書を持っていると主張するサーバーが現れた場合、ブラウザはその言葉を鵜呑みにする必要はないのです。 もしそれが正当なものであれば、シマンテックはその（超秘密の）秘密鍵を使ってサーバのSSL証明書のデジタル署名を生成しているので、あなたのブラウザはその（超公開の）公開鍵を使ってこの署名が有効かどうかをチェックすることができるのです。 Symantecは、署名している組織が本当にMicrosoft.comを所有していることを確認する手順を踏んでおり、クライアントがSymantecを信頼していることから、本当にMicrosoft Inc.と話していると確信できます。

    3.3 自己署名

    すべてのルートCA証明書は「自己署名」されており、電子署名は証明書の自身の秘密鍵を使用して生成されているということに注意してください。 ルート CA の証明書について本質的に特別なことは何もありません。必要であれば、あなた自身の自己署名証明書を生成し、他の証明書に署名するためにこれを使用することができます。 しかし、あなたのランダムな証明書は、どこのブラウザにもCAとしてあらかじめロードされていないので、どのブラウザもあなた自身の証明書や他の証明書に署名するあなたを信用しないでしょう。 あなたは事実上、「ああ、私は完全にマイクロソフトだ、これが私が発行し署名した公式の ID 証明書だ」と言っているようなもので、すべての適切に機能するブラウザは、あなたのいかがわしい認証情報に反応して、非常に恐ろしいエラーメッセージを表示します。

    3.4 何を信用しているのか

    クライアントは技術的に、証明書を送った当事者を信用すべきかどうかではなく、証明書に含まれる公開鍵を信用すべきかどうかを確認しようとしていることに注目するのは興味深いことです。 SSL証明書は完全にオープンで公開されているので、攻撃者は誰でもマイクロソフトの証明書を手に入れ、クライアントのMicrosoft.comへのリクエストを傍受して、正当な証明書を提示することができます。 クライアントはこれを受け入れ、喜んでハンドシェイクを開始するでしょう。 しかし、クライアントが実際のデータ暗号化に使われる鍵を暗号化するとき、この本物の証明書にある本物のマイクロソフトの公開鍵を使って暗号化することになるのです。 攻撃者はそれを解読するためのマイクロソフトの秘密鍵を持っていないので、彼らは今困っています。 たとえハンドシェイクが完了しても、彼らは鍵を復号化することができないので、クライアントが送信したデータも復号化することができない。 攻撃者が信頼できる証明書の秘密鍵をコントロールしない限り、秩序は保たれる。

    4.1 喫茶店はネットワーク上の私の HTTPS トラフィックを監視できますか？ 公開鍵暗号の魔法は、攻撃者がクライアントとサーバー間で交換されるデータのすべてのシングルバイトを見ることができることを意味し、あなたが交換するデータのおおよその量を超えて、お互いに何を言っているのか分からないままです。 しかし、通常の HTTP トラフィックは、安全でない Wi-fi ネットワークではまだ非常に脆弱であり、薄っぺらなウェブサイトは、プレーン HTTP の上に HTTPS トラフィックを送信するか、完全に間違った場所に送信するように仕向ける、いくつもの回避策の犠牲となる可能性があ ります。 たとえば、ログイン フォームが HTTPS でユーザー名とパスワードのコンボを送信したとしても、フォーム自体が HTTP で安全にロードされていなければ、攻撃者はマシンに届く途中でフォームの HTML を傍受し、ログイン情報を自分のエンドポイントに送信するように修正することができます。 すべての信頼の連鎖のルートには、暗黙的に信頼された CA があり、これらの認証局のリストがブラウザに保存されていることを思い出してください。 あなたの会社は、あなたのマシンにアクセスすることで、このCAのリストに彼ら自身の署名入り証明書を追加することができます。 そして、あなたの HTTPS リクエストをすべて傍受し、適切なウェブサイトを代表していると主張する証明書を、偽の CA によって 署名され、したがってブラウザから疑いもなく信頼されているものとして提示することができる。 HTTPS リクエストはすべてその偽の証明書の公開鍵で暗号化されているので、対応する秘密鍵を使っ てリクエストを解読し、検査（修正も）して、目的の場所に送信することができる。 彼らはおそらくそうしない。 しかし、可能性はあります。

    ちなみに、これは、iPhoneアプリによって行われるアクセス不能なHTTPSリクエストを検査および変更するために、プロキシを使用する方法でもあります。 私たちが見てきたように、どんなに標準的なハッキングでも、FBIがLavabitとその顧客との間のデータを見ることはできませんでした。 LavabitのSSL証明書の秘密鍵がなければ、FBIはお手上げだったのです。 しかし、米国の判事がラバビットの創業者であるラダー・レヴィソンに、この鍵を渡すように告げたため、FBIは思う存分トラフィックを覗き見することができるようになった。 Levisonは、4ポイント活字の11ページのハードコピーで2,560文字のキーを渡して引き延ばそうと果敢に試みましたが、キーを有用なフォーマットで渡すか、渡すまで1日5千ドルの罰金を課すという命令で、打ちのめされました。 これは、クライアントが安全な接続を提供するためにもはや信用できない証明書のリストである、証明書取り消しリスト (CRL) に Lavabit 証明書を追加するものです。 危殆化した証明書、自己署名された証明書、またはその他の信頼できない証明書は、ブラウザに大きな赤いエラーメッセージを表示し、ユーザーによるそれ以上の行動を阻止するか、完全に禁止するようにします。 残念ながら、ブラウザは CRL の最新の更新を取得するまで壊れた証明書を信用し続けますが、このプロセスは実際には明らかに不完全です。

    結論

    HTTPS は破られないわけではなく、それに対する新しい攻撃が発見されてつぶされるのに応じて SSL プロトコルは常に進化し続けなければなりません。 しかし、誰にメッセージを見られるかを気にすることなく、秘密のデータを送信する方法としては、驚くほど堅牢なものです。 もちろん、ハンドシェイクメッセージの正確な形式や順序、鍵や暗号スイートを再交渉することなく最近のセッションをピックアップするための省略されたハンドシェイク、各段階で利用できる多くの異なる暗号化オプションなど、ここでは触れていない多くの実装の詳細が存在します。 覚えておくべき重要なことは、HTTPS は目的地までのデータの安全を確保する一方で、XSS やデータベース・リーク、その他夜中に発生する様々な事象からユーザや開発者を守ることはできないということです。 しかし、警戒は怠らないでください。 ウィル・スミスの不滅の言葉を借りれば、「影で歩き、静かに動き、地球外の暴力から守れ」

    これを楽しんでいただけたなら、おそらく、2015 年の SSL における FREAK 脆弱性の詳細を説明した私の投稿も楽しんでいただけると思います。

コメントを残す

メールアドレスが公開されることはありません。