hsts_HSTS和让我们加密

最新推荐文章于 2024-03-01 11:30:00 发布

cunya6061

最新推荐文章于 2024-03-01 11:30:00 发布

阅读量518

点赞数

文章标签：网络 java python linux http

原文链接：https://timkadlec.com/2016/01/hsts-and-lets-encrypt/

版权

hsts

I recently gave the Let’s Encrypt client a try and wrote up how that went. One of the follow-up questions that popped up was about HTTP Strict Transport Security (HSTS) and whether Let’s Encrypt’s helps with it. Since the question came up several times, I thought it would be worth writing up.

最近，我尝试了“ 让我们加密”客户端，并写下了如何进行。出现的后续问题之一是有关HTTP严格传输安全性(HSTS)以及Let's Encrypt的帮助。由于问题已经多次提出，所以我认为值得写。

什么是HSTS？ (What is HSTS?)

While the SSL certificate is a big boost for security in its own right, there is still a potential hole if you are redirecting HTTP content to HTTPS content.

尽管SSL证书本身可以极大地提高安全性，但是如果将HTTP内容重定向到HTTPS内容，则仍然存在潜在的漏洞。

Let’s say someone tries to request wpostats.com (diagrammed below). They may type it into the URL bar without the protocol (defaulting the request to HTTP) or they have it bookmarked from before it used HTTPS. In this case, the browser first makes the request to the server using a non-secure link (step 1). Then the server responds by redirecting the browser to the HTTPS version instead (step 2). The browser then repeats the request, this time using a secure URL (step 3). Finally, the browser responds with the secure version of the site (step 4).

假设有人尝试请求wpostats.com (如下图所示)。他们可以在不使用协议的情况下将其输入URL栏(将请求默认为HTTP)，或者在使用HTTPS之前将其添加为书签。在这种情况下，浏览器首先使用非安全链接向服务器发出请求(步骤1)。然后，服务器通过将浏览器重定向到HTTPS版本进行响应(步骤2)。浏览器然后使用安全URL重复该请求(步骤3)。最后，浏览器以站点的安全版本进行响应(步骤4)。

将非安全请求重定向到HTTPS的图 (Diagram of a non-secure request being redirected to HTTPS)

Trying to load a secure asset using a non-secure URL exposes a gap in security.

尝试使用非安全URL加载安全资产会暴露安全漏洞。

During the initial exchange, the user is communicating with the non-encrypted version of the site. This little gap could potentially be used to conduct a man-in-the-middle attack and send the user to a malicious site instead of the intended HTTPS version. This gap can occur every single time that person tries to access an asset using a non-secure URL.

在初始交换期间，用户正在与站点的非加密版本进行通信。这个小漏洞可能会被用来进行中间人攻击，并将用户发送到恶意站点，而不是预期的HTTPS版本。每当有人尝试使用非安全URL访问资产时，就会出现这种差距。

HTTP Strict Transport Security (HSTS) helps to fix this problem by telling the browser that it should never request content from your site using HTTP. To enable HSTS, you set a Strict-Transport-Security header whenever your site is accessed over HTTPS. Here’s the line I added to my virtualhost configuration for wpostats.com:

HTTP严格传输安全性(HSTS)通过告诉浏览器永远不要使用HTTP从您的站点请求内容来帮助解决此问题。要启用HSTS，只要通过HTTPS访问站点，就可以设置Strict-Transport-Security标头。这是我添加到wpostats.com的虚拟主机配置中的行：

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

With this line added to my server configuration, any asset served over HTTPS will include the following header:

将此行添加到我的服务器配置中后，通过HTTPS提供服务的任何资产都将包含以下标头：

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

The header will only be applied if sent over HTTPS. If it’s sent over HTTP it’s unreliable (an attacker could be injecting/removing it) and so the browser will choose to ignore it. As a result, that initial redirect still has to take place. The difference is that now, after the browser requests the content using a secure URL, the server can attach the HSTS header telling the browser to never bother asking for something over HTTP again, sealing off that vulnerability for any future access from that user. As an added bonus, with the redirect out of the way we get a little performance boost as well.

标头仅在通过HTTPS发送时才适用。如果它是通过HTTP发送的，那么它是不可靠的(攻击者可能正在注入/删除它)，因此浏览器将选择忽略它。结果，该初始重定向仍然必须进行。区别在于，现在，在浏览器使用安全URL请求内容之后，服务器可以附加HSTS标头，告诉浏览器再也不用再通过HTTP请求内容了，从而为该用户将来的访问提供了安全隐患。作为一项额外的好处，通过重定向，我们也获得了一些性能提升。

The header has three options (each of which were used in my example above):

标头具有三个选项(上面的示例中使用了每个选项)：

Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [;preload]

最大年龄 (max-age)

The max-age parameter is mandatory and specifics how long the browser should remember that this site is only supposed to be accessed over HTTPS.

max-age参数是必填参数，它指定浏览器应记住应该仅通过HTTPS访问该站点的时间。

The longer the better here. Let’s say you set a short max-age of one hour. The user accesses your secure site in the morning and the browser now seals up the vulnerability. If they then go to your site using a non-secure URL in the afternoon, the Strict-Transport-Security header is outdated, meaning the vulnerability is wide open again.

时间越长越好。假设您将max-age设置为一小时。用户在早上访问您的安全站点，并且浏览器现在可以修复漏洞。如果他们然后在下午使用非安全URL进入您的站点，则Strict-Transport-Security标头已过时，这意味着该漏洞再次被广泛打开。

Twitter sets their max-age to a whopping 20 years. I chose two years for mine, which most likely says something about me having committment issues or something.

Twitter将他们的max-age设置为20年之久。我为我选择了两年，这很可能说明我有承诺问题或其他事情。

includeSubDomains (includeSubDomains)

