HTTPSトラフィックのオープンソースフィルタリング
以前は、SquidGuardでSQUIDを実行しているUnixベースのシステムを介して約500人のユーザーがルーティングされ、疑わしいコンテンツをブロックし、ユーザーの行動をログに記録するように構成されたフィルタリング/プロキシ設定がありました。私たちが発見したのは、HTTPSプロトコルを使用する無料のオンラインプロキシにアクセスすることでブロックを回避できる人がいるということです。 HTTPSトラフィックを完全に無効にせずにブロックする方法を見つけることができませんでした。これは、購入とHR（または銀行サイトを使用する通常のユーザー）では機能しませんでした。
SQUID/SquidguardでHTTPSトラフィックをブロックまたはフィルタリングする方法はありますか？または他のオープンソース監視プログラム？他の人は、商業用の電化製品に頼らずにそれをどのように扱いますか？
編集：私たちはthe trafficを見ようとはしていません。 rlsを監視し、必要に応じてブロックしようとしています。クレジットカード番号などは必要ありません... Johnnyがいつアクセスしたかを知りたい https://schoolssucksoweproxyforyou.com/playboy.com 、ドメインをブロックファイルに追加して、それらを防止しますもう一度やってから。以下のいくつかの追加コメントを参照してください...
EDIT2：（Re：人事、銀行などと言えば）そうは思わないかもしれませんが、私たちには購入を行う人がいます。私たちの地区は郡に点在する7つの建物をカバーしているため、担当者がいます資料や在庫の配布、記録の確認や銀行業務を担当する人、スタッフの組合担当者、教職員の担当者、保険や傷害の請求や責任などの人事情報の処理を担当する人がいます。学校の運営には、一般の人が考えたことのないことがたくさんあります。さらに、スタッフや教職員がオンラインバンキングを実行できないようにしたり、学生でさえSSL接続が必要な場合があるオンライン使用のために特定のサイト（Webクエストなど）にアクセスできないようにするのが難しいと考えられていたため、HTTPSを禁止するという問題があります。ルーターで完全に実現可能ではありません。
とにかく、特定のユーザーのみをブロックすることについての提案に移りますが、ユーザーごとに認証の機能を統合する方法は見当たりませんでした。資格情報をWindowsから渡すことができ、ユーザーがさらに別のパスワードで認証を続ける必要がない場合、それは実行可能な解決策になりますが、私が見つけたものはすべて扱いにくく、確実に機能しませんでした。次に、人々にさらに別のパスワード（または学生/スタッフがパスワードを盗む/共有するパスワード）を覚えさせる問題です。私は個人的に、生徒が同じことをするのに十分な人とは見なされていないのに、教師がXを実行できるという問題にするのではなく、スタッフと生徒のために全体的に公平にフィルタリングを行うのが好きでした。
結局、サーバーがActive Directoryに対して確実に認証されるようにする方法を見つけることができませんでした（ユーザー管理を一元化し、覚えておくパスワードを減らすため）、または別の認証スキームを使用した場合、別のデータベースの同期を維持することを意味しますなんと...、最後のカウント、約1200ユーザーか毎年、学区の内外で子供たちが卒業し、新しい子供たちがやってくるので、解約率が高くなっていますか？...
私はここで倫理に入るつもりはありません-多分あなたはあなたがドメインを「知らない」すべてのサイトでこれをしたいでしょう...とにかく、倫理的な問題はさておき：
is可能です。間違いなくsquid2のビットを追加する必要がありますが、AFAIKsquid3はこれをそのまま実行します。一部の商用Webフィルターベンダーもそうです。通常、MITMスタイルの攻撃が唯一の方法です。
HTTPSトラフィックの全体的なポイントは、サーバーとエンドユーザーの間で暗号化されているため、フィルターを含め、他の誰もそれをスヌープできないことです。コンテンツフィルタリングを行うことはできません。実行できる唯一のHTTPSフィルタリングは、特定のIPアドレスへのSSLポートをブロックすることです。
ホワイトリストに登録すると、誤検知がたくさん発生します-思いもよらなかった銀行、ログインやアクセスにHTTPSが必要な便利なサイトなど。ブラックリストに登録すると、誤検知が大量に発生します-新しいプロキシサイトが出現します毎秒アップ。
これは、技術レベルではなく、ポリシーレベルで対処する必要があるものです。誰かが職場のポルノサイトでふざけて、プロキシを使用してフィルターを回避する場合、人事部は手にそれらを叩き、それが続く場合は終了を脅かす必要があります。
以下は、商用ベンダーによって実装された非常に醜いソリューションです。
ブラウザのCA証明書を独自の社内証明書に置き換えます
不明なアドレスへの接続が要求されると、プロキシは自身のクライアントに接続し、サイトの証明書を取得します
次に、独自のCAによって署名された、そのサイトの偽の証明書を生成します
その後、プロキシは効果的にMITM（man-in-the-middle）として機能します
ストックSquidでそれを行うことはできませんが、Apacheでそれを実装するにはmod_Perlハッキングに約1日かかります。
IRCサーバーが時々行うことを実行することで、どのような解決策が考えられますか。XXX.XXX.XXX.XXXからの接続を確認すると、そのIPに接続して、オープンプロキシサーバーかどうかを確認します。もしそうなら、彼らはそのIPをブロックします。
それは私が考えることができる最も近いものであり、完全に自動化された解決策ですが、あなたの側での作業が必要になります。ホワイトリストに関する他の提案と組み合わせるか、手動でログを見てhttpsのリモートIPを確認し、サイトをホストしているのが唯一の解決策であるかどうかを確認します
[〜＃〜] not [〜＃〜]可能な場合でも、man-in-the-middleテクニックを使用してHTTPSトラフィックのコンテンツを監視する必要があります。それは全体のセキュリティを弱め、そもそもHTTPSを使用するポイントを破壊するだけです。ただし、外部でHTTPSトラフィックを監視できます。
たとえば、Webプロキシを経由するすべてのHTTPSトラフィックはCONNECTメソッドを使用して開始するため、接続先のサイトを知ることができます。これは、クリアテキストで送信される初期ビットです。この情報は、接続の継続を許可するかどうかを決定するのに役立ちます。
HTTPSトラフィックの帯域幅使用量を監視することもできます。これにより、彼らがそれを使用してビデオをストリーミングしているのか、それとも銀行などのオンライン取引に使用しているのかを知ることができます。
Man-In-The-MiddleプロキシとしてのDeleGate のようなhttpsslプロキシが必要になる場合があります。
編集：おそらく機能する新しい方法を追加します
たぶん、すべてのトラフィックをsslポートで渡してみて、それまでにプロセスを開始して、ターゲットサーバーがsslプロキシであるかどうかを検出し（認証が必要ない場合は検出できる）、それをブロックします。
ほとんどのコンテンツベースのファイアウォールはこのような戦略を使用しており、最初にそれを通過させ、次にそれをチェックしてブロックします。
この質問は古いことは知っていますが、DNSプロキシを使用する必要があると思います。したがって、SSLかどうかに関係なく、不要なすべてのドメインをブラックリストに登録できます。
たとえば、dnsmasqはうまく機能します。透過DNSプロキシとして構成できます。 「EndianFirewall」と呼ばれるオープンソースのLinuxディストリビューションがあります。あなたはそれのためにそれを使うことができます、そしてそれはセットアップするのが非常に簡単です。
MITMなしではどうしてもできないことは、HTTPSサイトのレポート（アクセスされた量、アクセスされた頻度、アクセスしたユーザーなど）を提供することです。