【发布时间】:2010-09-05 17:18:20
【问题描述】:
如何将 HTTPS 重定向到 HTTP?也就是说,与每个人(似乎)教的相反。
我有一个 HTTPS 上的服务器,我为此支付了 SSL 认证,还有一个镜像,我没有,只是为了紧急情况而保留,所以不值得获得认证。
在我客户的桌面上,我有一些指向http://production_server 和https://production_server 的快捷方式(两者都有效)。但是,我知道如果我的生产服务器出现故障,那么 DNS 转发就会启动,并且那些在快捷方式上有“https”的客户端将盯着https://mirror_server(这不起作用)和一个大胖的 Internet Explorer 7 红色我公司的不安屏幕。
不幸的是,我不能只在客户端级别进行切换。这些用户是非常计算机文盲:并且很可能会因为看到 HTTPS“不安全”错误而吓坏了(尤其是现在 Firefox 3 和 Internet Explorer 7 处理它的方式:完全停止,谢天谢地,但在这里没有帮助我哈哈)。
very easy to find Apache solutions 代表 http->https redirection,但对于我来说,我不能做相反的事情。
想法?
【问题讨论】:
-
不要那样做!来自 HTTP 的 HTTPS 重定向非常危险(事实上,由于滥用,很快就会被所有浏览器阻止),尤其是如果这是通过静默 HTTP 状态的节点(但如果这是通过 javascript 完成的,情况也是如此),除非:- (1)有一个短暂的HTTPS停放页面,邀请用户通过主动点击链接来浏览它;或: - (2) HTTPS 重定向到完全相同的 SAME 域上的 HTTP,并且重定向不会更改请求的内容类型。在浏览器中允许它允许许多恶意软件通过隔离。这种重定向非常具有欺骗性。
-
这看起来像一个内部站点,OP 知道它发生了什么,因此并不危险......如果这是一个面向 Web 的服务器,我同意你的看法,但是一个内部站点,本地唯一的网络服务器,这种方式的重定向不会成为问题。
-
@verdy_p 我正在处理 HTTPS 到 HTTP 302 重定向,即强制门户的情况。您能否指出您所指的文档?
-
对于您的强制门户,永远不要执行任何 HTTPS 到 HTTP 302 重定向,除非这是完全相同的域(甚至不是子域)。并且由于存在信息泄露的高风险,请注意通过重定向透明传递的会话令牌和 cookie!您应该知道 HTTP 目标可以被调整,恶意软件透明代理甚至恶意 DNS 可以获取信息:您的客户可能甚至不知道您的仅 HTTP 目标将无法访问,并且实际上会进入黑帽!所以永远不要在包含私有会话/cookies/请求的 HTTPS 链接上这样做。
-
此类 HTTPS 302 重定向始终是您的 HTTPS 站点中的安全漏洞。巨大的风险是会话被盗,您的经过身份验证的用户的私人账户被盗。在所有情况下,永远不要为加载 javascript 或活动多媒体进行此类重定向:这是 HTTPS“沙盒”领域中的一扇敞开的大门。真正考虑做一些相反的事情:将 HTTP 重定向到 HTTPS(特别是您的主门户或不需要私有数据/会话/cookies 的静态公共页面)并使用 HTTPS 进行其他操作。如果您需要从 HTTPS 到 HTTP,请使用标准链接(在不同的请求中)