尽管 HTTP 在我们的项目中应用已经很广泛了,然而 HTTP 并非只有好的一面,事物皆具有两面性,它也是有不足之处的。

HTTP 主要有这些不足,列举如下:

1. 缺乏安全性: HTTP 通信是明文传输的,这是的数据容易收到窃听和篡改的威胁。攻击者可以使用网络嗅探工具截获 HTTP 请求和响应,获取用户敏感信息。除此之外,HTTP 没有内置的身份验证机制,使得服务器无法验证请求的真实性和发送者的身份。互联网上的任何角落都存在通信内容被窃听的风险,如下图所示:
   
2. 无状态性：HTTP 是一种无状态协议,服务器不会保留关于之前请求的任何信息。每个请求都是独立的,服务器无法直接识别来自同一用户的多个请求。这限制了一些功能的实现，,如用户会话跟踪、状态管理和个性化体验。为了跟踪用户状态,需要使用额外的机制,如使用 Cookie 或在 URL 中添加会话标识符;
3. 性能问题: HTTP 在处理大量并发请求时存在性能问题,每个 HTTP 请求都需要建立和维护一个新的链接,这会增加服务器的负载和延迟。此外,HTTP 头部信息相对较大,占用了传输带宽没特别是在多次请求中重复的头部信息,这回导致不必要的带宽小环和传输功率的降低;
4. 缺乏灵活性: HTTP 是一种请求-响应协议,客户端发送请求,服务器返回响应。这种模式限制了服务器向客户端主动发送数据的能力,客户端必须主动发起请求才能接收到更新的信息。对于实时性要求较高的应用场景,如聊天应用或实时数据流,HTTP 的这种单向通信模式不够灵活;

什么是 HTTPS

为了解决上述存在的问题,就用到了 HTTPS,实际上它也并发是应用层的一种新协议,只是 HTTP 通信接口部分用 SSL 和 TLS 协议代替而已。

在正常情况下,HTTP 直接和 TCP 通信,当使用 SSL 时,则演变成先和 SSL 通信,再由 SSL 和 TCP 通信了,换句话说,所谓的 HTTPS 实际上就是身披 SSL 协议这层外壳的 HTTP。

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

相互交换秘钥的公开密钥加密技术

在对 SSL 进行讲解之前,我们先来了解一下加密方法。SSL 采用一种叫做公开密钥加密的加密处理方式。

在近代的加密方法中,加密算法是公开的,而密钥是保密的,通过这种方式得以保持加密方法的安全性。加密和揭秘都会用到密钥,没有密钥就无法对密码解密,反过来说,任何人只要持有密钥就能解密了。

对称密钥加密(共享密钥加密)

加密和揭秘同用一个密钥的方式称为共享密钥加密,也被叫做对称密钥加密:

以共享密钥方式加密时必须将密钥也发给对方,这是一个挑战,因为在传输密钥本身也需要保证其安全性。如果密钥在传输过程中被截获或篡改,通信的机密性将会被威胁。

在使用共享密钥的通信中,通信双方必须实现共享密钥,并且彼此信任密钥的安全性。如果其中以防的密钥被泄漏或者公婆,通信的机密性将无法保证。因此,确保双方对共享密钥的安全性和信任是至关重要的。

非对称密钥加密(公开密钥加密)

公开密钥加密方式很好地解决了共享密钥加密的困难。它使用一堆非对称的密钥,一把叫作私有密钥,另外一把叫作公开密钥。私有弥远哦不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用方式: 发送密文的一方使用 对方的公钥 对信息进行加密,对方接收到被加密的信息后再使用自己的私钥进行解密。

特点: 信息传输一对多,服务器只需要维持好一个私钥就能和多个客户端进行加密通信。可以实现安全的身份验证、数字签名和密钥交换等功能。

优点:

1. 安全性高: 私钥不会被公开传输,只有私钥的持有者才能解密加密的信息;
2. 方便的密钥交换: 发送方和接收方只需交换公钥,而无需交换密钥;
3. 可以实现数字签名: 私钥持有者可以使用时要对消息进行签名,接收方可以使用公钥验证签名的有效性;

缺点:

1. 计算复杂度高: 与对称密钥加密相比,非对称密钥加密的计算速度慢,处理大量数据时可能会更耗时;
2. 密钥管理复杂: 由于涉及到公钥和私钥的生成、发布和保护,密钥管理可能会更复杂;
3. 通信效率较低：由于加密和解密操作需要使用较长的密钥,导致加密数据的大小增加,从而降低了通信效率;

虽然说安全性高,但也不是没有被盗的可能,因为公钥是公开的,谁都可以获取,如果发送的加密信息是通过私钥加密的话,有公钥的黑客就可以用这个公钥来解密拿到里面的信息。

混合加密机制

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。它录用了对称密钥加密算法的高效性和非对称密钥加密算法的安全性,可以保证安全性的同时提高加密和揭秘的效率。

混合加密机制的操作步骤主要一下几个方面:

1. 密钥交换: 接收方生成一对非对称密钥(公钥和私钥),并将公钥发送给发送方;
2. 对称密钥生成: 发送方生成一个随机的对称密钥,用于对消息进行加密;
3. 对称密钥加密: 发送方使用接收方的公钥将对称密钥加密,并将加密后的对称密钥发送给接收方;
4. 消息处理: 发送方使用对称密钥对要发送的消息进行加密,并将加密后的消息发送给接收方;
5. 密文传输: 接收方收到加密后的对称密钥和消息;
6. 对称密钥加密: 接收方使用自己的私钥解密接收到的对称密钥;
7. 消息解密: 接收方使用解密后的对称密钥对接收到的消息进行解密,获得原文明文消息;

使用文字的方式来表达难免会有些难以理解,接下来我们使用一个流程图来看看回合加密机制的步骤是怎样实现的:

虽然混合加密机制结合了对称加密和非对称加密两者的优势,能后实现双方之间安全的传输。但也不是没有缺点,它的缺点主要有以下几个方面:

1. 数据不完整性: 混合加密主要是为了解决 HTTP 中内容可能被窃听的问题。但是它并不能保证数据的完整性,也就是说在传输的时候数据是有可能被第三方篡改的,比如完全替换掉,所以说它并不能校验数据的完整性;
2. 复杂性: 混合加密设计多种加密算法和密钥管理过程,因此实现和管理起来相对复杂;
3. 密钥交换: 混合加密需要在通信双方之间进行密钥交换,以便简历安全的通信信道,如果密钥交换过程不正确或者被攻击者窃取,那么整个加密系统的安全性将会受到威胁;
4. 性能开销: 混合加密需要同时使用非对称加密和对称加密算法,非对称加密算啊的加密和解密速度较慢,而对称加密算法的加密和解密速度较快。因此,在大规模数据传输时,可能会引入性能开销;
5. 中间人攻击: 混合加密并不能防止中间人攻击,如果攻击者能够劫持或篡改通信信道,并替换公钥或插入恶意代码,那么它们仍然可以窃听、修改或伪装通信内容;

保证公开密钥正确性的数字证书

目前来看,混合加密机制已经很安全了,但也不是完全没有问题。那就是无法郑敏公开密钥本身就是货真价实的公开密钥。它有可能在公开密钥传输途中,真正的公开密钥已经被攻击者替换掉了。

为了解决这个问题,通过数字证书认证机构和其他相关机关颁发的公开密钥证书。其中数字证书的基本组成部分主要有以下几个主体:

1. 公钥：证书中包含了公钥,即需要验证的公开密钥;
2. 签名：证书颁发机构使用自己的私钥对证书的内容进行数字签名,以验证证书的完整性和真实性;
3. 有效期：证书包含了开始和结束的有效期,指定了证书的有效期限;
4. 颁发机构信息：证书中包含了颁发机构的身份信息,用于验证颁发机构的可信性;

证书的主体部分包含了公钥持有者的身份信息,如名称、电子邮件地址等。

服务器会将这份由数字证书认证机构办法的公钥证书发送给客户端,以进行公开密钥加密方式通信。接到证书的客户端可使用数字证书认证机构的公开密钥,对那张证书上的数字签字进行验证,一旦验证通过,客户端便可以明确两件事:

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

数字签名是什么呢,它是一种用于验证数据完整性和身份认证的技术,它的产生过程主要有以下几个步骤:

1. 生成密钥对: 数字签名使用非对称密钥加密算法,首先需要生成密钥对。密钥对包括一个私钥和一个公钥。私钥用于生成签名,而公钥用于验证签名;
2. 签名生成: 使用私钥对数据进行签名,签名生成的过程通常是先对数据进行哈希运算,然后使用私钥对哈希值进行加密,生成签名;
3. 签名附加：将生成的签名与原始数据一起发送或存储;
4. 验证签名：接收方或验证者收到签名和原始数据后,可以执行以下步骤验证签名的有效性
   • 提取公钥: 从签名的来源获取签名者的公钥;
   • 解密签名: 使用签名者的公钥对签名进行解密,得到解密后的哈希值;
   • 哈希计算：对原始数据进行哈希运算,得到哈希值;
   • 比较哈希值：将解密后的哈希值与计算得到的哈希值进行比较。如果两者匹配,说明签名是有效的。如果不匹配,说明签名无效；

通过这个过程,验证者可以确保数据在传输过程中没有被篡改,并且可以确定签名的来源。

数字证书的颁发流程

有了数字签名校验数据的完整性,但是数字签名校验的前提是能拿到发送方的公钥,并且保证这个公钥是可信赖的,所以就需要数字证书。

数字证书的颁发流程通常涉及以下步骤:

1. 密钥生成:

   • 实体(个人、组织或服务器)生成一个密钥对,包括一个公钥和一个私钥;
   • 私钥用于加密和签名,公钥用于解密和验证;

2. 证书请求:

   • 实体向证书办法机构(Certificate Authority,CA)提交证书请求;
   • 证书请求中包含实体的公钥以及一些身份信息,例如名称、电子邮件地址等;

3. 身份验证:

   • CA 对实体的身份进行验证,验证的方式包括人工审核、文件验证、域名验证等;
   • CA 确保证书请求的提交者拥有对应的私钥，并具备合法身份；

4. 证书生成:

   • 经过身份验证后,CA 使用自己的私钥对证书进行签名,生成数字证书;
   • 数字证书中包含实体的公钥,身份信息以及 CA 的签名;

5. 证书颁发:

   • CA 将生成的数字证书颁发给实体,通常以电子文件的形式提供;
   • 实体接收到数字证书后,可以将其用于加密通信、数字签名等安全操作;

6. 证书验证:

   • 其他参与者在与实体进行通信时,可以获取实体的数字证书;
   • 参与者使用证书颁发机构的公钥验证证书的签名，确保证书的完整性和真实性;

为什么说数字证书就能对通信方的身份进行验证呢？

数字证书能够对同新方身份进行验证,是因为数字证书采用了公钥加密和数字签名的技术,结合了非对称密钥加密算法的特性。

在数字证书中,证书颁发机构使用自己的私钥对证书进行签名,这个数字签名可以被其他参与这使用 CA 的公钥进行验证,通过验证数字签名,可以确保证书的完整性和真实性。

以下几个步骤是数字证书验证通信方身份的过程:

1. 获取证书: 通信方在通信开始之前,从对方获取数字证书;;
2. 提取公钥: 通信方从数字证书中提取对方的公钥;
3. 验证签名: 通信方使用证书颁发机构的公钥对证书中签名进行解密,得到签名的哈希值;
4. 哈希计算: 通信方对原始证书内容进行哈希计算,生成一个哈希值;
5. 比较哈希值: 通信方将解密得到的哈希值与自己计算的哈希值进行比较,如果两者相同,则证书的签名是有效的,证明证书没有被篡改;

通过以上验证步骤,通信方可以确保证书的完整性,并且确定证书的来源是可信的。这样同新方可以信任证书中关联的公钥,并使用公钥进行加密、身份认证或数字签名的验证。

总的来说，数字证书通过使用证书颁发机构的私钥对证书进行签名,提供了一种可信任的方式来验证证书的完整性和真实性。通过验证证书,同新方可以建立对对方身份的信任,并使用其公钥进行安全的通信操作。

HTTPS 的安全通信机制

当客户端与服务器之间建立安全连接时,HTTPS 使用以下过程来实现安全通信:

1. 客户端通过发送 Client Hello 报文开始 SSL 通信,报文中包含客户端支持的 SSL 的指定版本、加密组件列别;
2. 服务器可进行 SSL 通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL 版本以及加密组件。服务器加密组件内容是从接收到的客户端加密组件内筛选出来的;
3. 之后服务器发送 Certificate 报文,报文中包含公开的密钥证书;
4. 最后服务器发送 Server Hello Done 报文通知客户端,最初阶段的 SSL 握手协商部分结束;
5. SSL 第一次握手结束之后,客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master-secret 的随机密码串,该报文已用步骤 3 中的公开密钥进行加密;
6. 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密;
7. 客户端发送 Finished 报文,该报文包含连续至今全部报文的整体校验值,这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准;
8. 服务器同样发送 Change Cipher Spec 报文;
9. 服务器同样发送 Finished 报文;
10. 服务器和客户端的 Finished 报文交换完毕之后,SSL 连接就算建立完成。当然,通信会受 SSL 的保护。从此处开始进行应用层协议的通信,即发送 HTTP 请求;
11. 应用层协议通信,即发送 HTTP 响应;
12. 最后由客户端断开连接。断开连接时,发送 close_notify 报文;
13. 发送 TCP FIN 报文来关闭与 TCP 的通信;

在以上的这些流程中,应用程发送数据时会附加一种叫作 MAC (Message Authentication Code) 的报文摘要。MAC 能够查知报文是否篡改,从而保护报文的完整性。

接下来我们在看看整个 HTTPS 的通信的整个流程,如下图所示:

SSL 速度慢吗

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

SSL 的慢分两种,一种是指通信慢,另外一种指由于大量消耗 CPU 及内存等资源,导致处理速度变慢。

和使用 HTTP 相比,网络负载可能会变慢 2 到 100 倍,除去和 TCP 连接、发送 HTTP 请求-响应以外,还必须进行 SSL 通信,因此整体上处理通信量不可避免会增加。

另外一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和揭秘的运算处理,因此从结果上将,比起 HTTP 会更多地消耗服务器和客户端的硬件资源,导致负载增强。

为什么不一致使用 HTTPS

既然 HTTPS 那么安全可靠,那为何所有的 Web 网站不一直使用 HTTPS?

这里有几个原因可能导致不一致地使用 HTTPS,如下:

1. 成本：在某些情况下,使用 HTTPS 可能会导致更高的成本。获取有效的数字证书需要支付费用,尤其是在需要经过更高级别的身份验证和验证的情况下。此外,启用 HTTPS 可能需要更多的计算资源和带宽,这也可能增加运营成本;
2. 性能影响：加密和解密数据以及建立安全连接的过程会增加处理时间和资源消耗。对于某些网站或应用程序来说,这可能会对性能产生一定的影响。特别是对于大流量的网站或高并发的应用程序,可能需要更多的服务器资源来处理 HTTPS 请求,这可能会导致性能下降;
3. 兼容性问题：一些旧的设备、操作系统和浏览器可能不完全支持最新的加密协议和算法，导致与 HTTPS 的一致性问题。这可能会导致某些用户无法正常访问网站或应用程序，或者遇到安全警告。在某些情况下,为了保持兼容性,一些网站或应用程序可能会选择不全面使用 HTTPS;
4. 开发和维护复杂性：使用 HTTPS 需要对加密和证书管理等方面进行额外的开发和维护工作。这可能需要更多的时间和资源来确保正确的配置、证书更新和监控。对于一些开发团队或组织来说,可能需要额外的培训和专业知识来正确实现和维护 HTTPS;

尽管存在一些挑战和障碍,但随着网络安全意识的增强以及对用户隐私和数据安全的关注,越来越多的网站和应用程序正在转向全面使用 HTTPS。HTTPS 提供了保护用户隐私和数据安全的重要机制,可以防止数据被窃听、篡改和伪装。使用 HTTPS 是保护用户和组织数据的重要措施之一。

总结

HTTPS 的本质就是在 HTTP 的基础上添加了安全层,主要是通过他来加密和验证机制来保护通信数据的安全性和隐私性。它提供了保密性、完整性和身份验证的重要机制,使得数据在传输过程中得到了有效的保护,防止数据被窃听、篡改和伪装。

参考文献

• 书籍: 图解HTTP