web-dev-qa-db-ja.com

透過的なSquid転送プロキシをSSLで動作させる際の問題

4台のサーバーがネットワークで接続された環境があります。 1台のサーバーはサーバーとして機能し、他の3台はPhoromaticを使用して自動テストとLinuxベンチマークを実行するためのクライアントとして機能します。

4つのシステムはすべて企業ファイアウォールの背後にあります。クライアントに「http_proxy」と「https_proxy」の環境変数を設定すると、外部に接続してテストなどをダウンロードできますが、プロキシを使用してローカルサーバーに接続しようとするため、サーバーに接続できません。 。パッケージのダウンロードやテストなどをキャッシュしたかったので...サーバーシステムにSquidプロキシを設定し、透過プロキシとして構成しましたが、httpリクエストでのみ機能します。

私がやりたいのは、httpリクエストをキャッシュ経由で処理し、必要に応じて親プロキシに転送することです。明らかに、SSLセッションを復号化することはできませんが、Squidプロキシにhttps要求を親プロキシに転送させる方法を理解することはできません。さらに、squidプロキシはPhoromaticサーバーと同じボックスで実行されています。PhoromaticサーバーはWebベースですが、ユーザーが構成可能な非標準ポートを使用しますが、Squidは、許可されているとして構成に追加されている場合でも、そのポートへの要求をブロックすることを好みます。

クライアントにhttpsおよびftpリクエストに直接企業ファイアウォールを使用させ、httpリクエストにSquidキャッシュを使用するか、Squidプロキシを完全に破棄して、クライアントがローカルホストにプロキシを使用しないように設定するだけで問題ありません。

ほとんどの場合、情報を探し出し、他の人の頭脳を選ばずに自分で物事を機能させるのが得意なので、それは本当にイライラしますが、私はかなり独特の状況にあると思います！そして、はい、私はPhoromaticのPhoronixフォーラムを試しましたが役に立ちませんでした。

サーバーは、Fedora24を実行するSuperMicroX8DTTデュアルシャーシシステムです。ネットワーク構成は、スイッチへのGbE接続（外界への接続として使用）と、各システムの2つの10Gbで構成され、スイッチを介して接続されますが、10Gbシステム外の世界に接続されていません-帯域幅のテストに使用されます（10Gbカードのドライバーはシステムがテストするように設定されているものです）

linuxlinux-networkingsquidautomated-testing
2
Andrew Bowers

私は短くなります（ええ、それはまったく短く見えませんが、そうでなければそれははるかに長く、完全に読めないでしょう）。

  • プロキシが必要なようには見えません。完全に好きです。
  • 現代の環境では、キャッシュ比率は0から40％の間である可能性があります（そして私はプロキシのバイト比率に基づいて判断しています）ので、その量のデータを保存したい場合、もちろん、プロキシを使用できます。しかし、これを考慮してください。今日のエンタープライズ環境では、プロキシの役割は、データをキャッシュすることよりも、WANアクセスに向かう途中のユーザーを承認することです。これが、選択を疑う主な理由です。
  • それでもプロキシが必要な場合は、HTTPSを復号化する必要があるという意味ではありません。ただそれを生きさせてください。キャッシュされないので、どうしますか。それはそのデザインにあります。
  • それでもHTTPSの復号化を主張している場合は、 sslBumpテクニック を使用できます。しかし、これは一部の国では違法である可能性があり、さらにこれは事態を非常に複雑にします。 LikeA LOT。キャッシュの目的でのみこの方法を使用しないことをお勧めします。
  • プロキシ経由でローカルトラフィックを処理しないでください。遅延が追加され、プロキシが読み込まれ、不要なトラフィックが発生します（安価で、LANチャネルがWANよりもはるかに広いため）、デバッグが複雑になり、寄生虫ネットワークの依存関係が追加されるため、賢明ではありません。
  • プロキシが必要だとは思えないので、親プロキシが必要だとは思えません。あなたはただこのことをしているように見えます....あなたが知っている、プロキシに入っています。必要に応じて使用してください。
  • プロキシの代わりに、高速で適切なWebサーバーであるlinenginxが必要な場合があります。したがって、Webサーバーが過負荷になる状況では、l2キャッシュを備えたファームのバランサーとして機能する可能性があります。
  • squidはそれほどうまくスケーリングしていません。 10ギガの帯域幅の場合、SMP squid機能を使用する必要がありますが、これには欠点があります。イカの労働者への不均衡な負荷のように、イカの内部でのSMPの問題など。 squidの使用経験がある場合は解決できる可能性がありますが、初めてのように設定した場合は解決できない可能性があります。
  • 最後に、squidを使い続けることにした場合は、透過的である必要はありません。クライアント用にWPADを構成し、サーバーにインターネットへのアクセス方法を決定させることができます。
2
drookie

サーバーシステムにSquidプロキシを設定し、透過プロキシとして構成しましたが、httpリクエストでのみ機能します。

これは、HTTPとHTTPSの動作が異なり、プロキシで同じように処理できないためです。 HTTPS要求がプロキシポートに透過的にリダイレクトされると、プロキシは暗号化されたトラフィックを調べることができないため、それを処理できません。 transparentプロキシは、実際には「中間者」のように機能し、ユーザーが知らないうちにhttpトラフィックをインターセプトします。これは不足しているために可能です。 httpプロトコルのセキュリティの。

