Https
過濾 HTTPS 內容並在沒有 MITM 代理的情況下強制執行 Captive Portal
我的教會想開始為我們的客人提供免費 WiFi，但有兩個要求：
- 必須過濾掉不適當的內容（例如 Pornography 和 Warez）。
- 最終使用者必須創建一個帳戶並同意我們的條款和條件（強制門戶）。
目前，我們正在使用Web Filter、HTTPS Inspector和Captive Portal附加組件執行Untangle實例。
這很有效，但有一個例外：當使用者第一次連接到我們的 WiFi 時，我們必須要求他們安裝我們的 CA 根證書，以便能夠 MITM 他們的 HTTPS 流量以過濾掉不良內容，或者他們在嘗試通過 HTTPS 訪問任何站點：
這對於 Internet Explorer 使用者來說是一個相當大的進入障礙，因為導入根證書的過程對於非技術人員來說可能很長而且令人困惑。
我們還有許多需要根證書的現場機器，但我們可以將其推廣到具有 Active Directory GPO 的機器，因此這不是問題。
我們還考慮了以下選項：
- **使用WPAD.DAT 文件通過我們的過濾器發送使用者：**這似乎不可靠（許多瀏覽器預設關閉它）。
- **通過 IP 阻止內容：**這意味著維護一個 IP 黑名單，最終使用者會收到“連接被拒絕”消息，而不是解釋我們阻止該內容的原因。
- 使用SNI阻止內容： Untangle 開箱即用地支持此功能，但它與 IP 阻止存在相同的問題（“連接被拒絕”消息）。
這個問題也影響了我們的強制門戶，因為我們需要將使用者重定向到強制門戶以登錄 - 如果沒有 MITM 請求/響應，這在 HTTPS 上是不可能的。
我錯過了什麼嗎？是否有另一種解決這個問題的方法對最終使用者來說更容易/不需要他們做任何事情？
考慮您要問的問題（“我如何在我的使用者不必做任何事情的情況下提供阻止頁面而不是https://playboy.com ”）作為“我如何提供我自己的https://trusted-bank版本.com在我的使用者不知情的情況下”。
HTTPS 和瀏覽器（這些天）旨在避免這種情況。這使得網路過濾變得困難。
即使你推送了一個 wpad，並且有一個明確的代理，你仍然只能拒絕與“壞”站點的連接，雖然它確實解決了與 sni 相關的問題，但它真的不會讓你走得更遠（有了這個部分問題，至少）。
在提供登錄頁面方面，wispr 有助於通知使用者他們必須登錄。