鉴于流经互联网的大量个人数据，我们不能或应该忽视加密。现代浏览器提供了多种机制来确保用户数据在传输过程中安全无虞：安全 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 连接会在发送任何数据之前对整个通道进行端到端加密，这使得您与目标之间的机器无法读取或修改传输中的数据。
HTTPS 提供的安全性基于公钥和私有加密密钥的概念。（我们很高兴）对细节进行深入讨论超出了本文的范围，但核心前提却相当简单：使用给定公钥加密的数据只能使用相应的私钥解密。当浏览器启动 HTTPS 握手以创建安全通道时，服务器会提供一个证书，通过检查服务器是否拥有正确的私钥，为浏览器提供验证身份所需的所有信息。此后的所有通信均采用加密方式，证明请求会传送到经过身份验证的服务器，而响应则从经过身份验证的服务器接收。
因此，HTTPS 可以保证您是在与自己认为通信的服务器通信，没有其他人在监听或混杂线路。这种加密是保障 Web 安全性的绝对先决条件；如果您的应用目前不是通过 HTTPS 传送，则容易遭到攻击。修复。Ars Technica 提供了一份很好的证书获取和安装指南（免费），建议您查看该指南，了解技术详情。提供方和服务器之间的配置各不相同，但证书请求流程在任何位置都是一样的。
默认安全
在请求并安装证书后，请确保您的用户从您的辛苦工作中受益：通过 HTTP 重定向的魔力透明地将现有用户迁移到 HTTPS 连接，并确保 Cookie 仅通过安全连接进行传递。
请
当用户访问 http://example.com/ 时，请发送包含相应 Location 标头的 301 Moved
Permanently 响应，将用户重定向到 https://example.com/：
$ 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 等服务器中轻松设置此类重定向。例如，从 http://example.com/ 重定向到 https://example.com/ 的 Nginx 配置如下所示：
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
锁定 Cookie 罐
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
使用 secure 关键字设置的 Cookie 永远不会通过 HTTP 发送。
关闭打开的窗口
透明地重定向至 HTTPS 意味着，用户在访问您的网站时，绝大多数时候都会使用安全连接。但是，它确实会留下很小的攻击机会：初始 HTTP 连接是宽松的，容易受到 SSL 剥离和相关攻击。鉴于中间人对初始 HTTP 请求拥有完全访问权限，因此它可以充当您与服务器之间的代理，无论服务器意图如何，您都可以使用不安全的 HTTP 连接。
您可以通过要求浏览器强制执行 HTTP 严格传输安全协议 (HSTS) 来降低此类攻击的风险。发送 Strict-Transport-Security HTTP 标头可指示浏览器在不触碰网络的情况下，在客户端执行 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 详细信息）会注明此特定网站请求了仅限 HTTPS 的访问，这意味着无论用户如何访问该网站，都将通过 HTTPS 进行访问。即使她在浏览器中输入 http://example.com/，最终也会使用 HTTPS，而不进行任何 HTTP 连接。更好的是，如果浏览器检测到无效证书（可能试图欺骗服务器的身份），系统将不允许用户通过 HTTP 继续操作；要么全部发送，要么什么都没有，这是非常棒的。
浏览器将在 max-age 秒后（在本示例中为大约一个月）后使服务器的 HSTS 状态失效；请将该值设为一个合理的值。
您还可以通过在标头中添加 includeSubDomains 指令来确保某个来源的所有子网域受到保护：
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
安全无忧，安全无忧
HTTPS 是远程确保您发送的数据完整到达预期收件人的唯一方式。您应该立即为自己的网站和应用设置安全连接。这个过程相当简单，有助于确保客户数据安全。获得加密通道后，无论用户通过何种方式访问您的网站，您都应发送 301 HTTP 响应，以透明的方式将用户重定向到此安全连接。然后，在设置 Cookie 时添加关键字 secure（安全），确保所有用户的敏感会话信息都仅使用以下安全连接。完成上述所有步骤后，请向用户发送 Strict-Transport-Security 标头，以确保用户不会意外下车，从而确保其浏览器能够正常运行。
设置 HTTPS 不费吹灰之力，为您的网站及其用户带来巨大的好处。值得付出努力。
资源
- StartSSL 提供免费通过域名验证的证书。自由无比。当然，提高验证等级是可行且价格合理的。
- SSL 服务器测试：为服务器设置 HTTPS 后，请通过 SSL 实验室的服务器测试来验证是否设置正确。您将看到一份内容非常详细的报告，其中会显示您是否真的在正常运行。
- Ars Technica 最近的文章使用 SSL/TLS 保护您的网络服务器值得阅读，了解有关设置服务器的基本背景信息。
- HTTP 严格传输安全规范 (RFC6797) 是值得重点浏览的与您可能想要的
Strict-Transport-Security标头相关的所有技术信息。 - 在您真正知道自己在做什么后，接下来可以采取的一种可能的方法是，宣称只能通过一组特定证书访问您的网站。IETF 团队正在开展一些工作，以便您通过
Public-Key-Pins标头实现这些目的；这仍然是早期阶段，但很有趣，值得关注。