怎样在服务器上启用 HTTPS [每日前端夜话(0x1A)]

每日前端夜话0x1A

每日前端夜话,陪你聊前端。

每天晚上18:00准时推送。

正文共:6188 字 9代码

预计阅读时间: 16 分钟

摘要

  • 创建一个 2048 位 RSA 公钥/私钥对。
  • 生成一个嵌入您的公钥的证书签名请求 (CSR)
  • 将 CSR 与证书颁发机构 (CA) 共享以接收最终证书或证书链。
  • 将最终证书安装在非网络可访问的位置,例如 /etc/ssl(Linux 和 Unix)或 IIS 需要它的位置 (Windows)。

此部分使用 openssl 命令行程序(大部分 Linux、BSD 和 Mac OS X 系统均附带此程序)来生成私钥/公钥和 CSR。

我们首先生成一个 2048 位 RSA 密钥对。较短的密钥,如 1024 位,不足以抵御暴力猜测攻击。 较长的密钥,如 4096 位,则有点过度。 长远来看,随着计算机处理开销降低,密钥长度会增加。 目前 2048 是最佳长度。

用于生成 RSA 密钥对的命令为:

这将生成以下输出:

在此步骤中,您将公钥和有关贵组织及网站的信息嵌入到证书签名请求(或 CSR)中。 openssl 命令以交互方式要求您提供所需的元数据。

运行以下命令:

系统将输出以下内容:

为确保 CSR 的有效性,请运行以下命令:

响应结果应如下所示:

对于不同的证书颁发机构 (CA),需要使用不同的方法将 CSR 发送给他们。 这些方法可能包括在其网站上使用表单、以电子邮件或其他方式发送 CSR。 一些 CA(或其经销商)甚至可能将其中部分或全部流程自动化(在某些情况下,包括密钥对和 CSR 的生成)。

将 CSR 发送给 CA 并按照他们的说明接收最终证书或证书链。

对于为您的公钥进行证实的服务,不同 CA 的收费将有所不同。

还可以选择将密钥映射到多个 DNS 名称,包括多个独立名称(例如 example.com、www.example.com、example.net 和 www.example.net 的全部)或“通配符”名称(例如 *.example.com)。

例如,某个 CA 目前提供以下价格:

  • 标准:16 美元/年,适用于 example.com 和 www.example.com。
  • 通配符:150 美元/年,适用于 example.com 和 *.example.com。

按这些价格,当您有 9 个以上子域名时,通配符证书比较划算;您也可以只购买一个或多个单名称证书。 (例如,如果您有五个以上子域名,在服务器上启用 HTTPS 时,您可能发现通配符证书更方便。)

Note: 记住,在通配符证书中,通配符只适用于一个 DNS 标签。对 *.example.com 有效的证书将对 foo.example.com 和 bar.example.com 有效,但对于 foo.bar.example.com 无效。

将证书复制到所有前端服务器的非网络可访问位置,例如 /etc/ssl(Linux 和 Unix)或 IIS 需要它们的位置 (Windows)。

在服务器上启用 HTTPS 是确保网页安全的关键一步。

  • 使用 Mozilla 的服务器配置工具来设置服务器以支持 HTTPS。
  • 定期使用 Qualys 便捷的 SSL 服务器测试来测试网站,并确保得分至少为 A 或 A+。

此时,您必须做出关键的操作决定。选择下列其中一项:

  • 给为网络服务器提供内容的每个主机名指定一个独立的 IP 地址。
  • 使用基于名称的虚拟托管。

如果您一直针对每个主机名使用独立的 IP 地址,则可以轻松地让所有客户端支持 HTTP 和 HTTPS。

但是,大多数网站运营商使用基于名称的虚拟托管以节约 IP 地址,另一个原因是这样通常更方便。 Windows XP 上的 IE 和 2.3 版以前的 Android 的问题是,它们不理解服务器名称指示 (SNI),而这对 HTTPS 基于名称的虚拟托管非常重要。

将来有一天(希望很快),不支持 SNI 的客户端将被现代软件代替。 监控请求日志中的 User Agent 字符串,以了解何时已有足够的用户迁移到现代软件。 (您可以决定您的阈值;可能是 < 5%,或 < 1%。)

如果您的服务器上还没有 HTTPS 服务,请立即启用(无需将 HTTP 重定向到 HTTPS;参见下文)。 配置网络服务器以使用您购买并安装的证书。 您可能发现 Mozilla 便捷的配置生成器很有用。

