嵌入式 HTTPS 服务器。应该如何处理重定向，我应该提供 HTTP 吗？

Question

背景

我已经实现了一个 HTTPS 服务器，它位于一个硬件内部，用于对设备进行安全的远程配置。为了实现这一点，我使用了现有的轻量级嵌入式 TCP/IP 堆栈以及开源 SSL 库。位于其之上的 Web 服务器完全由我从头开始编写。 （这可能看起来像是对轮子的重新发明，但就我们的目的而言，它需要非常轻量级并且具有非常狭窄的特定功能集。例如，与我们正在使用的嵌入式 RTOS 以及 ROM“文件系统”的兼容性。这是一个只有几百 KB 可用于 HTTP(S) 会话和 SSL 上下文的系统，而不是多少兆字节。在考虑了所有因素并查看了各种其他产品之后，创建我自己的产品是有意义的）。此 Web 服务器只需要支持 5 到 10 个同时套接字连接（即 5 到 10 个并发或持久 HTTP 连接），这大约是硬件可以处理的数量。这很好，因为它是专为一两个人访问和管理盒子而设计的。

目前一切都很好。我已经对其进行了编码，以实现我认为 HTTP 1.1 所必需的尽可能多的 RFC2616。目前，它只是监听五个 HTTPS 端口（443），我还没有实现任何从端口 80 重定向的东西。

第一个问题 - 重定向

我看过无数关于从 HTTP 重定向到 HTTPS 的文章，但我所读到的所有内容都涉及如何配置现有和传统的 Web 服务器来执行此操作。我想要解决的是在协议级别使用了哪些技术，因为我必须以编程方式实现这一点。

常见的方法似乎是发出 301 / 302 响应。所以，我想到的策略是，假设我有八个同时请求的资源：

• 在端口 443 上侦听 HTTPS 连接。最多可同时使用六个 HTTPS 连接（六个套接字）。

• 在端口 80 上侦听 HTTP 连接，最多有两个 HTTP 连接（因此端口 80 上有两个套接字）可用。对于端口 80 上的套接字，不会真正访问真正的 Web 服务器。相反，我会一直从套接字读取，直到看到 \r\n\r\n 或 \n\n（表示请求标头结束），然后发回 301（或 302）响应，这在我的代码中几乎是一个硬-编码const char* 字符串。然后，关闭套接字。这两个端口 80 套接字的存在纯粹是为了重定向。

这个策略听起来明智吗？

目前我唯一不确定的是在 301 / 302 响应中包含重定向 URL。这个硬件“盒子”是一个可以放在房子里或路由器后面某处的设备，可能通过动态 DNS 服务等访问。那么，我将如何以编程方式确定它的“外部世界”等效 HTTPS URL？也许通过结合使用请求 URI 中的内容和原始 HTTP 请求标头的 host: 字段？

如果上面有任何问题，那么我的下一个最佳想法是返回一小段 HTML，其中包含一些 JavaScript，通过从浏览器获取 URL 来执行 HTTPS 重定向（特别是 JavaScript我要调用的方法我不记得了，但我已经做了很久了）。 （目前我还不确定 SSL 证书到底是如何工作的，因为没有可以指定的特定域，但我稍后会跨过那座桥，也许在一个单独的 SO 问题中。）

第二个问题 - 提供 HTTP 和 HTTPS

这可能更多地是一个设计问题，或者说是客户想要什么，而不是一个编程问题——但我想我还是把它放在这里看看人们有什么意见。我的问题是客户只是简单地声明盒子“应该有 SSL”，但仅此而已。例如，我不知道他们是否期望能够为最终用户提供是否使用 SSL 的选择。现在在实际问他们之前，我只是在预测可能会被问到什么，我想事先用一些知识和答案武装自己。换句话说，写规范的人“只想看挂锁”和“想要 SSL”，这显然是一件好的事情；但我需要为愚蠢的建议做好准备。

首先，我知道 SSL 没有半途而废的解决方案：您要么需要拥有它，要么什么都不需要。换句话说，假设我决定尝试通过 HTTPS 提供重要的东西来减少我的小处理器必须做的工作，但我通过 HTTP 提供图像和 CSS 文件。在阅读了一些内容之后，我现在确切地知道为什么这是绝对禁止的，原因有很多。

但是，如果我让最终用户能够在某个初始登录页面选择 HTTPS 或 HTTP，那会怎样？选择“HTTPS”将重定向到安全的 HTTPS 登录页面。例如，如果用户在从移动电话访问盒子时为了提高访问速度而选择牺牲安全性，这可能是一个有用的选项。此初始页面可能提供“安全登录”和“标准不安全登录 - 不建议”或类似内容。显然，就用户而言，这会带来一个漏洞，但它是否也会危及 SSL 连接？我的意思是，由于这个初始登录页面必须通过 HTTP 提供服务，因此理论上攻击者可能会破坏它，以便交换按钮——诸如此类。因此，HTTPS 是否应该从一开始就意味着 HTTPS？鉴于我已经设法将 HTTPS 硬塞到这个东西中并使其工作，并且考虑到它是专门为与现代浏览器（IE8/9，FF）一起使用而设计的，那么正常的 HTTP 访问应该是什么实际的原因呢？作为替代品提供？

Answer 1

关于问题 1：我认为商业网站经常使用这两种技术，但是如果服务器端的空间真的如此有限，那么读取主机头并返回 301 绝对是更可取的。

关于问题 2，对提供这两种协议的一个可能的反对意见是，一些中间人攻击会在会话期间从客户端的角度将 https 请求/响应通信重新路由到 http。大多数浏览器通过警告消息防止会话中的重新路由，但如果攻击者提前知道目标站点，他可能能够欺骗用户，特别是如果用户期望站点可以在任一模式下运行。为此（可能还有一堆我不知道的更好的原因），限制使用 https 可能是有意义的，因为无论如何您已经完成了这项工作。