你真的了解HTTPS协议吗

前言

在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。本文即将带大家来了解这些。

任何事物都有两面性，为了满足HTTP协议的快，但导致了它有如下的不足：

通信采用明文（不加密），导致内容可能被窃取
不验证通信方的身份，可能遭到伪装
无法证明报文的完整性，可能遭到纂改
........

针对这些问题，我们一一的来解决：

一、HTTP问题的解决方案

1.1、防止通信时的被窃听

目前，最常用的防止窃听的机制是：

通信的加密
内容的加密

1.1.1通信的加密

HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或 TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。

用 SSL建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

1.1.2内容的加密

关于内容的加密是一种将参与通信的内容本身加密的方式。

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

为了做到内容的加密，我们则需要满足一个前提：请求方和接收方都要有相同的加密或解密的机制。

1.2、验证对方身份信息

由于我们知道：HTTP 协议中的请求和响应不会对通信方进行确认。

我们可以采用SLL中的颁布证书来实现验证对方身份。

先来说说证书是什么？

证书是由可信第三方颁发，确保服务器和客户端的真实身份。
并且伪造证书难度大，验证证书可确认通信对方的真实性，增强安全性，保护用户信息免遭泄露。
同时客户端证书同样用于个人身份验证及网站认证，提高交易可靠性。

1.3、报文的完整性

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

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

但是我们可以通过使用一些方法来解决这个问题：

MD5和SHA-1：可以通过在HTTP头部使用MD5或SHA-1散列值作为一种简单的方式来校验内容完整性，但这两种方法因安全性问题（特别是SHA-1已被证明存在碰撞攻击的风险）现在不建议单独用于安全认证。
ETag和If-Match/If-None-Match：HTTP协议中的ETag是一种实体标签，服务器可以使用它来标识特定版本的资源。客户端在后续请求中可以携带If-Match或If-None-Match头部，服务器根据这些头部验证资源是否发生了改变，间接地确认报文的完整性。
Content-MD5：虽然不常用，HTTP规范中曾定义过一个名为Content-MD5的头部字段，用于包含请求或响应主体的MD5摘要。然而，由于MD5的弱点和Content-MD5在实际应用中的局限性，这种方法很少被采用。

通过介绍完上述的解决方法，其实我们的Https就是这几种的结合体：

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

为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）。

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

通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL协议这层外壳的 HTTP。在采用 SSL后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

2.1、相互交换密钥的公开密钥加密技术（加密）

在介绍SSL前，了解其使用的公开密钥加密至关重要。这种加密技术公开加密算法，但密钥保密，确保安全。加密解密需密钥，密钥丢失意味着安全防线崩溃，SSL以此为基础增强通信安全。

2.1.1、共享密钥加密

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

上图引用《图解HTTP》

但是这个共享密钥加密会有一个问题，就是怎么让对方拥有相同的密钥呢，在转发的时候，如果通信被监听了，那么可能落到攻击者的手中，就失去了加密的意义。所以就引出了下面这种新的方法。

2.1.2、使用两把密钥的公开密钥加密

先给出这个的概念：

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

总结上述的：就是一个私钥，是留给自己用来解密的，一个公钥，给别人发送加密的。

这个有些书上并没有将的很清楚，我在这里举一个例子来演示非对称加密的基本原理：

密钥对生成：每个参与通信的个体（如A）都会生成一对密钥，一个称为公钥，可以公开分享给任何人；另一个称为私钥，必须严格保密，不能泄露给他人。

加密过程：当其他人（比如B）想要向A发送一条私密信息时，B会使用A已经公开的公钥对信息进行加密。由于非对称加密算法的设计，一旦使用公钥加密，就只能用对应的私钥来解密。

解密过程：A收到B用其公钥加密的信息后，就可以用自己保有的私钥来解密，获取原始信息。这样即使信息在传输过程中被截获，没有相应的私钥，信息仍然是安全的，无法被破解。

