1. HTTPS

HTTP 由于是明文传输，所以安全上存在以下三个风险：

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

由图可见，HTTP 在传输数据的过程中，所有的数据都是明文传输，自然没有安全性可言，特别是一些敏感数据，比如用户密码和信用卡信息等，一旦被第三方获取，后果不堪设想。这里可能有人会说，我在前端页面对敏感数据进行加密不就行了，比如 MD5 加盐加密。这么想就太简单了。首先 MD5 并不是加密算法，其全称是 Message Digest Algorithm MD5，意为信息摘要算法，是一种不可逆的哈希算法，也就是说经过前端 MD5 处理过的数据在服务器端是无法复原的。这里以密码举例，前端把用户密码通过 MD5 进行处理，并把得到的哈希值发送给服务器，服务器由于无法复原密码，就会直接用这个哈希值处理用户请求。所以第三方在获取这个哈希值后，可以绕过前端登录页面直接访问服务器，造成安全问题

总之 MD5，SHA-1 之类的哈希算法并不能让 HTTP 变得更安全。要想让 HTTP 更安全，只能使用真正的加密算法，因为加密算法可以用密钥加密或还原数据，只要确保密钥不被第三方获取，那就能确保数据传输的安全了。而这正是 HTTPS 的解决方案。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议。

可以很好的解决了上述的风险：

信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

可见，只要自身不做恶，SSL/TLS 协议是能保证通信是安全的。

HTTPS 是如何解决上面的三个风险的？

混合加密的方式实现信息的机密性，解决了窃听的风险。
摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
将服务器公钥放入到数字证书中，解决了冒充的风险。

混合加密

通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法

摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

数字证书

客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

这就存在些问题，如何保证公钥不被篡改和信任度？

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

2. 对称加密

从图中可以看出，被加密的数据在传输过程中是无规则的乱码，即便被第三方截获，在没有密钥的情况下也无法解密数据，也就保证了数据的安全。但是有一个致命的问题，那就是既然双方要使用相同的密钥，那就必然要在传输数据之前先由一方把密钥传给另一方，那么在此过程中密钥就很有可能被截获，这样一来加密的数据也会被轻松解密。那如何确保密钥在传输过程中的安全呢？这就要用到非对称加密了。

3. 非对称加密

非对称加密，顾名思义，就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公钥对外公开；得到该公钥的乙方使用公钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的私钥对加密后的信息进行解密。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。常用的非对称加密算法是 RSA 算法。其优缺点如下：

优点：算法公开，加密和解密使用不同的钥匙，私钥不需要通过网络进行传输，安全性很高。
缺点：计算量比较大，加密和解密速度相比对称加密慢很多。

由于非对称加密的强安全性，可以用它完美解决对称加密的密钥泄露问题，效果图如下：

在上述过程中，客户端在拿到服务器的公钥后，会生成一个随机码 (用 KEY 表示，这个 KEY 就是后续双方用于对称加密的密钥)，然后客户端使用公钥把 KEY 加密后再发送给服务器，服务器使用私钥将其解密，这样双方就有了同一个密钥 KEY，然后双方再使用 KEY 进行对称加密交互数据。在非对称加密传输 KEY 的过程中，即便第三方获取了公钥和加密后的 KEY，在没有私钥的情况下也无法破解 KEY (私钥存在服务器，泄露风险极小)，也就保证了接下来对称加密的数据安全。而上面这个流程图正是 HTTPS 的雏形，HTTPS 正好综合了这两种加密算法的优点，不仅保证了通信安全，还保证了数据传输效率。

非对称加密有两个密钥，一个是公钥，另一个是私钥。一般来说，公钥用来加密，这时密文只能用私钥才能解开。

那么，当客户端发起连接请求，服务端将公钥传输过去，客户端利用公钥加密好信息，再将密文发送给服务端，服务端里有私钥可以解密。

但是，当服务端要返回数据，如果用公钥加密，那么客户端并没有私钥用来解密，而如果用私钥加密，客户端虽然有公钥可以解密。但这个公钥之前就在互联网上传输过，很有可能已经有人拿到，并不安全，所以这一过程只用非对称加密是不能满足的。

