使用 HTTPS 和 HTTP 严格的传输安全性混淆恶意中间人

  • Z时代
  • 2024-01-10
  • 分类：综合

考虑到流经互联网的大量个人数据的数量，加密不是我们可以或应该轻易忽视的事情。 现代浏览器提供了多种机制，可用于确保用户数据在传输过程中的 ： 安全 安全 cookie 和 严格传输安全 是其中最重要的两个。 它们允许您无缝地保护您的用户，将他们的连接升级到 HTTPS，并保证用户数据永远不会以明文形式发送。

你为什么要关心？ 考虑一下：

通过未加密的 HTTP 连接传递网页与将未密封的信封交给您在街上看到的第一个看起来像是朝邮局方向走的人或多或少相同。 如果你幸运的话，她可能会自己把它带到那里，或者她可能会把它交给她看到的下一个走对路的人。 那个人可能也会这样做，依此类推。

这个即兴链中的大多数陌生人都是值得信赖的，他们永远不会偷看你的公开信或改变它。 然而，这封信易手的次数越多，可以完全访问您发送的信函的人数就越多。 最后，您的信件的预期收件人很可能会 收到 一些东西 在邮件中 ，但这些东西是否 的 与 相同 您最初传递 是一个悬而未决的问题。 也许你应该密封那个信封……

中间人

无论好坏，大量互联网都依赖于陌生人的可信度。 服务器之间没有直接连接，而是在一个巨大的电话游戏中将请求和响应从一个路由器传递到另一个路由器。

您可以使用 traceroute 查看这些跃点的运行情况。 从我的计算机到 HTML5Rocks 的路线如下所示：

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 跳也不错，真的。 但是，如果我通过 HTTP 发送请求，那么每个中间路由器都可以完全访问我的请求和服务器的响应。 所有数据都以未加密的明文形式传输，任何中间人都可以充当 中间人 ，阅读我的数据，甚至在传输过程中对其进行操作。

更糟糕的是，这种拦截几乎无法检测到。 恶意修改的 HTTP 响应看起来与有效响应完全一样，因为不存在使您能够确保接收到的数据_正是_发送的数据的机制。 如果有人决定 把我的互联网颠倒过来取笑 ，那我或多或少不走运。

这是一条安全的线路吗？

从纯文本 HTTP 切换到安全的 HTTPS 连接可以为您提供针对中间商的最佳防御。 HTTPS 连接在发送任何数据之前对整个通道进行端到端加密，使您和目的地之间的机器无法读取或修改传输中的数据。

Chrome 的多功能框提供了很多关于连接状态的详细信息。

HTTPS 提供的安全性植根于公钥和私钥的概念。 对细节的深入讨论（很高兴）远远超出了本文的范围，但核心前提相当简单：用给定公钥加密的数据 只能 用相应的私钥解密。 当浏览器启动 HTTPS 握手以创建安全的

通道，服务器提供一个证书，该证书为浏览器提供所有必要的信息，以便通过检查服务器是否拥有正确的私钥来验证其身份。 从该点开始的所有通信都以这样一种方式加密，以证明请求已传递到经过身份验证的服务器并从该服务器接收到响应。

因此，HTTPS 为您提供了一些保证，即您正在与您认为正在与之交谈的服务器交谈，并且没有其他人正在监听或玩弄网络上的比特。 这种加密是网络安全的绝对先决条件； 如果您的应用程序当前未通过 HTTPS 交付，则它很容易受到攻击。 修理它。 Ars Technica 有一个很好的 指南来获取和安装证书（免费） ，我建议你看看技术细节。 配置因提供商和服务器而异，但证书请求过程在任何地方都是相同的。

默认安全

一旦您请求并安装了证书，请确保您的用户从您的辛勤工作中受益：通过 HTTP 重定向的魔力透明地将现有用户迁移到 HTTPS 连接，并确保 cookie 仅 通过安全连接传递。

这边请

当用户访问 http://example.com/, 将它们重定向到 https://example.com/通过发送一个 301 Moved Permanently以适当的方式回应 Location标题：

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

您可以在 Apache 或 Nginx 等服务器中轻松设置这种重定向。

例如，一个 Nginx 配置从 http://example.com/ 到 https://example.com/ 看起来像这样：

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

Lock the cookie jar