https://en.wikipedia.org/wiki/HTTPS

HTTPS（HTTP over TLS、[1] [2] HTTP over SSL、[3]およびHTTP Secure [4] [5]とも呼ばれます）は、インターネットで広く使用されているコンピューターネットワークを介した安全な通信のためのプロトコルです。 HTTPSは、トランスポート層セキュリティまたはその前身であるSecure Sockets Layerによって暗号化された接続内のハイパーテキスト転送プロトコル（HTTP）を介した通信で構成されます。 HTTPSの主な動機は、アクセスしたWebサイトの認証と、交換されたデータのプライバシーと整合性の保護です。

インターネット上での一般的な展開では、HTTPSは、通信しているWebサイトおよび関連するWebサーバーの認証を提供し、man-in-the-middle攻撃から保護します。さらに、クライアントとサーバー間の通信の双方向暗号化を提供し、通信の内容の盗聴や改ざん、および/または偽造から保護します。[6]実際には、これにより、（なりすましではなく）通信することを意図したWebサイトと正確に通信していることを合理的に保証し、ユーザーとサイト間の通信内容を閲覧したり偽造したりできないようにします。第三者。

ご覧のとおり、HTTPSは中間者攻撃から保護し、許可しないことになっています。次のSquidページでは、すべての質問と混乱について詳しく説明しています。

http://wiki.squid-cache.org/Features/HTTPS

ブラウザがhttps：// URLに遭遇すると、次の2つのいずれかを実行します。

  • originサーバーへのSSL/TLS接続を直接開くか

  • cONNECT要求メソッドを使用して、Squidを介してOriginサーバーへのTCPトンネルを開きます。

これら2つのトラフィックタイプとのイカの相互作用については、以下で説明します。

CONNECTトンネル

CONNECTメソッドは、HTTPプロキシを介してあらゆる種類の接続をトンネリングする方法です。デフォルトでは、プロキシは指定されたサーバーへのTCP接続を確立し、HTTP 200（接続確立）応答で応答し、理解せずにクライアントとサーバー間でパケットをやり取りします。トンネリングとCONNECTメソッドの詳細については、RFC2817およびWebプロキシサーバードラフトを介した期限切れのトンネリングTCPベースのプロトコルを参照してください。

イカを介してトンネルを接続する

ブラウザがSquidを介してCONNECTトンネルを確立すると、アクセス制御はCONNECT要求を制御できますが、利用できる情報は限られています。たとえば、リクエストURLの多くの一般的な部分は、CONNECTリクエストには存在しません。

  • uRLスキームまたはプロトコル（例：http：//、https：//、ftp：//、voip：//、iTunes：//、またはtelnet：//）、

  • uRLパス（例：/index.htmlまたは/ secure/images /）、

  • およびクエリ文字列（例：？a = b＆c = d）

HTTPSを使用すると、上記の部分はトンネルを通過するカプセル化されたHTTPリクエストに存在しますが、Squidはこれらの暗号化されたメッセージにアクセスできません。他のトンネリングされたプロトコルは、HTTPメッセージとURL（telnetなど）を使用しない場合もあります。

ブラウザがプロキシを手動で使用するように構成されている場合、ブラウザは上記のCONNECTメソッドを使用して機能します。そうは言っても、httpsトラフィック（ssl-bump）をインターセプトするように透過プロキシを構成する方法があります。これはリーガルではなく、推奨されないため、注意して使用する必要があります。

バンピングCONNECTトンネル

{X}警告：{X} HTTPSは、ユーザーにプライバシーとセキュリティへの期待を与えるように設計されています。ユーザーの同意や知識なしにHTTPSトンネルを復号化すると、倫理基準に違反する可能性があり、管轄区域では違法になる可能性があります。ここや他の場所で説明されているイカの復号化機能は、ユーザーの同意を得て、または少なくとも同意なしの復号化が合法である環境で展開するように設計されています。これらの機能は、ユーザーがHTTPS接続の信頼に注意する必要がある理由と、HTTPS保護のチェーンの中で最も弱いリンクがかなり脆弱である理由も示しています。 HTTPSトンネルの復号化は、ネットワークセキュリティ全体の観点から中間者攻撃を構成します。攻撃ツールは、現実の世界では原子爆弾に相当します。自分が何をしているかを理解し、意思決定者が賢明な選択を行うのに十分な情報を持っていることを確認してください。

Squid SslBumpおよび関連機能を使用して、HTTPSCONNECTトンネルがSquidプロキシを通過するときにそれらを復号化できます。これにより、トンネル化されたHTTPメッセージを通常のHTTPメッセージであるかのように処理できます。これには、詳細なアクセス制御の適用やコンテンツの適応の実行が含まれます（たとえば、情報漏えいのリクエスト本文の確認やウイルスの応答の確認）。構成の誤り、Squidのバグ、および悪意のある攻撃により、暗号化されていないメッセージがSquidの境界から逃れる可能性があります。

ブラウザの観点からは、カプセル化されたメッセージはプロキシに送信されません。したがって、個々の埋め込みリクエストを認証できないなど、一般的な傍受の制限がここでも適用されます。

1
Diamond