注意，严格来讲，私钥并不能用来加密，只能用作签名使用，这是由于密码学中生成公钥私钥时对不同变量的数学要求是不同的。

因此公钥私钥抵抗攻击的能力也不同，在实际使用中不可互换。

只有一组公钥私钥只能保证单程的加解密，那么如果我们准备两组公钥私钥呢，是不是可以解决这个问题？

来看下面这个过程：

服务端有非对称加密的公钥 A1，私钥 A2。
客户端有非对称加密的公钥 B1，私钥 B2。
客户端向服务端发起请求，服务端将公钥 A1 返回给客户端。
浏览器收到公钥 A1，将自己保存的公钥 B1 发送给服务端。
之后浏览器所有向客户端发送的数据，使用公钥 B1 加密，客户端可以使用私钥 B2 解密。
客户端所有向服务端发送的数据，使用公钥 A1 加密，服务端可以使用私钥 A2 解密。

此时，两条传输方向的数据都经过非对称加密，都能保证安全性，那么为什么不采用这种方案呢？

最主要的原因是非对称加解密耗时要远大于对称加解密，对性能有很大损耗，大家的使用体验很差。

所以，HTTPS才最终选用了上文介绍到非对称加密+对称加密的方案，再复习一下：

服务端有非对称加密的公钥 A1，私钥 A2。
客户端发起请求，服务端将公钥 A1 返回给客户端。
客户端随机生成一个对称加密的密钥 K，用公钥 A1 加密后发送给服务端。
服务端收到密文后用自己的私钥 A2 解密，得到对称密钥 K，此时完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题。
之后双方通信都使用密钥 K 进行对称加解密。

4. HTTPS连接

HTTPS 的整个通信过程可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为非对称加密和对称加密两个阶段。具体流程按图中的序号讲解。

客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书，证书是需要申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是要钱的，安全级别越高价格越贵)。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。
客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。
双方使用对称加密愉快地传输所有数据。

用 wireshark 抓包，观察 HTTPS 连接建立的过程。

首先是 TCP 三次握手，然后客户端（浏览器）发起一个 HTTPS 连接建立请求，客户端先发一个 Client Hello 的包，然后服务端响应一个 Server Hello。

接着再给客户端发送它的证书，然后双方经过密钥交换，最后使用交换的密钥加行加解密数据。

SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

SSL/TLS 的「握手阶段」涉及四次通信，可见下图：

SSL/TLS 协议建立的详细流程：

1. ClientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来，因为此时还没有发生 HTTP 请求。

2. SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

服务端选中的加密套装叫 TLSECDHERSAWITHAES128GCM_SHA256，这一串的意思是：

密钥交换使用 ECDHE
证书签名算法 RSA
数据加密使用 AES 128 GCM
签名校验使用 SHA256

服务给客户端发来了 4 个证书：

第一个证书的公用名（common name）就是我们当前访问的域名 developer.mozilla.org。

如果公用名是 *.mozilla.org 的话那么这个证书便能给 mozilla.org 的所有二级子域名使用。

第二个证书是第一个证书的签发机构（CA）的证书，它是 Amazon，也就是说 Amazon 会用它的私钥给 developer.mozilla.org 进行签名。

依此类推，第三个证书会给第二个证书签名，第四个证书会给第三个证书签名，并且我们可以看到第四个证书是一个根（Root）证书。

一个证书里面会有什么东西呢，我们可以展开第一个证书看一下，如下图所示：

证书包含三部分内容：

tbsCertificate（to be signed certificate）待签名证书内容
证书签名算法
CA 给的签名

也就是说 CA 会用它的私钥对 tbsCertificate 进行签名，并放在签名部分。为什么证书要签名呢？签名是为了验证身份，这部分放在后面讲。

3.客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

总结一下TLS的连接建立过程

