web-dev-qa-db-ja.com

VPNを使用せずにTLSを介してすべてのWebトラフィックをリダイレクトする

仮定：

サーバ：

  • 静的IPv4アドレスを使用して、パブリックインターネット上でルーティング可能なDebianSqueezeサーバーがあります。
  • サーバー上のソフトウェアを変更するための無制限のアクセス権があります。
  • サーバーは任意のポートでリッスンし、ファイアウォールルールを再構成できます。基本的に、サーバーに実行させることができる内容に制限はありません。

クライアント：

  • Firefox、Javaプログラム、.NETプログラム、およびlocalシステム（ロックダウンされたWindowsデスクトップ）で管理者アクセスを必要としないいくつかのネイティブ実行可能ファイルを実行できます管理者権限なし）。
  • Firefoxにアドオンをインストールできます。
  • ループバック（localhost）インターフェイスの任意のポートでリッスンできます。したがって、前述のプログラムcanは、プロキシを経由せずに、ローカルポートにバインドし、任意のネットワークI/Oを実行します。
  • すべてパブリックインターネットアクセスは、多くのサイトをブロックし、慎重なステートフルインスペクションを行う制限付きHTTPプロキシを介してルーティングされます。ポート80では、HTTPのみを許可します（TLS/SSLは許可しません）。ポート443では、ドメイン名/ IPアドレスによってブロックされていないリモートホストへのCONNECTベースのSSL/TLSを許可します。
  • 制限付きHTTPプロキシ実行しないプロキシを介して許可されるTLS接続のディープパケットインスペクションを実行し、実行しないこれらの接続に対して中間者攻撃を実行します。
  • 私がアクセスできる上記のサーバーは、プロキシによってブロックされていますnot。

ゴール：

Firefoxから発行されたHTTPおよびHTTPSリクエストを、上記のサーバーを介してSSL/TLS経由でルーティングしたいall。

「目標」に関するその他の注意事項：

  • エンドポイントサイト（たとえば、http://superuser.com）サーバーに対してSSL/TLSを使用していませんが、SSL/TLSを使用したいクライアントからサーバーへ、暗号化されているかどうかに関係なく、サーバーにHTTPリクエストを実行させます- -希望の目的地へ。
  • I 気にしないサーバーがSSLトラフィックを「平文で」見ている場合。言い換えると、リモートサーバーが次のようにアクセスされている場合、ローカルクライアントからリモートサーバーに至るまで、完全なエンドツーエンドのSSL暗号化は必要ありません。 https://google.com。言い換えれば、私はtrustサーバーが私のデータの機密を保持します。
  • 管理者権限を必要とせず、32ビットのWindows7で実行できるソフトウェアまたはFirefoxアドオンをインストールしたいと思っています。
  • プロプライエタリよりもオープンソースソフトウェアが好まれ、ライセンス料が必要なソフトウェアよりもフリーウェアが好まれます。
  • 新しいソフトウェアをコード化するよりも既存のソフトウェアの方が好まれますが、それが唯一の方法である場合はコードを記述してもかまいません。

私は次のことを説明する大まかに説明された「解決策」を探しています。

  • クライアントにはどのようなソフトウェアが必要ですか？知っている特定のソフトウェアパッケージがある場合は、それに名前を付けます。それ以外の場合は、クライアントソフトウェアが何をしなければならないかを説明してくださいdo。
  • サーバーにはどのようなソフトウェアが必要ですか？知っている特定のソフトウェアパッケージがある場合は、それに名前を付けます。それ以外の場合は、サーバーソフトウェアが何をしなければならないかを説明してくださいdo。
  • 上記の特定のソフトウェアパッケージに名前を付けた場合は、私の目標を達成するためにセットアップするために必要な構成パラメーターを説明してください。
  • 何らかの理由でこれが不可能であると思われる場合は、理由について説明してください。