如果您有许多主机名/子域名,它们每个都需要使用正确的证书。

Caution: 如果您已完成上述步骤,但您使用 HTTPS 仅仅是为了将客户端重定向回 HTTP,那么,请马上停止这么做。参考下一部分以确保 HTTPS 和 HTTP 顺畅工作。Note: 最终,您应将 HTTP 请求重定向到 HTTPS 并使用 HTTP 严格传输安全 (HSTS)。不过,现在不是向这种做法进行迁移的合适阶段;请参考“将 HTTP 重定向到 HTTPS”和“打开严格传输安全和安全 Cookie”。

现在,以及您网站的整个生命周期中,使用 Qualys 便捷的 SSL 服务器测试来检查您的 HTTPS 配置。 您的网站得分应为 A 或 A+;将导致等级较低的任何因素均视为错误。(今天的 A 在明天会变成 B,因为针对算法和协议的攻击始终在改进!)

由于您的网站同时运行 HTTP 和 HTTPS,不管哪种协议,都应当尽可能顺畅运行。 一个重要的因素是对站内链接使用相对网址。

确保站内网址和外部网址与协议无关;即确保使用相对路径或省去协议,例如 //example.com/something.js

当您通过 HTTPS 提供一个包括 HTTP 资源的页面(称为混合内容)时会出现问题。 浏览器将警告用户,已失去 HTTPS 的全部能力。事实上,如果是主动混合内容(脚本、插件、CSS、iframe),则浏览器通常根本不会加载或执行此内容,从而导致页面残缺。

Note: 在 HTTP 页面中包括 HTTPS 资源完全没问题。

此外,当您链接到您网站中的其他页面时,用户可能从 HTTPS 降级为 HTTP。

当您的页面包括了使用 http:// 架构的完全限定站内网址时,会出现这些问题。

不建议的做法 — 我们不建议使用完全限定站内网址。