客户端向服务端发送 Client Hello 消息，其中携带客户端支持的协议版本、加密算法、压缩算法以及客户端生成的随机数；
服务端收到客户端支持的协议版本、加密算法等信息后；
1. 向客户端发送 Server Hello 消息，并携带选择特定的协议版本、加密方法、会话 ID 以及服务端生成的随机数；
2. 向客户端发送 Certificate 消息，即服务端的证书链，其中包含证书支持的域名、发行方和有效期等信息；
3. 向客户端发送 Server Key Exchange 消息，传递公钥以及签名等信息；
4. 向客户端发送可选的消息 CertificateRequest，验证客户端的证书；
5. 向客户端发送 Server Hello Done 消息，通知服务端已经发送了全部的相关信息；
客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后，验证服务端的证书；
1. 向服务端发送 Client Key Exchange 消息，包含使用服务端公钥加密后的随机字符串，即预主密钥（Pre Master Secret）；
2. 向服务端发送 Change Cipher Spec 消息，通知服务端后面的数据段会加密传输；
3. 向服务端发送 Finished 消息，其中包含加密后的握手信息；
服务端收到 Change Cipher Spec 和 Finished 消息后；
1. 向客户端发送 Change Cipher Spec 消息，通知客户端后面的数据段会加密传输；
2. 向客户端发送 Finished 消息，验证客户端的 Finished 消息并完成 TLS 握手；

TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥，通信的双方可以使用这个对称的密钥加密消息防止中间人的监听和攻击，保证通信的安全。

5. CA机构

依然考虑中间人攻击的情况，非对称加密的算法都是公开的，所有人都可以自己生成一对公钥私钥。

当服务端向客户端返回公钥 A1 的时候，中间人将其替换成自己的公钥 B1 传送给浏览器。

而浏览器此时一无所知，傻乎乎地使用公钥 B1 加密了密钥 K 发送出去，又被中间人截获。

中间人利用自己的私钥 B2 解密，得到密钥 K，再使用服务端的公钥 A1 加密传送给服务端，完成了通信链路，而服务端和客户端毫无感知。

出现这一问题的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的。为了解决这个问题，互联网引入了一个公信机构，这就是 CA。

服务端在使用 HTTPS 前，去经过认证的 CA 机构申请颁发一份数字证书，数字证书里包含有证书持有者、证书有效期、公钥等信息。

服务端将证书发送给客户端，客户端校验证书身份和要访问的网站身份确实一致后再进行后续的加密操作。

但是，如果中间人也聪明一点，只改动了证书中的公钥部分，客户端依然不能确认证书是否被篡改，这时我们就需要一些防伪技术了。

前面说过，非对称加密中一般公钥用来加密，私钥用来解密，虽然私钥加密理论上可行，但由于数学上的设计这么做并不适合，那么私钥就只有解密这个功能了么？

私钥除了解密外的真正用途其实还有一个，就是数字签名，其实就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败。

具体过程如下：

CA 机构拥有自己的一对公钥和私钥。
CA 机构在颁发证书时对证书明文信息进行哈希。
将哈希值用私钥进行加签，得到数字签名。

明文数据和数字签名组成证书，传递给客户端：

客户端得到证书，分解成明文部分 Text 和数字签名 Sig1。
用 CA 机构的公钥进行解签，得到 Sig2（由于 CA 机构是一种公信身份，因此在系统或浏览器中会内置 CA 机构的证书和公钥信息）。
用证书里声明的哈希算法对明文 Text 部分进行哈希得到 H。
当自己计算得到的哈希值 T 与解签后的 Sig2 相等，表示证书可信，没有被篡改。

这时，签名是由 CA 机构的私钥生成的，中间人篡改信息后无法拿到 CA 机构的私钥，保证了证书可信。

注意，这里有一个比较难以理解的地方，非对称加密的签名过程是，私钥将一段消息进行加签，然后将签名部分和消息本身一起发送给对方。

收到消息后对签名部分利用公钥验签，如果验签出来的内容和消息本身一致，表明消息没有被篡改。

在这个过程中，系统或浏览器中内置的 CA 机构的证书和公钥成为了至关重要的环节，这也是 CA 机构公信身份的证明，如果系统或浏览器中没有这个 CA 机构，那么客户端可以不接受服务端传回的证书，显示 HTTPS 警告。

实际上 CA 机构的证书是一条信任链，A 信任 B，B 信任 C，

5.1. 身份验证

我们先来看一下 tbsCertificate 里面有什么内容，如下图所示：

它里面包括了证书的公钥、证书的适用公用名、证书的有效期还有它的签发者等信息。Amazon 的证书也具备上述结构，我们可以把 Amazon 证书的公钥拷出来，如下图所示：