Cookie 使我们能够通过无状态 HTTP 协议为用户提供无缝登录体验。 存储在 cookie 中的数据（包括会话 ID 等敏感信息）会随每个请求一起发送，从而使服务器能够了解当前正在响应的用户。 一旦我们确保用户通过 HTTPS 访问我们的网站，我们还应该确保存储在 cookie 中的敏感数据仅通过安全连接传输，而不会以明文形式发送。

设置 cookie 通常涉及如下所示的 HTTP 标头：

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

您可以通过添加单个关键字来指示浏览器限制 cookie 的使用以保护会话：

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

使用 设置的 Cookie secure 关键字 永远不会通过 HTTP 发送。

关闭打开的窗口

透明重定向到 HTTPS 意味着您的用户在您的网站上的绝大多数时间都将使用安全连接。 然而，它确实为攻击留下了一个小窗口：初始 HTTP 连接是敞开的，容易受到 SSL 剥离 和相关攻击。 鉴于中间人可以完全访问初始 HTTP 请求，它可以充当您和服务器之间的代理，使您处于不安全的 HTTP 连接上，而不管服务器的意图如何。

您可以通过要求浏览器强制执行 来降低此类攻击的风险 HTTP 严格传输安全 (HSTS) 。 发送 Strict-Transport-SecurityHTTP 标头指示浏览器在 执行 HTTP 到 HTTPS 重定向 客户端 ，而无需接触网络（这也恰好对性能很有好处；最好的请求是您不必发出的请求）：

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

支持此标头的浏览器（当前为 Firefox、Chrome 和 Opera：caniuse has details ）会注明此特定站点已请求仅 HTTPS 访问，这意味着无论用户如何访问该站点，她都会访问通过 HTTPS。 即使她在浏览器中键入“http://example.com/”，她最终也会使用 HTTPS，而从未建立过 HTTP 连接。 更好的是，如果浏览器检测到无效证书（可能试图欺骗您的服务器身份），用户将不被允许通过 HTTP 继续； 要么全有，要么全无，这很好。

浏览器将过期服务器的 HSTS 状态后 max-age秒（在这个例子中大约是一个月）； 将此设置为相当高的值。

您还可以通过添加 includeSubDomains 标头的指令：

Strict-Transport-Security: max-age=2592000; includeSubDomains

安全地出发

HTTPS 是远程确保您发送的数据完好无损地到达预期接收者的唯一方法。 您应该立即为您的站点和应用程序设置安全连接。 这是一个相当简单的过程，将有助于确保客户数据的安全。 建立加密通道后，您应该：

  • 通过发送 301 HTTP 响应将用户透明地重定向到此安全连接，无论他们如何访问您的站点。

  • 所有用户的敏感会话信息 使用 仅 通过 添加 ，确保 该安全连接 安全 在设置 cookie 时 关键字 。

  • 寄一个 Strict-Transport-Security标头，以确保您的用户 始终 通过 HTTPS 访问您的网站，并且永远不会意外为活跃的网络攻击者打开机会之窗。

设置 HTTPS 的工作量并不大，而且对您的网站及其用户有巨大的好处。 这是非常值得的。

资源

  • StartSSL 提供免费的域验证证书。 你不能自由。 当然，升级到更高级别的验证是可能的，而且价格合理。

  • SSL Server Test: 一旦你为你的服务器设置了 HTTPS，通过 SSL Labs 的服务器测试来验证你是否正确地完成了它。 您将获得一份非常 详细的报告 ，向您展示无论您是否真的启动并运行。

  • Ars Technica 最近的文章 “使用 SSL/TLS 保护您的 Web 服务器” 值得一读，以了解有关设置服务器的具体细节的更多背景细节。

  • 该 HTTP严格传输安全规范（RFC6797） 值得一撇有关的所有技术资料 Strict-Transport-Security 您可能想要的标题。

  • 一旦您真正知道自己在做什么，下一步可能是宣传您的网站只能通过一组特定的证书访问。 还有在IETF一些工作正在进行中，这将允许你做到这一点通过 的 Public-Key-Pins标头 ； 仍处于早期阶段，但很有趣，值得关注。

以上是 使用 HTTPS 和 HTTP 严格的传输安全性混淆恶意中间人 的全部内容， 来源链接： utcz.com/z/264368.html

回到顶部