HTTPS安全加密机制 ：
过程图示 ：
===>>>
过程 ：
1 ) 客户端（ 通常是浏览器 ） 向服务器发送加密通信的请求，然后连接
到服务端的 443 端口，这被叫做 ClientHello 请求 （ 请求加密通讯的
请求加密信息就叫做 Hello 不是一个字符串，这是一个动作 ）
客户端主要向服务器提供以下信息 ：
* 支持的协议版本，比如 TLS 1.0 版
* 支持的加密方法，比如 RSA 公钥加密
* 支持的压缩方法
2 ） 服务端回应 （ ServerHello ） 接收到信息之后给予客户端响应握手信
息，服务器的回应包含以下内容 ：
（ 第二步，那就是 服务器要回应客户端要求建立连接的请求，并
把服务器自己的证书 发给 客户端 。 来证明自己不是仿冒的，是
官方的）
* 确认使用的加密通信协议版本，比如 TLS 1.0 版本。 如
果 浏览器与服务器支持的版本不一致，服务器关闭加密通
信。
* 一个服务器生成的随机数 ， 稍后用于生成 “ 会话密钥 ”
* 确认使用的加密方法，这个加密算法一定是 client 发送给
server 加密算法的子集，比如 RSA 公钥加密。
* 服务器证书 ： 可以自己制作，也可以向组织申请。
区别就是自己颁发的证书需要客户端验证通过，才可以继
续访问，而使用受信任的公司申请的证书则不会弹出提示
页面，传送的证书其实就是公钥，只是包含了很多信息，
如证书的颁发机构，过期时间，服务端的公钥，第三方证
书认证（ CA - 即 安全认证中心，是个机构 )的签名等。
* 除此之外，如果服务器需要使用双向认证，就会再包含一
项请求，要求客户端提供 “ 客户端证书 ”。 比如，金融机
构往往只允许认证客户连入自己的网络，就会向正式客户
提供 USB 密钥，里面就包含了一张客户端证书 。
这个证书是服务器自己做的嘛，自己生成的嘛 ？？
===>>>
其实，还不是的。
就是你想证明你自己是你，还不行，你不能证明自己是自己；
举个例子，你想想，你的身份证是谁颁发的~？？
哈哈， 得由官方来证明， 官方就是 ： 公信力的部门，就是 CA - 安全认证中心
3 ) 客户端回应 ： 客户端收到服务器回应以后进行证书解析，首先会验
证证书是否有效，比如 颁发机构，过期时间等等，如
果发现异常，则会弹出一个警告框，提示证书存在问题
如果没有问题，那就生成一个随机数3（ 预主密钥），
接下来是通过随机值1，随机值2和随机值3组装 会话密
钥。 然后通过服务器端证书的公钥加密会话密钥，传送
加密信息，内容如下 ：
那客户端收到服务端发送的 证书 后，
首先进行的就是 证书的验证
主要的就是检查两个有效 （ 还有其它的，主要是下面俩，但是只要有一个出问题，那就会弹出弹窗，就不行 ~！）
第一 ： 颁发者是否有效，万一，有人冒充 CA 咋办 ？？ 是吧 ？？
第二 ： 检查下颁发时间是否过期了 ，就是看下证书是否在有效期呢 ~！~！
* 一个随机数 C 。 该随机数用服务器公钥加密，防止被窃听
* 编码改变通知，表示随后的信息都将用双方商定的加密方法
和密钥发送。
* 客户端握手结束通知，表示客户端的握手阶段已经结束。
这一项同时也是前面发送的所有内容的 HASH 值，用来供
服务器校验。
4 ) 服务器的最后回应 ：
服务器收到客户端的第三个随机数 预主密钥 之后，计算生成
本次会话所用的 “ 会话密钥 ” （ 对称密钥 ） 。
然后，向客户端最后发送下面信息 ：
* 编码改变通知，表示随后的信息都将双方商定的加密
方法和密钥发送。
* 服务器握手结束通知，表示服务器的握手阶段已经结
束。 这一项同时也是前面发送的所有内容的 HASH 值
用来供客户端校验。
至此，整个握手阶段全部结束。 接下来，客户端与服务器进入加密通信，就完
全是使用普通的 HTTP 协议，只不过会用 “ 会话密钥 ” 加密内容。
大致分为三个阶段 ：
* 1 ) 2） 认证服务器 ： 浏览器内置一个受信任的 CA 机构列表，并保存了这
些 CA 机构的证书。
第一阶段会提供 经 CA 机构认证颁发的服务器证书，
如果认证该服务器证书的 CA 机构，存在于浏览器的
受信任 CA 机构列表中，并且服务器证书中的信息与当
前正在访问的网站（ 域名 ） 一致，那么，浏览器就认
为服务端是可信的，并从服务器证书中取得服务器公
钥，用于后续流程。
否则，浏览器将提示用户，根据用户的选择，决定是否
继续。
当然，我们可以管理这个受信任 CA 机构列表，添加
我们想要信任的 CA 机构，或者 移除我们不信任的 CA
机构。
* 3) 4 ) 协商会话密钥 ： 客户端在认证完服务器，获得服务器的公钥之后， 利
用该公钥与服务器进行加密通信，协商出两个会话密
钥，分别是用于加密客户端往服务端发送数据的客户
端会话密钥，用于加密服务端往客户端发送数据的服
务端会话密钥。
在已有服务器公钥，可以加密通讯的前提下，还要协
商两个对称密钥的原因，是因为非对称加密相对复杂
度更高，在数据传输过程中，使用对称加密，可以节
省计算资源。 另外，会话密钥是随机生成，每次协
商都会有不一样的结果，所以安全性也比较高。
* 加密通讯 ： 此时，客户端服务器双方都有了本次通讯的会话密钥，之后传输
的所有 Http 数据，都会通过会话密钥加密。 这样网路上的其它
用户，将很难窃取和篡改客户端和服务端之间传输的数据，从而
保证了数据的私密性和完整性。
对上示过程进行总结 ：
首先 服务器 向客户端 提交 HTTPS 的连接申请，
然后 服务端发送客户端证书，来证明 服务端的官方真实性，
客户端 收到 服务端的证书之后，会把证书拿到本机存储的受信
任颁发者列表里面检查是不是官方发的，验证下证书的真实性。
客户端认可证书后，客户端和服务端就会 协商 将来发送明文时加密的
密钥、算法、位数等一系列问题；
客户端，服务端 协商成功后，就可以进行通讯了 ~！！
那提出一个问题，上述整个流程中，用了几种加密算法呀 ？？
===>>>
答案是 ： 两种
这两类 分别是 对称加密 和 非对称加密 两种 加密算法 。
就是你要验证服务器的真实性，就得用公钥加密算法（ 非对称
加密 ）就是 有公钥 有私钥 。
但是 ，只要真实性验证成功后，剩下的交流 （ 你发给我 ，我
发给你，就是 客户端 和 服务端 两个相互交流） 这个之间的信
息不是还得加密嘛，这个加密算法就得 必须用 对称加密 。
因为，对称加密有个最大优点就是 速度快 ~！！！
===>>>
再总结， HTTPS 一共用了两种加密方式 ：
第一 ： 公钥加密算法 又称为非对称加密算法，
主要是用来验证服务端的网站真实性的~！！
第二 ： HTTPS 客户端 和 服务端 两个之间的信息交流
主要是 对称加密算法 以此来保证 数据的安全性的 ~！！
3194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
