HTTPS与强制门户

强制门户

http://www.whatis.com.cn/word_5182.htm

强制网络门户（captive portal）是一个Web页面，它是使用公共访问网络的用户在被授予访问权限前必须访问和交互的页面。强制网络门户通常在为因特网用户提供免费的Wi-Fi热点服务的商业中心、机场、宾馆大厅、咖啡厅和其他公共场所中使用。

　　在一个带有强制网络门户的网络中，一个用户第一次登录的时候，在被授予因特网的访问权限之前，会看到一个要求做一些特定动作的Web页面。一个简单的强制网络门户会强制用户至少看一眼(如果不是读的话)可接受用户策略页面，然后点击一个按钮表示同意策略条款。这大概是因为这样在碰到有用户在登录之际犯罪或做了其他破坏性的动作时可以为服务提供者免责的缘故。在有些强制网络门户中，会显示服务提供者的赞助商的广告，用户在被授予因特网访问权限之前必须点击一下或者关闭出现的窗口。还有一些强制网络门户在用户获得因特网访问权限之前会要求给出预设的用户ID和密码信息。这种认证可以打消使用无限热点作为犯罪活动的站点的积极性。大部分带有强制网络门户的服务器都同时装有反病毒和防火墙程序，用来保护用户的计算机免受攻击，这种攻击可能是来自因特网的，也可能来自同一个网络中的计算机。

　　即使是一个带有简单强制网络门户的免费公共访问网络，总会有人会不断地连接网络，以一种连续的方式使用网络来下载音乐、视频或其他大文件。这种行为称作带宽扭曲。这在强制网络门户中可以通过附加的编程来使其最小化。这种编程可以控制哪些大文件可下载、限制可下载文件的大小（以千字节或兆字节为单位），限制在单个会话中同时下载的数目或者阻塞那些通常用来下载大文件的Web站点。这被称作带宽扼杀或流量修整。

强制门户实现原理

强制门户有两种实现方法：

1、 当WAN侧网络断开的情况下， DNS请求被欺骗为 接入网络设备的 IP,  请求的HTTP目标地址， 被跳转到在接入网络设备上部署的页面， 此属于非典型门户。  主要用于诊断 设备的连通性， 给用户以提示设备异常的机会。

如果是HTTPS请求， 浏览器不会对主动跳转到门户页面上，需要用户点击继续（由于服务器证书不对） 。

 

https://msdn.microsoft.com/en-us/library/windows/hardware/dn408681.aspx

If the initial connection attempted is made over Secure Sockets Layer (SSL), the browser displays a security warning to the user before the user is redirected to the captive portal. This creates a confusing experience for users because they must ignore the security warning to get connected.

 

2、  当WAN侧网络连通的情况下， DNS工作正常， 对于所有的HTTP请求， 在设备的防火墙中被终止， 不继续由路由模块转送到目的主机上， 同时防火墙模块给客户端会送 HTTP 302 跳转报文， 客户端收到后跳转到目的门户页面上。

请注意此处凡是可重定向的请求， 都是HTTP报文， 不是HTTPS。

 

知名设备门户只支持 HTTP，不支持HTTPS

思科设备明确表示不支持 https

https://supportforums.cisco.com/discussion/11940491/how-redirect-https-traffic-captive-portal

redirection only happen on http traffic, a feature request has been issued to have the redirection happen on https.

please check the following

CSCar04580

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCar04580

---------------------------------------------------------------------------------

Please make sure to rate correct answers

 

https://forum.pfsense.org/index.php?topic=53630.0

pfsense设备也不支持HTTPS

Re: Captive portal slow redirect to login from https pages

« Reply #12 on: April 25, 2013, 02:26:29 pm »

It's the same. You can't redirect HTTPS.

Logged

Need help fast? Commercial Support!
Co-Author of pfSense: The Definitive Guide. - Check the Doc Wiki for FAQs.
Do not PM for help!

 

为啥门户不支持HTTPS?

对于DNS欺骗方式， HTTPS需要用户手动确认访问HTTP门户网站页面， 首先本身这种跳转方式， 是与HTTPS安全协议相冲突的，出现告警页面是对中间人类似攻击的警戒， 如果培养用户成经常点解类似页面的习惯， 则很有可能遭到类似攻击。

 

同时对于实现HSTS的浏览器， DNS欺骗过来的HTTPS访问， 则不会出现继续访问的选项。则用户无法访问门户。

 

对于第二种防火墙访问解析请求报文，执行HTTP跳转， 需要用户能够解析到报文的URL， 对于HTTPS访问， 其是安全连接， 不能被中间人窥视， 所以无法执行HTTP 302类似的跳转动作。

 

chrome对于HTTPS门户探测的一扇窗

对于防火墙执行URL跳转， 从原理上论断其只支持HTTP协议。

其它浏览器对于DNS欺骗执行的门户，对于没有HSTS协议支持的网站， 其可以让用户选择，点击继续， 可以继续执行访问页面门户网站， 但是对于HSTS网站（其域名内置在浏览器中， 要求浏览器只使用HTTPS访问服务器， 不管地址上是HTTP还是HTTPs）， 都没有继续选项。

 

但是对于chrome， 其实现了更加人性化的考虑， 其会判断，如果https失败， 会自动开启门户探测模式， 显示一个新的tab页面， 显示跳转后的门户站点。

http://serverfault.com/questions/596844/ssl-certificate-errors-in-captive-portals

3 down vote

The Chromium Project has a good page describing how their logic works for detecting captive portals:

1. Attempt to connect (plain HTTP) to a well-known host + URI
2. Expect HTTP 204 No Content
3. If a different response is received, assume it's a captive portal.

There are other details in the provided link regarding how they handle DNS failures when trying to resolve the well-known host, etc. This is just one example, but (in my personal experience) modern OS designs are using processes similar to this to detect and prompt the user even, in some cases, before the user opens a browser. (Consider: someone who only wants to use an IMAP client or other non-HTTP service.) In that case, the detection occurs not over SSL/TLS so your concern is avoided.

RFC 6585 Section 6 proposes a new HTTP status code 511 Network Authentication Required that doesn't help your SSL/TLS case but is another standard you might consider if you don't already use it.

http://serverfault.com/questions/755307/captive-portal-and-ssl?lq=1

However I can tell a sligtly better solution than giving up on this does exist, because I used it a few days ago in a school. At first I hadn't realized my (Debian 8) notebook had automatically connected to their open wifi network, and I typed some search terms in the Chrome address bar. My default search engine is Google, which serves only HTTPS pages. The page where I expected to obtain the Google results showed a connection error instead (unavoidable), but Chrome automatically opened a new tab showing the Captive Portal landing page, with the login form.