HTTPS链接完整过程
国密 私钥 得到 公钥 私钥加密公钥能解密吗_hochie的技术博客_51CTO博客
上面是介绍很详细的博客，下面节选经典的部分
非加密算法的缺点：
1.一次完全 TLS 握手，密钥交换时的非对称解密计算量占整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
2.非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是 2048 位，意味着待加密内容不能超过 256 个字节。
数字证书有两个作用：
1.身份授权。确保浏览器访问的网站是经过 CA 验证的可信任的网站。
2.分发公钥。每个数字证书都包含了注册者生成的公钥。在 SSL 握手时会通过 certificate 消息传输给客户端。
CA 签发几点说明：
1.数字签名签发和校验使用的密钥对是 CA 自己的公私密钥，跟证书申请者提交的公钥没有关系。
2.数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。
3.现在大的 CA 都会有证书链，证书链的好处一是安全，保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销，即如何证书出现问题，只需要撤销相应级别的证书，根证书依然安全。
4.根CA 证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
5.怎样获取根 CA 和多级 CA 的密钥对？它们是否可信？当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的公钥都默认装到了浏览器或者操作系统环境里。比如 firefox 就自己维护了一个可信任的 CA 列表，而 chrome 和 IE 使用的是操作系统的 CA 列表。
SSL握手协议
Session ticket的工作流程如下：
1.客户端发起client hello，拓展中带上空的session ticket TLS，表明自己支持session ticket。
2.服务器在握手过程中，如果支持session ticket，则发送New session ticket类型的握手报文，其中包含了能够恢复包括主密钥在内的会话信息，当然，最简单的就是只发送master key。为了让中间人不可见，这个session ticket部分会进行编码、加密等操作。
3.客户端收到这个session ticket，就把当前的master key和这个ticket组成一对键值保存起来。服务器无需保存任何会话信息，客户端也无需知道session ticket具体表示什么。
4.当客户端尝试会话复用时，会在client hello的拓展中加上session ticket，然后服务器收到session ticket，回去进行解密、解码能相关操作，来恢复会话信息。如果能够恢复会话信息，那么久提取会话信息的主密钥进行后续的操作。
Certificate
服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
Server Key Exchange
仅用于（服务器）证书消息没有包含足够的信息来建立预置密钥（pre-master key）的情况。如短暂的DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。
Certificate Request
服务端要求客户端上报证书，这一步是可选的，需要双向认证时要用到。
Server Hello Done
Server Hello Done 通知客户端 Server Hello 过程结束。
客户端回应
客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验，以浏览器为例说明如下：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验 （2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发 （3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。 （4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密 （5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比 （6）对比结果一致，则证明服务器发来的证书合法，没有被冒充 （7）此时浏览器就可以读取证书中的公钥（服务端的公钥），用于后续加密了。 （8）客户端再生成一个随机数 Random3，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
至于为什么一定要用三个随机数，来生成"会话密钥"，总结来说就是为了增加随机性，不容易被暴力破解。SSL协议不信任每个主机都能生成完全随机的随机数。同时需要注意前两个随机数都是明文传输的，窃听者是可以轻易获取到的，只有最后一个 PreMaster Secret 是加密传输的，只有拥有服务器私钥才能解密，一旦 PreMaster Secret 泄露，那么本次通信就就完全可被破解了。
Client Key Exchange
上面客户端根据服务器传来的公钥生成了 pre-master Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。
Change Cipher Spec
这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。
Change Cipher Spec 有必要么？ Change Cipher Spec 用来通知对端，开始启用协商好的密钥做对称加密，内容只有1个字节。 这个协议是冗余的，在TLS 1.3里面直接被删除了。
Encrypted Handshake Message
这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。
Change Cipher Spec
这一步是服务端通知客户端后面再发送的消息都会使用加密，也是一条事件消息。
Encrypted Handshake Message
这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。
总结 SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。 （2） 双方协商生成"对话密钥"（session key）。（只有双方知道，一共需要三个随机数） （3） 双方采用"对话密钥"进行加密通信。（不直接用公钥加密，因为公钥加密计算量太大，服务器的公钥和私钥只用于加密和解密-对话密钥（确切的来说是第三个随机数），无其他作用。） 关于随机数的介绍。