1. https工作在http和tcp层之间，添加了加密逻辑，让整个传输过程更安全，不会被黑客操纵和截取明文报文。https的握手过程是在tcp三次握手之后额外添加2次RTT来完成。
2. 这中间涉及到对称加密和非对称加密，使用非对称加密（RSA代表）协商出对称加密（AES代表）的密钥，主要是因为非对称加密效率低，占用cpu太多时间，通信成本高。
3. 我理解的握手过程大致是下面这样的。
（a）Browse端先发一个client hello，这里面包含（支持的对称加密，非对称加密套件，client random）给server端，服务端返回选择出来的对称和非对称加密套件，server random，server的公钥，CA证书，以及这个证书的数字签名（相当于房管局给房产证上盖的那个鲜章，这里是一个加密后的字符串），这个签名是怎么生成的呢？拿出server的公钥，通过摘要算法得到一个Hash值，然后用CA的私钥对这个Hash值加密就得到这个数字签名。
（b）浏览器收到server的内容后，第一步验证CA证书的有效性，这里会通过CA证书链路一级一级的往Root CA确认，Root CA权威机构全球那几家会事先内置到操作系统中。若最终判定证书合法，且还在有效期，再通过server的公钥算出一个Hash值， 然后用CA的公钥对返回来的数字签名解密出另一个Hash值，判断两个Hash值是否相等，若相等则再生成第三个随机数Pre-Master，然后取出server端返回来的公钥对Pre-Master加密后传输给server端。
（c）server端收到加密后的pre-master，用自己的私钥解密出明文的pre-master，此时就可以通过client-random，server-random，pre-master这3个随机数，两端通过相同的算法对着3个随机数生成后续数据传输的对称加密密钥。
4. 注意上述CA证书验证过程，实际上只验证了server端的公钥合法性，只是为了证明server是我们想要请求的server，验证了它公钥的有效性，并没有验证客户端的合法性，如果要验证客户端，还可能需要更多的流程，像有的银行要求用户安装U盾，最终目的是为了验证客户端的合法的。
5. 目前主要使用的协议版本是TLS1.2， 未来http3 是TLS1.3， hash摘要算法使用的是SHA2， 已经逐渐淘汰使用有漏洞的SHA1， MD5， MD4算法。
6. 知名的 CA 全世界就那么几家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。
7. 常见的对称加密有DES， 3DES， AES，前两个有漏洞，逐渐淘汰使用。
非对称加密算法有RSA，DSA，RSA使用较多。
常见的信息摘要Hash算法：MD4，MD5，SHA1，SHA2，SHA3，主流是SHA2；
注意Base64只是一种编码方式，用于传输，算法可逆，不可用于私密通信。