中间有一些填充的数字，用灰色字表示。可以看到N通常是一个很大的整数（二进制 2048 位），而 e 通常为 65537。然后我们用这个 CA 的公钥对 mozilla.org 的证书签名进行解密，方法和上面的类似：

取解密后的数字 decrypted 的十六进制的末 64 位，即为二进制 256 位的 SHA 哈希签名。

接下来我们手动计算一下 tbsCertificate 的 SHA256 哈希值，方法是在 wireshark 里面把 tbsCertificate 导出一个原始二进制文件：

然后再使用 openssl 计算它的哈希值，如下所示：

liyinchengs-MBP:https liyincheng$ openssl dgst -sha256 ~/tbsCertificate.binSHA256(/Users/liyincheng/tbsCertificate.bin)= 5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d

我们发现手动计算的哈希值和加密后的证书里的哈希值一致！说明只有知道了 Amazon 私钥的人才能正确地对 mozilla.org 的证书签名，因为公私钥是唯一匹配的。

因此我们验证了第一个证书 mozilla.org 确实是由第二个证书 Amazon 签发的，使用同样的方式，我们可以验证 Amazon 是由第三个签发的，第三个是由第四个根证书签发。

并且第四个证书是根证书，它是内置于操作系统的（通过 Mac 的 keychain 工具可以查看）：

假如 Hacker 通过 DNS 欺骗之类的方式把你访问的域名指向了他的机器，然后他再伪造一个证书。

但是由于根证书都是内置于操作系统的，所以它改不了签名的公钥，并且它没有正确的私钥，只能用自己的私钥，由于公私钥不配对，很难保证加解密后的信息一致。

或者直接把浏览器拿到的证书搬到他自己的服务器？这样再给浏览器发的证书便是一模一样，但是由于他不知道证书的私钥，所以无法进行后续的操作，因此这样是没有意义的。

这个就是 HTTPS 能够验证身份的原理。另外一个例子是 SSH，需要手动验证签名是否正确。

例如通过打电话或者发邮件等方式告知服务器的签名，与自己算的证书的签名是否一致，如果一致说明证书没有被篡改过（如证书的公钥没有被改为 Hacker 的公钥）：

上面展示的便是自己手动计算的值，拿这个值和之前的值进行比较是否相等便可知发过来的证书是否被修改过。

那么，为什么不直接使用 RSA 的密钥对进行加密数据？因为 RSA 的密钥对数值太大，不太合适频繁地加解密数据，所以需要更小的密钥。

另一个原因是服务端没有浏览器或者客户端的密钥，无法向浏览器发送加密的数据（不能用自己的私钥加密，因为公钥是公开的）。所以需要进行密钥交换。

5.2. 密钥交换

密钥交换的方式有两种：RSA 和 ECDHE，RSA 的方式比较简单，浏览器生成一把密钥，然后使用证书 RSA 的公钥进行加密发给服务端，服务再使用它的密钥进行解密得到密钥，这样就能够共享密钥了。

它的缺点是攻击者虽然在发送的过程中无法破解，但是如果它保存了所有加密的数据，等到证书到期没有被维护之类的原因导致私钥泄露，那么它就可以使用这把私钥去解密之前传送过的所有数据。

而使用 ECDHE 是一种更安全的密钥交换算法。如下图所示，双方通过 ECDHE 进行密钥交换：

ECDHE 的全称是 Elliptic Curve Diffie–Hellman key Exchange 椭圆曲线迪非-赫尔曼密钥交换，它是对迪非-赫尔曼密钥交换算法的改进。

这部分直接阅读参考资料https://mp.weixin.qq.com/s/e_fT-EbsVjDbTeuRAOE4Cg

6. 参考资料

https://www.jianshu.com/p/c1d6a294d3c0

https://mp.weixin.qq.com/s/bUy220-ect00N4gnO0697A

https://mp.weixin.qq.com/s/vCaYFSUxYRVfKHx6btDjqQ

https://segmentfault.com/a/1190000021494676

https://mp.weixin.qq.com/s/7rgovxQWJlE4hlzDTdhWGQ

HTTPS

最后更新：2018-12-21