The includeSubDomains parameter is optional. When included, it tells the browser that the HSTS rules should apply to all subdomains as well.

includeSubDomains参数是可选的。如果包含在内，它将告诉浏览器HSTS规则也应适用于所有子域。

预载 (preload)

Some of you may have noticed a kink in the HSTS armor. If a user has a fresh local state for any reason (max-age expires, haven’t visited the site before) then that first load is still vulnerable to an attack until the server has passed back the HSTS header.

你们中有些人可能已经注意到HSTS装甲的扭结。如果用户由于某种原因( max-age期限已过期，之前没有访问过该站点)而处于新的本地状态，则直到服务器将HSTS标头回传之前，该第一个负载仍然容易受到攻击。

To counter this, each major modern browser has a preloaded HSTS list of domains that are hardcoded in the browser as being HTTPS only. This allows the browser to know to request only HTTPS assets from your URL without having to wait for your web server to tell them. This seals up that last little kink in the armor, but it does carry some significant risk.

为了解决这个问题，每个主要的现代浏览器都有一个预加载的HSTS域列表，这些域在浏览器中被硬编码为仅HTTPS。这使浏览器可以知道仅从URL请求HTTPS资产，而不必等待Web服务器告诉它们。这样可以密封装甲中的最后一点扭结，但确实带来一些重大风险。

If the browser has your domain hardcoded in the HSTS list and you need it removed, it may take months for the deletion to make its way out to users in a browser update. It’s not a simple process.

如果浏览器在HSTS列表中对您的域进行了硬编码，并且您需要将其删除，则删除可能需要几个月的时间才能在浏览器更新中显示给用户。这不是一个简单的过程。

For this reason, getting your domain included in the preload list requires that you manually submit the domain and that your HSTS header includes both the includeSubdomains parameter as well as this final preload parameter.

因此，要将您的域包含在预加载列表中，需要您手动提交域，并且HSTS标头同时包含includeSubdomains参数以及此最终preload参数。

“让我们加密”客户端是否启用HSTS？ (Does the Let’s Encrypt client enable HSTS?)

The Let’s Encrypt client can enable HSTS if you include the (currently undocumented) hsts flag.

如果您包含(当前未记录) hsts标志，则“让我们加密”客户端可以启用HSTS。

./letsencrypt-auto --hsts

The reason why it’s not enabled by default is that if things go wrong HSTS can cause some major headaches.

默认情况下未启用它的原因是，如果出现问题，HSTS可能会引起一些严重的麻烦。

Let’s say you have HSTS enabled. At some point something (pick a scary thing…any scary thing will do) goes wrong with your SSL configuration and your server is unable to serve a secure request. Your server cannot fulfill the secure request, but the browser (because of the HSTS header) cannot request anything that is insecure. You’re at an impasse and your visitor cannot see the content or asset in question. This remains the case until either your SSL configuration is restored or the HSTS header expires. Now imagine you’re running a large site with multiple teams and lots of moving parts and you see just how scary this issue could be.

假设您启用了HSTS。在某些时候，您的SSL配置出了点问题(选择一件令人恐惧的事情……任何一件令人恐惧的事情都会发生)，并且您的服务器无法满足安全请求。您的服务器无法满足安全要求，但是浏览器(由于HSTS标头)无法请求任何不安全的内容。您陷入僵局，访客无法看到相关内容或资产。在恢复SSL配置或HSTS标头过期之前，情况一直如此。现在想象一下，您正在运行一个拥有多个团队和大量活动部件的大型站点，并且看到此问题可能有多可怕。

Because of this risk, HSTS has to be an option that a user must specify in Let’s Encrypt—despite its importance.

由于存在这种风险，HSTS必须是用户必须在“让我们加密”中指定的选项，尽管它很重要。

有待改进 (Room for improvement)

That’s not to say the process couldn’t be improved. The GUI version of the client currently asks you a variety of questions as you setup your certificate. One of those questions asks if you would like to redirect all HTTP traffic to HTTPS.

这并不是说流程无法改进。客户端的GUI版本当前在设置证书时会询问您各种问题。其中一个问题询问您是否要将所有HTTP通信重定向到HTTPS。

An example of the Let’s Encrypt GUI asking the developer to decide whether to make everything HTTPS or keep HTTP around.

“让我们加密” GUI的示例要求开发人员决定是制作所有HTTPS还是保留HTTP。

If the developer decides to redirect all HTTP traffic to HTTPS, I would love to see the very next question be: “Would you like Let’s Encrypt to setup HSTS?”, probably with a warning encouraging the developer to make sure they have all content on HTTPS.

如果开发人员决定将所有HTTP流量重定向到HTTPS，我希望看到下一个问题是：“您要让我们加密来设置HSTS吗？”，可能带有警告，鼓励开发人员确保其上包含所有内容。 HTTPS。

Defaults matter and most people will stick with them. HSTS is important and HTTPS is…well…incomplete without it. If we’re serious about HTTPS Everywhere then we need to be just as serious about enabling HSTS as we are about making sure everyone is serving content over HTTPS. Finding a way to encourage its use whenever possible would go a long way towards boosting security on the web as well as adhere to one of the primary principles of the Let’s Encrypt initiative (emphasis mine):

违约很重要，大多数人会坚持下去。 HSTS很重要，而HTTPS很……没有它就不完整。如果我们对HTTPS到处都是认真的，那么我们在确保HSTS方面也要同样认真，就像确保每个人都通过HTTPS提供内容一样。找到一种鼓励其使用的方法将大大提高网络的安全性，并遵循“让我们加密”倡议(强调我的倡议)的主要原则之一：

Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.

Let's Encrypt将在CA方面并通过帮助站点操作员正确保护服务器的安全性，充当促进TLS安全最佳实践的平台。