2.1.3、HTTPS采用的混合加密

先来介绍一下这种方式：

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。

具体的步骤：

客户端在获取到服务端的公钥后，会利用这个公钥来安全地生成一个会话密钥（也称为对称密钥）。这个过程通常涉及某种形式的密钥交换协议，确保即使在不安全的通道上协商该密钥，潜在的攻击者也无法得知这个密钥的内容。
一旦客户端和服务端都独立计算出了相同的会话密钥，之后的通信就会使用这个会话密钥进行加密和解密。由于会话密钥是对称的，这意味着用它加密的数据可以用同一个密钥解密，这对比非对称加密（如RSA）在性能上更有优势，适合大量数据的快速加解密处理。

证明公开密钥正确性的证书（认证）

公开密钥加密面临的一个挑战在于确保公钥的真实性。当与服务器建立加密通信时，如何验证接收到的公钥确属目标服务器颁发，是一个关键问题。因为在传输过程中，公钥有可能被黑客拦截替换，导致信息流向了错误或恶意的源头，这种攻击称为中间人攻击。因此，需要一种机制来保证公钥的真实性和完整性，这是公开密钥加密体系的一个重要考量点。

为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。可以将CA类比成中介，通过中介来标识互相身份。

2.2、HTTPS 的安全通信机制（完整性）

要了解HTTPS通信机制，我们就要先了解一下HTTPS的通信过程：

初始请求：客户端（如浏览器）通过TCP连接向服务器发起HTTPS请求，指定要访问的HTTPS网址。
服务器证书传输：服务器回应客户端请求，发送其数字证书。这包括服务器的公钥、证书颁发机构信息、证书有效期及服务器标识等。
证书验证：客户端验证服务器证书的合法性，包括检查证书是否过期、是否由受信任的CA签发、以及证书中的域名是否与正在访问的域名匹配。
密钥交换：验证证书无误后，客户端生成一个会话密钥（对称密钥），用于接下来通信的加密，并使用服务器的公钥加密这个会话密钥，然后发送给服务器。
密钥解密与会话建立：服务器使用其私钥解密得到会话密钥，至此，客户端和服务器双方都拥有相同的会话密钥，可以开始进行加密通信。
加密通信：之后的通信内容都使用这个会话密钥进行对称加密，确保数据的保密性和完整性。客户端发送加密的HTTP请求，服务器回复加密的HTTP响应。
通信结束：当一次请求-响应周期结束后，TCP连接可以保持打开以服务于额外的请求，或者根据配置和需求关闭连接。

在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。

2.3、HTTPS的一些缺点

前文也说了，事物都要两面性，说了HTTPS的好，也有它的坏。也可以将这个问题说成，既然HTTPS有这么好，为啥不一直使用它？

资源消耗：HTTPS连接需要更多的计算资源来处理加密和解密过程，这可能会对服务器和客户端（尤其是资源有限的设备）造成额外的性能负担。
成本问题：虽然现在获取SSL/TLS证书的成本已经大大降低，甚至可以免费获得基本的证书，但对于大规模部署或需要高级特性的网站来说，仍然可能涉及成本问题，包括证书管理、运维等。
历史遗留系统：一些老旧的系统或硬件可能不支持HTTPS，或者升级到HTTPS需要大量的工作和测试，这在某些情况下可能会阻碍HTTPS的采用。
非敏感信息传输：对于一些只传输非敏感信息的网站或应用（如纯信息展示的静态网站），使用HTTPS可能被认为是过度设计，因为没有严格的数据保护需求。

总的来说，虽然HTTPS是推荐的最佳实践，特别是对于涉及用户数据和敏感操作的网站，但在实际应用中，是否使用HTTPS还需权衡安全需求、成本、性能和技术能力等多种因素。随着技术进步和网络安全意识的提高，越来越多的网站和服务正逐步转向全站HTTPS。