私が試したがうまくいかないこと

  • サーバーにsquidをインストールして、サーバーに独自の標準HTTPプロキシを設定しようとしました。 Firefoxで通常のHTTPを介してWebサイトを要求すると、Firefoxも通常のHTTPを介してサーバーにアクセスしようとします！ローカルネットワーク上のプロキシが可能であるため、これは受け入れられません。もちろん、クライアントとサーバー間の通常のHTTPトラフィックを監視および/またはブロックします。
  • VPNは機能しません、ポート443でリッスンしているOpenVPN over TLSもありません。これは、ローカルコンピューターにレイヤーを実行できるtunネットワークアダプターをインストールする権限がないためです。 3ルーティング、またはレイヤー2ルーティング（例：tap）を実行することもできません。つまり、OpenVPNをインストールするには管理者権限が必要であり、一時的に管理者権限を持っていたとしても、インストールされていることに気付いた場合、会社はそれほど満足しません。 Javaまたは.NETプログラムは、特にプログラムの追加と削除にインストールされておらず、OpenVPNのようなカーネルドライバーコンポーネントがない場合は、それほど目立ちません。
firefoxproxyfirewallhttps
10
allquixotic

私はそれを考え出した。 ：Dこのソリューションは、私の要件のallを満たし、私の目標のallを完全に満たしています。これを達成するために必要な間接参照のレベルを考慮すると、パフォーマンスもそれほど悪くはありません。

したがって、一般的なアプローチは次のとおりです。

  1. ローカル認証局（CA）をセットアップし、RSA「サーバーキー」と「クライアントキー」を生成します（私は256ビット暗号化を使用しました）。このために、私は Easy-RSA バージョン3.0.0-rc2を使用しました。

  2. 「DebianBox」（パブリックインターネット上のサーバー）で任意のbog標準HTTPプロキシを実行し、localhostのみでリッスンするようにします（パブリックインターネットに公開しないでください）。私の目的では Privoxy を使用しましたが、Squidも同様に機能します。ローカルホストでのみリッスンしているため、認証は必要ありません（信頼できないプロセスがボックスで実行されている場合を除きます。その場合、yikes ...）

  3. stunnel をダウンロードして、クライアントとサーバーの両方にインストールします。これを行うプロセスはOS固有になります。私の場合、Windows用のソース（パラノイア...）からstunnelをコンパイルすることを選択しました。これは、ここでは詳しく説明しませんが、かなり複雑なプロセスでした。サーバー側では、パッケージマネージャーで利用可能でした:)

  4. Stunnelの構成は最初はかなり気が遠くなるようなものでしたが、見た目よりも単純です。基本的に、サーバーには、以下の「サーバーのstunnel.conf」のようなものが必要です。クライアントでは、以下の「クライアントのstunnel.conf」のようなものが必要です。

  5. Privoxyを起動します。サーバーでstunnelを起動し、構成ファイルをポイントします。クライアントでstunnelを起動し、構成ファイルをポイントします。 Privoxyの設定について特別なことは何もありません。デフォルトは私にとっては問題ありませんでした。

  6. クライアント側で選択したブラウザであるFirefoxでは、HTTPおよびHTTPSプロキシを、クライアントのstunnelがリッスンしているポートと同じになるように設定します（おそらくlocalhost：8080など）。

ローカルネットワークのプロキシが何らかの認証を要求する場合は、stunnelを使用して認証するか、anotherローカルインターセプトプロキシを使用してそれらをチェーンする必要があることに注意してください。 Firefox-> stunnel->ローカル認証プロキシ-> LANプロキシ/ゲートウェイ->インターネット->サーバーのstunnel-> privoxy。

それはたくさんのコピーですが、うまくいきます！

;This is the *client's* stunnel.conf.
[https]
accept = localhost:9020
connect = your.lan.proxy:80
client = yes
protocol = connect
;protocolHost should be the same as the "accept" for the server
protocolHost = 1.2.3.4:443
;Same CAfile, different cert and key pair
CAfile = ca.crt
cert = client.crt
key = client.key
;VERY IMPORTANT!!! Make sure it's really your server and not a MITM attempt by your local network by making sure that the certificate authority "ca.crt" really signed the server's cert
verify = 2
;More performance tweaks...
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

。

;This is the *server's* stunnel.conf.
[https]
;1.2.3.4 is a publicly-routable, static IP address that can be connected to by your box that's under the firewall
accept = 1.2.3.4:443
;localhost:8118 is an example of where your local forwarding HTTP(S) proxy might reside.
connect = localhost:8118
CAfile = ca.crt
cert = server.crt
key = server.key
;VERY IMPORTANT!!! Without this, anyone in the world can use your public stunnel port as an open proxy!
verify = 2
;Set some timeouts higher for performance reasons
sessionCacheTimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

