========== 我们直接从https的工作流程开始讲起，在讲解过程中在逐个解释相关术语 ==========
Step：服务端向权威CA机构，购买一份受信任的SSL证书 Explain：CA机构是数字证书颁发认证机构，一份证书包括一份公钥和一份私钥，用于加密解密 私钥由服务端收藏，用于服务端加密解密，公钥向所有人公开，用于客户端加密解密 浏览器可以自动检索所有CA机构颁发的证书列表，从而找出对应网站的公钥，这些都是自动完成的
Step：浏览器向服务器发出请求，并携带自己的加密算法和摘要算法
Step：服务器收到浏览器的请求，选择浏览器要求的加密算法和摘要算法
Step：服务器将自己申请的数字证书返回给浏览器
Step：浏览器根据证书的颁发机构，去内置的证书列表中查找 如果是权限证书机构，则取出对应的公钥，如果不是可信机构，则警告证书不可信，是否继续使用
Step：浏览器用公钥去解密服务器发来的数字证书，得到证书中的域名，有效期等信息 如果域名和实际访问地址不一致，或者已过有效期，则提示用户证书无效
Step：浏览器生成一个随机数R，用公钥加密后发送给服务器 Explain：公钥私钥的非对称加密算法，仅用于证书验证阶段，不用于后续的数据加密 http报文加密解密，客户端服务器用的都是同一种对称加密算法，以随机数R作为密钥 由于第三方角色没有私钥，所以即便窃取了通信数据，也无法拿到随机数R 客户端和服务器都是知道R的，第三方角色却不知道，这样便可以使用同样的对称加密算法，用R作为共用密钥，来加密解密后续的通信报文，因为第三方角色不知道密钥R，无法解密数据，即便报文被劫持了，仍然是安全的
Step：服务器用私钥解密，得到随机数R，用R加密网页，发送给浏览器
Step：浏览器用R作为密钥，解密网页数据，并以R为密钥，加密后续的请求报文
========== 了解了https的工作原理和流程，我们再来回答常见的疑问 ==========
Case：既然https可以加密数据，为什么在浏览器控制台，还可以看到数据原文 Explain：SSL是传输层协议，是防止http报文在传输过程中被第三方窃取或篡改的 我们的浏览器属于本地设备，我们在控制台看到的属于应用层数据，要么是尚未加密的发送数据，要么是已经解密的返回数据 https只负责传输安全，本地安全并不属于https考虑的范畴 如果服务器不想被本地客户端看到真实数据，可以使用代码混淆，应用层请求字段加密等技术
Case：为什么Fiddler等抓包工具，可以抓取并解密https报文 Explain：Fiddler的工作原理，实际上是在浏览器向服务端请求数字证书的阶段，拦截请求并将自己的伪造证书返回给浏览器 浏览器收到伪造证书后，发现是不可信机构颁发的，会警告用户证书不可信，是否继续使用 如果用户同意，浏览器便使用Fiddler的伪造证书来加密数据 这实质相当于是用户主动授意Fiddler来劫取自己的数据 -> 浏览器用伪造证书的公钥加密数据发送给服务器，Fiddler拦截请求，用对应的伪造私钥来解密 -> Fiddler将解密数据，用CA机构的真实公钥，重新加密数据发给服务器 -> 服务器返回数据，被Fiddler拦截，Fiddler用真实公钥解密，再用自己的伪造私钥加密，重新打包报文，发给浏览器 -> 浏览器用伪造公钥，解密被伪造私钥重新加密的报文 我们可以看到，Fiddler确实可以拦截，解密，篡改https报文，但这并不表明https是不安全，因为这是用户在知情的情况下主动授权的，如果用户拒绝使用不受信任的证书，便可以保证安全
Case：如果有公司申请了CA机构的可信证书，作为Fiddler的伪造证书，是不是浏览器就不会警告了 Explain：每个CA证书都对应一个域名，CA机构不会把相同域名的证书发给其它人
Case：如果CA机构本身不靠谱，非法为机构颁发证书，或者泄露私钥怎么办 Explain：很遗憾，这个问题确实是存在的。https还处于完善阶段，一切都是基于信任。 如果权威的CA机构出现了信用问题，虽然可以将这个CA机构除名，但确实会造成一定损失。 事实上，确实不少CA机构出现过操作失误，或者被政府控制，恶意窃取数据的事件。 但整体来说，https是安全的，出事概率很小，只有涉及国家安全，重要商业机密的公司，才需要考虑更深层次的加密方案。