换句话说,使站内网址尽可能是相对地址:协议相对(省去协议,以 //example.com 开头)或主机相对(以相对路径开头,例如 /jquery.js)。

建议做法 — 我们建议您使用协议相对站内网址。

建议做法 — 我们建议您使用相对站内网址。

通过脚本实现,而不是手动操作。如果网站内容在数据库中,则在数据库的开发副本中测试您的脚本。 如果网站内容由简单文件组成,则要在文件的开发副本中测试您的脚本。 像平常一样,只有在更改通过 QA 后,才会将更改推送到生产平台中。可以使用 Bram van Damme 的脚本或类似脚本来检测网站中的混合内容。

在链接到其他网站(而不是包括其他网站的资源)时,请勿更改协议,因为您不能控制这些网站的运行方式。

Success: 为确保大型网站的迁移更顺利,我们建议采用协议相对网址。如果您还不确定是否能够完全部署 HTTPS,则强制网站的所有子资源使用 HTTPS 可能会弄巧成拙。可能会有一段时间,您对 HTTPS 觉得新奇,并且 HTTP 网站仍必须像往常一样运行。但从长远看,您将完成迁移并锁定 HTTPS(请参考接下来两个部分)。

如果网站依赖第三方(例如 CDN、jquery.com)提供的脚本、图像或其他资源,则有两个选择:

  • 对这些资源使用协议相对网址。如果该第三方不提供 HTTPS,请求他们提供。 大多数已经提供,包括 jquery.com。
  • 从您控制的并且同时提供 HTTP 和 HTTPS 的服务器上提供资源。 这通常是个好点子,因为您可以更好地控制网站的外观、性能和安全。 此外,您不必信任第三方,尽管他们总是很不错。

Note: 请记住,您还需要更改样式表、JavaScript、重定向规则、<link> 标记和 CSP 声明中的站内网址,而不仅是 HTML 页面。

您需要在页面的最前面放一个规范链接,以告诉搜索引擎 HTTPS 是访问您网站的最佳方法。

在页面中设置 <link rel="canonical" href="https://…"/> 标记。这样可帮助搜索引擎确定访问您网站的最佳方法。

此时,您已准备好“锁定”使用 HTTPS。

  • 使用 HTTP 严格传输安全 (HSTS) 来避免 301 重定向产生的开销。
  • 始终在 Cookie 上设置安全标记。

首先,使用严格传输安全来告诉客户端,它们始终应通过 HTTPS 来连接您的服务器,即使在访问 http:// 引用时也是如此。

这样可挫败 SSL 剥离 之类的攻击,还能避免我们在将 HTTP 重定向到 HTTPS时启用的 301 redirect 产生的往返开销。

Note: 如果您的网站在其传输层安全协议 (TLS) 配置中出现过错误(例如过期证书),则已将您的网站注明为已知 HSTS 主机的客户端可能出现硬故障。通过此方式显式设计 HSTS 可确保网络攻击者无法欺骗客户端访问没有 HTTPS 的网站。在确认您的网站运营足够可靠之前,不要启用 HSTS,以避免部署 HTTPS 时总是出现证书验证错误。

通过设置 Strict-Transport-Security 标头来打开 HTTP 严格传输安全 (HSTS)。OWASP 的 HSTS 页面有说明链接,提供了针对各种服务器软件的说明。

大多数网络服务器提供相似的功能来添加自定义标头。

Note:max-age 的计算单位为秒。您可以从较小的值开始,并随着您越来越熟练自如地运营纯 HTTPS 网站而逐步增加 max-age

还要务必确保客户端从不通过 HTTP 发送 Cookie(例如用于身份验证或网站偏好)。 例如,如果用户的身份验证 Cookie 将在明文中暴露,则其整个会话的安全保障将被破坏 — 即使其他的一切都正确无误!

因此,更改您的网络应用,以便始终在其设置的 Cookie 上设置安全标记。此 OWASP 网页解释了如何在多个应用框架中设置安全标记。 每个应用框架都采用一种方法来设置此标记。

大多数网络服务器都提供一种简单的重定向功能。使用 301 (Moved Permanently) 来告诉搜索引擎和浏览器,此 HTTPS 版本是规范的,并将用户从 HTTP 重定向到网站的 HTTPS 版本。

对于从 HTTP 迁移到 HTTPS,许多开发者有着合情合理的顾虑。Google 网站站长团队提供了一些非常好的指导【https://plus.google.com/+GoogleWebmasters/posts/eYmUYvNNT5J】。

Google 使用 HTTPS 用作肯定性的搜索质量指标【https://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html】。Google 还发布一个指南,说明在维护其搜索排名时如何传输、移动或迁移您的网站。

Bing 也发布了网站站长指南。

当内容和应用层优化得当时(请参考 Steve Souders 的论著以获取很好的建议),相对于应用的总体开销而言,其余的传输层安全协议 (TLS) 性能问题一般都是小问题。此外,您可以减少和分摊那些开销。 (如需 TLS 优化建议和一般建议,请参考 IlyaGrigorik 撰写的高性能浏览器网络。) 另请参考 Ivan Ristic 的 OpenSSL 手册和 SSL 和 TLS 的防弹衣。

在某些情况下,TLS 可以提高性能,主要是可以采用 HTTP/2 所带来的结果。 Chris Palmer 在 Chrome 开发峰会 2014 上做过一个演讲,讨论 HTTPS 和 HTTP/2 的性能。

当用户从您的 HTTPS 网站链接到其他 HTTP 网站时,User Agent 不会发送引用站点标头。如果这是个问题,有多种方法可解决:

  • 其他网站应迁移到 HTTPS。如果被引用网站可以完成本指南中的在服务器上启用 HTTPS 部分,则可以将您网站中指向他们网站的链接从 http:// 更改为 https://,或可以使用协议相对链接。
  • 为解决引用站点标头的各种问题,可使用新的引用站点政策标准。

由于各搜索引擎正在迁移到 HTTPS,将来,当您迁移到 HTTPS 时,可能会看到更多的引用站点标头。

Caution: 根据 HTTP RFC,如果引用页面是通过安全协议传输的,则客户端不能在(非安全)HTTP 请求中包括引用站点标头字段。

通过展示广告来赚钱的网站运营商希望确保迁移到 HTTPS 不会降低广告曝光量。 但是,由于混合内容的安全问题,HTTP <iframe> 在 HTTPS 页面中不起作用。 这里就存在一个棘手的集体行动问题:在广告商通过 HTTPS 发布广告之前,网站运营商无法在不损失广告收入的情况下迁移到 HTTPS;但是在网站运营商迁移到 HTTPS 之前,广告商没有动力来通过 HTTPS 发布广告。

广告商至少应通过 HTTPS 提供广告服务(例如完成本页面中的“在服务器上启用 HTTPS”部分)。 许多广告商已经这样做了。您应当请求完全不提供 HTTPS 的广告商至少开始提供 HTTPS。

原文发布于微信公众号 - 京程一灯(jingchengyideng)

原文发表时间:2019-01-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券