https产生原因

由于http是明文传递数据，如果在客户端和服务器端设置个代理服务，完全可以拿到通信数据，https可以保证，通信是和真正的服务器通信（可能也是代理，但是没有意义，代理服务器无法拿到通信数据），https主要要保证怎么样传输数据是最安全的，及即使中间有个侵入的代理服务，代理服务也拿不到数据信息
需要解决两个问题：

• 如何保证与我通信的机器是真正的服务器？
  通过握手来保证是真正的服务器

• 即使代理转发服务器的消息，如何保证消息内容代理服务器是无法解析呢？
  在握手过程中商量好加密算法来保证无法解析

https通信过程

1、客户端请求服务端，携带随机参数，以及包含客户端支持的SSL指定版本,加密组件列表(所使用的加密算法 密钥长度等)

Handshake Protocol: Client Hello
Version: TLS 1.2 (0x0303)
Random: 1cbf803321fd2623408dfe…
Cipher Suites (17 suites)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

2、服务端选择算法，将证书返回（证书中包含公钥），以及选择的加密算法，以及一个随机数，以及一个用私钥加密的签名

• 随机选择加密算法返回，以及服务端的一个随机数

Handshake Protocol: Server Hello
Version: TLS 1.2 (0x0303)
Random: 0e6320f21bae50842e96…
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

• 返回证书信息以及私钥加密信息，以及算法的参数

Handshake Protocol: Server Key Exchange
EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: x25519 (0x001d)
Pubkey: 3b39deaf00217894e...
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature: 37141adac38ea4...

至此客户端和服务器通过明文共享了三个信息：Client Random、Server Random 和 Server Params。

3、客户端进行证书的验证，同时将证书里的公钥解析，将字符串解密，判断公钥是否合法

• 走证书链逐级验证，确认证书的真实性，再用证书公钥验证签名，就确认了服务器的身份
  4、客户端拿到了密钥交换算法的两个参数（Client Params、Server Params），就用 ECDHE 算法一阵算，算出了一个新的东西，叫“Pre-Master”，其实也是一个随机数，通过公钥加密将随机数发送到服务端，现在一共有三个随机数了

5、客户端和服务器手里有了三个随机数：Client Random、Server Random 和 Pre-Master。用这三个作为原始材料，就可以生成用于加密会 话的主密钥，叫“Master Secret”

6、握手就快结束了。客户端发一个“Change Cipher Spec”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证

7、服务器也是同样的操作，发“Change Cipher Spec”和“Finished”消息，双方都验证加密解密 OK，握手正式结束，后面就收发被加密的 HTTP 请求和响应了

image.png

问题

为什么不直接用公钥和私钥加密传输数据？
非对称加密性能太差
第三方机构是怎么颁发证书的？

• 这个“第三方”就是我们常说的 CA（Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）
  浏览器被调包是不是也不安全？
  是的。比如解密后直接将信息传到另一台服务器

客户端如何验证证书的合法性？

• 首先浏览器读取证书中的证书所有者、有效期等信息进行校验，校验证书的网站域名是否与证书颁发的域名一致，校验证书是否在有效期内
• 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
  如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
  如果找到，那么浏览器就会从操作系统中取出颁发者CA 的公钥(多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥)，然后对服务器发来的证书里面的签名进行解密
• 浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比，对比结果一致，则证明服务器发来的证书合法，没有被冒充
  （证书是CA颁发的，证书里面会有签名，签名是用CA的私钥加密的，加密的明文是证书通过hash算法算出来的Hash值）

公钥、私钥、数字证书的关系是什么？

• 公钥是公开的，不需要保密，而私钥是由证书持有人自己特有，并且必须妥善保管和注意保密。
• 数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机构的公章）后形成的一个数字文件