HTTPSコンテンツをフィルタリングし、MITMプロキシなしでキャプティブポータルを適用します
私の教会はゲストに無料のWiFiを提供し始めたいと思っていますが、2つの要件があります。
- 不適切なコンテンツ（ポルノやウェアーズなど）は除外する必要があります。
- エンドユーザーはアカウントを作成し、利用規約（キャプティブポータル）に同意する必要があります。
現在、 ntangle のインスタンスを Web Filter 、 HTTPS Inspector および Captive Portal アドオンで実行しています。 。
これは1つの例外を除いてうまく機能します：ユーザーが最初にWiFiに接続するとき、 CAルート証明書をインストールする HTTPSトラフィックをMITMして不良コンテンツをフィルターで除外できるようにするように依頼する必要があります。 HTTPS経由で任意のサイトにアクセスしようとすると、次のようなメッセージが表示されます。
ルート証明書をインポートするプロセスは長く、技術者以外の人にとっては混乱を招く可能性があるため、これは特にInternetExplorerユーザーにとって参入障壁になります。
ルート証明書を必要とするオンサイトマシンも多数ありますが、Active Directory GPOを使用しているマシンに展開できるため、問題はありません。
次のオプションも検討しました。
WPAD.DATファイル を使用してユーザーをフィルターに送信します：これは信頼できないようです（多くのブラウザーでは、デフォルト）。
IPによるコンテンツのブロック：これは、IPブラックリストを維持することを意味し、エンドユーザーは理由の説明の代わりに「接続が拒否されました」というメッセージを受け取ります。そのコンテンツをブロックしました。
[〜＃〜] sni [〜＃〜] を使用してコンテンツをブロックする：Untangleはこれをサポートしますが、 IPによるブロックと同じ問題があります（「接続が拒否されました」というメッセージ）。
ログインするにはユーザーをキャプティブポータルにリダイレクトする必要があるため、この問題はキャプティブポータルにも影響します。これは、MITMの要求/応答なしではHTTPSでは不可能です。
私は何かが足りないのですか？この問題を解決するための、エンドユーザーにとってより簡単な/必要のない別のアプローチはありますかdo何か？
あなたが尋ねている質問（「ユーザーが何もしなくても、 https://playboy.com の代わりにブロックページを提供するにはどうすればよいですか」）を「自分のバージョンの https://trusted-bank.com ユーザーの知らないうちに」。
HTTPSとブラウザは（最近）これを正確に回避するように設計されています。これにより、Webフィルタリングが困難になります。
Wpadをプッシュし、明示的なプロキシを使用している場合でも、「悪い」サイトへの接続を拒否することしかできません。これにより、sni関連の問題は解決されますが、実際にはそれほど先に進むことはできません（これにより）少なくとも問題の一部です）。
ログインページを提供するという点では、wisprはユーザーにログインする必要があることを通知するのに役立ちます。
あなたがケータリングしているのは一般の人々なので、SSLルート証明書をインストールするように合理的に依頼することはできないと思います（ホーム接続でそれらをmitmしないことをどうやって彼らは知っていますか？）。このプロセスも非常に技術的であり、ブラウザによって異なります。
あなたの選択肢は、IPブラックリストを維持するか、https接続を完全に無効にすることだと思います。 IPブラックリストの場合、はい、カスタムエラーページではなく「接続が拒否されました」と表示されるだけですが、ウェアーズやポルノへのアクセスがブロックされた理由を本当に説明する必要がありますか？ httpsを無効にすると、特定のWebサイトにアクセスできなくなりますが、教会にいる間に本当にこれらのWebサイトにアクセスする必要があるのか、それともオープンWi-Fi信号への侵入者が接続を傍受できるようにするのかを検討してください。 。おそらくそれを補うために、人々が本当にこれらのサイトを使用する必要がある場合に備えて、教会が所有するコンピューターでhttpsを（ルート証明書とインターセプトプロキシを介して）許可することができます。
ゲートウェイに透過プロキシを設定できます。たとえば、OpenWrtでは、Tinyproxyとファイアウォールのルールを使用して実行できます。 SSLの場合、redsocksなどのプロキシリダイレクタにTCPも必要です。ただし、現在のバージョンのredsocksは、プロキシとの通信にHTTP 1.0のみを使用します。これにより、Tinyproxy側でのフィルタリングが防止されます（フィルタリングとして） HTTP 1.1 Locationヘッダーに基づいています）。しかし、HTTP1.1をサポートするredsocksの代替手段を見つけることができると思います。
また、私の 要点 を確認し、手順と他の関連ソースへのリンクを確認してください。