すべてが構成されると、最終結果は次のようになります。

  1. Webブラウザはlocalhost:9020（stunnel）に接続し、HTTPおよび/またはHTTPS接続を受け入れることができるプロキシのように扱います。
  2. Stunnelがブラウザから接続を取得すると、ファイアウォールのプロキシ/ゲートウェイを介して、リモートサーバーとのTLSセッションを確立します。 この時点で、クライアントはサーバーのPKI証明書を検証し、その逆も同様です。
  3. リモートサーバーとのTLSセッションが確立されると、stunnelはブラウザからのデータを渡します。ローカルプロキシを介してサーバーに直接送信されるHTTPリクエストまたはSSLトンネルリクエスト。このチャネルは暗号化されているため、ローカルネットワークはデータに何が含まれているかを知ることができず、トラフィック分析を行うことによってのみ推測できます。
  4. 実行中のstunnelインスタンスサーバー上がデータの受信を開始すると、たとえば、 localhost:8118。これは、HTTP（S）プロキシサーバー（私の場合はPrivoxy）がリッスンしている場所です。
  5. Privoxyは、通常の転送HTTPプロキシサーバーのように機能し、サーバーのISPを介してパブリックインターネットにリクエストを転送します。

関係するソケットとバッファの量により、このメソッドのオーバーヘッドは非常に高くなります。特に、プロキシを介してSSL接続をネストしている場合は、しかしには利点がありますローカルネットワークには、SSL経由でアクセスしていることを知る方法がないことどのサイト。つまり、サーバーにアクセスしていることはわかっていますが、それ以外は、GmailやSuperUserなどにアクセスしているかどうかはわかりません。また、ローカルゲートウェイには、フィルタリングやブロックを行う方法がありません。

5
allquixotic

ローカルマシンでこの設定を試しましたが、「制限プロキシ」がCONNECT DEBIAN_IP:443 HTTP/1.1を取得することは保証できますが、証明書が表示されないため、これが機能するかどうかはわかりません。

仮定しましょう：あなたのDebianにはプロキシを行うためのApacheまたはSquidがありますそして SSHサーバー。クライアントPCには、PuTTYが必要です。これは、実行に管理者権限を必要とせず、インストールも不要で、ペンドライブから実行できるプログラムです。

まずあなたのDebian：

SSHをポート443でリッスンさせ、Port 443に/etc/ssh/sshd_configを追加（または現在のポートを置き換える）し、TCP転送（add AllowTcpForwarding yesそのファイル）

プロキシを実行するようにSquidまたはApacheを構成します。これはSSHトンネルを介して使用されるため、ループバックインターフェイスでリッスンするだけで済みます。 Apacheを使用する場合：

Listen 127.0.0.1:8080
ProxyRequests On
<Proxy *>
  Order deny,allow
</Proxy>

サーバーが完了しました。クライアントPCを構成しましょう。

PuTTYで、DebianのパブリックIPをHostとして、443をポートとして構成します。 SSHがまだ選択されていることを確認してください。 Connection -> Proxy設定に変更し、HTTPを選択して、「制限付きプロキシ」設定を入力します。 Connection設定に変更し、30-60のキープアライブを確立します。 Connection -> SSH -> Tunnelsに変更します。 source port stablish 8080、およびDestination、localhost:8080。 Localを選択したままにして、Addを押します。 L8080 locahost:8080のようなものの上のスペースに表示されます。 Session設定に戻り、Saved sessionsの最初の行に名前を書き留めますこれらの面倒な設定をすべて保存します次の日に接続を再確立できるようにします。

これで、Debianへの接続をOpenすることができます。ユーザープロンプトが表示された場合は、これを終了するための一歩です。そうでない場合は...別の方法を探す必要があります。

ここで、Firefoxで、ポート8080のlocalhostをプロキシとして設定します。

2
NuTTyX

サーバーにプロキシを設定する途中です。残りの半分はサーバー上のSSLであり、PuTTYを使用してSSL対応のHTTPプロキシに接続し、Firefoxを設定してすべてを127.0.0.1にプロキシするクライアント上のローカルプロキシです。

私はPuTTYセットアップのために簡単なグーグルをしたところ、これを見つけました： https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-Apache-170/

1
joe