HTTPSはプライベートですか?

最近、私が読んだブログの 1つで、興味深い声明を見つけました(私の無料翻訳):

オフィスでオンラインバンキングを使用しているとき、エンドツーエンドの安全な接続があると思いますか? もう一度考えてください。


十分に興味を持ち、少し掘り下げます。 「そして、あなたはどう思いますか? (c)「完全に安全な」HTTPS接続には、少なくとも2つの仲介者(Man In The Middle)を埋め込むことができます。 確かに、両方とも信頼されている必要があります(TMITM)ので、非常にパニックする必要はありません。 これまで。





オプション1:企業/キャリアファイアウォールまたはプロキシ



企業ネットワークでは、ユーザーは通常、プロキシを介してインターネットにアクセスします。プロキシは、明示的または暗黙的に設定できます(透明または高度なファイアウォールのみ)。 これは、トラフィックに対する少なくとも最小限の企業制御(不要なサイト/スクリプト/広告のフィルタリング、ウイルス対策チェック、キャッシュなど)を維持するために必要であり、原則として論理的です。

これが暗号化されていないHTTPでどのように機能するかは明確ですが、HTTPSではすべてが明確ではありません。 結局のところ、HTTPSはセッションへの「クラッシュ」やトラフィックの傍受を防ぐように設計されているだけです。データは暗号化され、サーバーの信頼性は証明書によって検証されます。 したがって、少なくとも2つの質問が発生します。

  1. なぜプロキシ証明書を信頼する必要があるのですか?
  2. プロキシ証明書を信頼していても、銀行の名前ではなく、プロキシの名前で発行されます-どうすれば機能しますか?
それができることがわかりました。



会社に独自の証明書インフラストラクチャがあり、独自のCAがある場合、最初の質問はまったく発生しません。 この場合、このCAの証明書は作業中の各マシンに信頼できるものとしてインストールされ、同じ証明書(プロキシ)によって署名されるすべてのものも信頼されます。 このため、このような「信頼できる」実装がこのシナリオで可能になります。



しかし、証明書内の間違った名前をどうすればよいでしょうか? この問題をうまく解決するMITMproxyやHoneyProxyのようなプログラムのクラスがあります(かなり前のことです)。 それらの主な機能は、Apple GameCenterで読み取り、その場で証明書生成することです! プロキシは(エンタープライズルートCAによって署名された)中間CAとしてインストールされ、任意の名前の証明書を(それ自体に対して)動的に生成します。 したがって、クライアントは銀行と通信していると考えていますが、実際には、HTTPSセッションはプロキシで終了しています。

詳細はこちら



画像



したがって、最初の声明は真実であることが判明し、稼働中のHTTPS接続は、IT部門を信頼できる範囲でしか信頼できません。 または、OSに依存しない独自の証明書ストアと証明書のピン留めサポートを備えたFirefoxなどのブラウザーを使用します(最近ではブラウザーで一般的になっています)。 まあ、または、もちろん、仕事以外の目的のために仕事用のネットワークで仕事用のマシンを使用するのではなく、誰がこの愚かなルールに従うのでしょうか? VPNは、SSLに基づいていない場合にも役立ちます。



UPD:コメントの中で、彼らは、オペレータファームウェアで「オペレータから」スマートフォンを使用すると同じことが起こり得るという考えを思い付きました。



オプション2:CloudFlareキーレスクラウドプロキシ



まあ、最初のケースでは、私のオフィスにあり、私の代わりに接続を開始するプロキシがあります。 まあ。 いずれにせよ、接続するターゲットサーバーは本物でなければなりません。そうでない場合、プロキシはパニックを起こし、HTTPSセッションをその前に構築しません(管理者が設定を台無しにしない限り)。 CloudFlareのKeyless SSLの最近の発表を踏まえると、これも事実ではないようです。



画像



技術的な詳細はこちらをご覧ください 。 このシナリオでは、ターゲットサーバー(同じオンラインバンキング)が既に存在していることが重要です。銀行はまだ属していません。 良いニュースは、それが銀行が信頼する誰かに属するということです。



CloudFlareの仲間は、証明書を偽造したり、顧客の鍵で署名したりすることなく、顧客のHTTPSサーバーとして自分自身を紹介する方法を開発しました。 実際、銀行サーバーで認証チェックのみが実行されますが、合格するとすぐに、信頼できるCloudFlareサーバーとのセッションが確立されます。 高貴な目標は、クライアントのHTTPSトラフィックをオフロードし、DDoS攻撃から保護することです。 証明書とキーを取得せずにターゲットサーバーを偽装する方法を発明するのにどれくらい時間がかかりますか(または、さまざまな国の「権限」がバックドアアクセスを必要とするか)。 うまくいけば十分です。



合計



一見「安全な」HTTPS接続では、少なくとも2つの仲介者が落ち着くことができます。 両方を信頼する必要がありますが、管理者はそれら、上司、銀行、店舗を信頼します。あなただけではありません。 インターネットのプライバシーがまだ100%であると思われる場合は、 もう一度考えてください



HTTPSに対する他の攻撃方法を知っていますか?



PSオリジナルはこちらです。



All Articles