【网络】应用层-HTTPS协议

网络-应用层-HTTPS协议

以下内容引用自《图解HTTP》

HTTP的缺点

我们已了解到 HTTP 具有相当优秀和方便的一面，然而 HTTP 并非只有好的一面，事物皆具两面性，它也是有不足之处的。

• 通信使用明文（不加密），内容可能会被窃听
• 不验证通信方的身份，因此有可能遭遇伪装
• 无法证明报文的完整性，所以有可能已遭篡改

通信使用明文可能会被窃听

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即，HTTP 报文 使用明文（指未经过加密的报文）方式发送。

按TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。

即使已经过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

解决办法(加密防止被窃听)

• 通信加密

一种方式就是将通信加密。HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTPSecure，超文本传输安全协议）或 HTTP over SSL。

• 内容加密

还有一种将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把HTTP 报文里所含的内容进行加密处理。在这种情况下，客户端需要对 HTTP 报文进行加密处理后再发送请求。

不验证通信方的身份就可能遭遇伪装

在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。可以说是**来者不拒**

存在以下各种隐患：

• 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器
• 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端
• 无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限
• 无法判定请求是来自何方、出自谁手
• 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）

解决办法(查看对方证书)

虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。

证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

无法证明报文完整性，可能已遭篡改

HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。

内容在客户端和服务器之间传输的过程中可能会被第三方劫持并篡改信息，而通信双方无法察觉到被篡改。

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）

解决方法(MD5 和 SHA-1 等散列值校验/确认文件的数字签名)

HTTP常用的验证报文完整性的方式是MD5 和 SHA-1 等散列值校验和确认文件的数字签名,但事实上并不便捷、可靠。

这两种方法已经被山东大学王小云教授破解，相对来说已经不再安全。

---

为了有效防止这些弊端，有必要使用 HTTPS。SSL 提供认证和加密处理及摘要功能。仅靠 HTTP 确保完整性是非常困难的，因此通过和其他协议组合使用来实现这个目标

HTTP+加密+认证+完整性保护=HTTPS

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。

通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL 协议这层外壳的 HTTP。

在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能

SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术

SSL加密方法

对称加密

加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密

客户端和服务器共用一个密钥用来加密和解密，但是在双方进行通信的时候，密钥也是要被传递给对方才能进行解密操作，但是密钥本身是不加密的，密钥传输过程中被中间人拿到，那么加密的意义就没有了

要解决对称加密密钥的传递安全问题，就有了非对称加密

非对称加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

通信方式：

用户A生成公钥A1私钥A2，将公钥A1公开；用户B同理生成公钥B1私钥B2，同样将公钥B1公开。

二者通讯时，用户A拿用户B公开的公钥B1，加密原文message生成密文message1。用户B拿到message1，用自己的私钥B2解密就能拿到原文message

混合加密

由于非对称加密要进行两次加密解密，效率相较于对称机密来说要低，而对称加密的安全问题主要在于密钥的传递安全，所以可以用非对称加密的方式传递对称加密的密钥，就可以保证对称加密的安全性。

在交换密钥环节使用非对称密钥加密方式，之后的建立通信交换报文阶段则使用对称密钥加密方式。

SSL证书

即使是非对称加密也存在安全问题，那就是无法验证通信双方的身份，要是中间人在一开始就截获了通信报文，并且伪装成通信方，并且把公钥替换成中间人的公钥交给对方，那么非对称加密也就没有意义了

为了解决上述问题，可以使用由数字证书认证机构（CA，CertificateAuthority）和其相关机关颁发的公开密钥证书

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上

首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证

一旦验证通过，客户端便可明确两件事：

• 认证服务器的公开密钥的是真实有效的数字证书认证机构
• 服务器的公开密钥是值得信赖的

认证机关的公开密钥必须安全地转交给客户端,许多浏览器的公开密钥在下载安装时就植入到了浏览器客户端内部

为什么不是所有网站都用HTTPS

HTTPS 也存在一些问题，那就是当使用 SSL 时，它的处理速度会变慢

和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL 通信，因此整体上处理通信量不可避免会增加。
另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强

特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源

除此之外，想要节约购买证书的开销也是原因之一

要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。
那些购买证书并不合算的服务以及一些个人网站，可能只会选择采用 HTTP 的通信方式