公钥-私钥，密钥通信学习指南
客户端浏览器和服务器间的通信过程
解决对称密钥的发放
- 服务器先创建一对
公钥/密钥 - 客户端向服务端发送请求，来获取公钥
- 服务端把公钥返回给客户端
- 客户端获取到公钥
- 客户端内部创建一个随机字符来做对称秘钥
- （客户端）使用公钥对内部生成的对称密码（随机字符串）加密，并发送给服务端
- （服务端）接受密码并使用私钥解密，获取对称秘钥
- （服务端）服务端发送Finished报文（双方都有了对称秘钥）
- （客户端）使用对称秘钥对要发送的数据加密【发送数据】
- （服务端）接收数据并使用对称秘钥进行解密
- （客户端）使用对称秘钥对相应数据加密【响应数据】
- （服务端）使用对称秘钥对数据解密
理解：
首先理解非对称秘钥加密 :公钥私钥对：公钥负责加密，私钥负责解密。
其次是理解对称秘钥：生成一个对称密码（一串随机字符），然后将对称密钥分别交给浏览器和服务端，对称密钥既可以进行加密，也可以进行解密。
由此可以看出，对称密钥既能加密又能解密，极为便利，最好的方法自然是让通信的双方使用同一套对称密钥，但是问题在于，假如我生成了对称密钥，如何把对称密钥给对方？
此处通信很聪明的，利用的非对称密钥 巧妙地将其中一人（客户端）的对称密钥 发给了服务端
首先：
服务端：生成自己非对称密钥 ：即公钥负责加密，私钥负责解密。
然后客户端向服务端发送一次风险请求（没有加密），然后服务端也向客户端发送一次风险响应（没有加密）但是携带了它的公钥。
然后客户端就得到了公钥，客户端生成自己的对称密钥
使用获得的公钥 对请求进行加密，携带自己生成的对称密钥 ，发送给服务端。
服务端接收到后，使用自己的私钥进行解密，获取到里面的内容（客户端的对称密钥）。
这时双方都获取到了同一套对称密钥 ，这时就可以进行安全通信了。
不过还没完，服务端确认已经获取到对称密钥后，向客户端发送FINISH报文，（不过这个东西加不加密呢？（使用对称密钥）） 不知道，但是这个FINISH报文却是为了告诉客户端，密钥获取环节结束了，可以正常通信了。后面客户端向服务器发请求，只需使用对称密钥进行加密，然后服务器也可以使用对称密钥进行解密，然后响应请求也使用对称密钥进行加密，就能保住双方的通信都是加密的。
实际上就是使用非对称密钥 并且将用于加密的公钥 暴露出去，因为可以看到，在传输公钥 时是风险请求，但是公钥本身因为不具备解密功能，所以没有用处。
有一个猜想：从前置动作可以看出，将公钥暴露，然后私钥不发出去，即解密的能力只在自己手上，那是否可以对方生成一套公钥和私钥，我们也生成一套公钥和私钥
然后将自己的公钥通过风险请求发给对方，对方的公钥也可以通过风险请求，或者安全请求（因为这时对方已经有我们的公钥了，可直接用我们的公钥 来加密他的公钥）但是公钥暴露好像没事？
不过这样的话，终归有一方正在使用的公钥暴露出去了。
不知道是不是有这层考量，因为如果最终使用的是对称密钥对，就保证了对称密钥 全笼罩在安全请求中。
解决黑客拦截对称密钥的发放过程
问题： 在上述过程中，对称密钥全程在安全状况下传输，但是有个bug，就是在第一次风险请求中，你向服务器发送请求，服务器向你发送它的公钥时， 这时，黑客跑出来拦截了这个响应，它拿到了服务器的公钥 ，这时黑客自己生成一对非对称密钥，将黑客的公钥 发给了你，然后你拿到后用黑客的公钥 加密你内部生成的对称密钥 ，这时黑客再次拦截了你的请求，因为你用的加密公钥是黑客的，所以它可以用它的私钥进行解密，从而获取到了你的对称密钥，但是这时服务器还没收到你发过去的对称密钥呢，并且这个你发送的请求因为使用了黑客的公钥加密，所以服务器就算接收到这个请求，也无法解密，所以就不会发送FINISH报文，就意味着你们的密钥同步没有成功，后面的交流就不会开始。而黑客拦截请求的目的是后面你们交流的信息，所以黑客会伪造一个请求，使用截获的服务器的公钥将你的对称密钥进行加密，然后发送给服务器，也就是说你在中间进行了掉包，然后获取到对称密钥后，再次弄了一个正确的请求给服务器，偷天换日 。然后二者就不知觉地，使用对称密钥 进行通信，而黑客因为也拿到了对称密钥 所以对请求进行拦截后，可以解密，获取到信息。
解决：
可以看到，黑客下手的点在于，他拦截了服务器发送给你的公钥 用它自己的公钥 进行掉包。 这个动作能实现的要点在于，你无法分辨发过来的公钥 的合法性，拿个通俗易懂的例子：古代皇帝任命地方官员去地方任职，官员长途跋涉到地方，会出现一种情况，官员在赴任途中被强盗截杀，然后强盗冒名顶替，然后去地方上任。这种情况多不多，不好说，但是有没有用，可以说明的是并非次次有用。
设身处地地想，皇上任命官员，必然会给官员一些凭证，但是这些凭证只能解决强盗没有截杀官员，直接顶替的情况，这种截杀后，必然获取一切随身物品，即请求的一切内容，即凭证必须不能因为被截杀就被获取，无法被截杀获取。
古代是如何操作的：当地方官员到任后，派人临摹一副画像，然后火速派往京城，然后京城经过对比画像，判断是否是冒认。这个例子好像有一点不贴切，我换句话说，京城要派人去你那拿一个信件，给了邮差一个特殊的盒子，不可被破坏，强盗可能半路截杀邮差，用自己的盒子进行掉包，因为京城的盒子，它没有钥匙，（这里假定开不了盒子就代表拿不到信息），这时你看到来人递给你一个盒子，要你把信件放进去，但是你不确定这个盒子是不是官府给的，所以，你派人临摹了这个盒子的样子款式，去京城进行确定，如果京城确定了，你就用这个盒子进行封装，这样的话，强盗就算要用自己的盒子偷天换日也无法做到。
这个就是解决方法，首先要引入第三方，然后因为在此次黑客拦截行动中，它的目的是拿到我们发出去的对称密钥 而我们之所以会把对称密钥给他，是因为我们使用了它给的公钥进行加密，导致对称密钥暴露了。而我们为什么使用了黑客的公钥进行加密，因为我们无从分辨拿到的公钥 是否是正确的，这时，我们添加一个第三方机构，【证书机构】，它可以分辨公钥是否合法，于是我们每次拿到公钥时，都拿去给【证书机构】鉴定一下，通过了才用这个公钥 进行加密，因为大家要明白一点，请求被截取是难以避免的，我们要做的其实是避免内容被破译。只要内容不被破译，黑客拦截了请求，导致通信中断，大不了不发了，或者再次发起。
具体解决：CA证书
- 开发网站后，会向证书认证机构申请一份证书
- 然后认证机构会将证书（包含公钥和企业信息）发给你
- 然后你将这份公钥和证书配置到你的服务器中。
- 客户端向你发送请求
- 服务器将配置的公钥和证书发送出去
- 客户端接收到公钥和证书后，会将公钥拿去验证（通过浏览器缓存的证书信息，或者直接拿去证书申请机构进行验证），如果通过了才用这个公钥进行加密 这就杜绝了黑客进行偷天换日的可能性，因为如果黑客拦截了服务器的响应后，用自己的公钥 进行替换，那么客户端就会识别出这个公钥是不可信任的，自然不会用这个公钥进行对对称密钥进行加密，就会导致通信终止，如果黑客不偷天换日，放任真正的公钥 传输，那么客户端使用真正的公钥进行加密的数据，它拦截了也解密不了。如果它拦着请求，不让其传到服务器上，顶多通信终止。
- 而且因为无法获取到对称密钥 就算想进行偷天换日也不可能，因为不知道加密手段，根本无法伪造请求。即使它拦截了客户端发送给服务器的对称密钥，它破译不了，它干脆不管了，直接使用截取的公钥 加密它自己的对称密钥 给服务器，这时服务器确实是和它建立起了联系，但是它如何欺骗另一端的客户端进行通信呢?若想偷天换日，在通信的中间进行请求的替换，必须掌握对两边的通信能力，即实际上A在和黑客通信，B也在和黑客通信，但是A以为是在和B在通信，实际上他们的通信都是通过黑客的替换和伪造来维持。但是就算黑客打通了黑客到服务器端的通信，成功哄骗了服务器使用黑客的对称密钥，获取到了服务器的响应值，但是它没有获取浏览器的对称密钥，根本无法将服务器的响应值用浏览器的对称密钥进行加密，以达到和浏览器的通信。因为用别的加密密钥加密的请求，浏览器根本解密不了，一旦出现解密不了的情况，立马意识到情况有变，会终止通信。
总结一句话： 一旦浏览器的对称密钥 使用了正确的公钥 进行加密，那么黑客将不可能通过其他手段获取到对称密钥的信息，除非它有对应的私钥 但是私钥不会被发送。所以除非黑客能攻入服务器，否则在请求传输层面无法达成目的。
问题：既然浏览器是通过公钥 是否在证书机构被认证来判断是否合法，那么黑客如果自己找证书机构申请一份证书和公钥，能否用这个公钥进行鱼目混珠？答案是不可能的，想必你也注意到了，证书认证机构在认证时，公钥和相关的企业信息时绑定的，你用别的企业的证书时不通过的。
尚且有一个疑问
可知，通过证书和公钥 能够确认合法性，但是如果我将证书和公钥 都进行替换，二者一体丢到证书认证机构中，当然通过。因为证书认证机构会进行两道认证：第一道时公钥 和证书是否都存在，第二道是公钥是否匹配证书。
问题在于在这个过程中，如果没有一方具有识别证书的能力，也就是说公钥的特异性由证书确定，而证书的特异性却由谁来确定呢？
换句话说，黑客申请了一个证书，企业是xxx，正规网站也申请了一个证书，企业是yyy，作为发送请求的浏览器是否能通过证书上的信息来识别，证书是否正确？
这个问题是关键，
我觉得可能是浏览器在发送请求时，已经知道对应的证书信息，怎么知道的呢？有以下几种可能：
- 请求的域名之类的
- 浏览器知道和谁在通信，知道企业信息是啥。
我偏向是第一种，即通过域名可以校正证书信息。
在动用Charles等代理服务时又该如何
这样的话，如果开启了Charles等代理服务时，又该如何解释呢？
可知charles在代理时需要配置证书，不然抓取到的信息都是乱码的。
由这个现象可以感觉出来，Charles做的事是不是类似于黑客?因为没有配置CA证书，所以无法破译。
但是这样说的话，那黑客申请一个证书也能够抓取到请求，进行破译。
所以应该是有区别的，
有两种可能性：
第一种： 是确实是和黑客的行为一样，只是说这个CA证书很特殊，和Charles软件所在的本地机器有关，所以导致这个CA证书可以通过验证，从而可以截取破译携带有对称密钥的请求。
第二种： Charles的运行机制并非黑客逻辑，而是作为正规的中转站，即实际上浏览器是跟Charles进行通信，Charles在和服务器进行通信，关键在于浏览器虽然最终目的是与服务器通信，但是它的第一导向确实是和Charles进行通信的，这就是为啥charles的CA证书可以通过验证，因为浏览器的直接通信目标企业就是Charles，然后可能是因为某些额外信息，让Charles知晓了浏览器的最终通信目的是和某某服务器进行通信，所以由Charles发起对服务器的通信。也就是确确实实的两段通信，和黑客拦截不同，浏览器和服务器都很清楚自己是在和Charles进行通信，只是说Charles将二者信息进行中转传递。而在黑客参与的场景下，浏览器实际上是直接和服务器进行通信的，他们都知道通信对方是谁，只是黑客在其中进行偷天换日罢了。也就是这时黑客这个中转站其实是隐性的，没有驿站的，只是散兵游勇，而上面的两段通信则是明确通信是存在三方驿站的。
公钥证书 CA 的认证
公钥证书也被称为数字证书或简称为证书。客户端接收到证书后，会进行以下操作：
验证数字签名：客户端使用数字证书认证机构的公开密钥来验证证书上的数字签名。
确认证书有效性：如果签名验证通过，客户端就可以确认两件事情：一是证书是由一个真实有效的数字证书认证机构签发的；二是服务器的公开密钥是可以信赖的。
通过数字签名来判断数据有没有被修改
数据摘要，也叫数据指纹。其基本原理是利用单向散列函数（Hash函数）【这类函数接受输入（可以是任意长度的数据），并输出一个固定长度的散列值（哈希值）。这个过程是单向的，即无法从散列值反推出原始数据】对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被修改。
数据摘要可以用来检查数据在传输或存储过程中是否被篡改。通过比较原始数据的散列值和接收到的数据的散列值，可以确定数据是否保持完整。
数据签名是一种用于验证数字信息或文档完整性和来源的技术。下面是它的工作流程：
- 生成签名：
哈希函数：首先，对要签名的数据进行哈希处理，生成一个固定长度的数据摘要（哈希值）。
私钥加密：然后，使用签名者的私钥对这个哈希值进行加密，生成数字签名。
验证签名：
- 公钥解密：接收方使用签名者的公钥对数字签名进行解密，得到哈希值。
哈希比较：接收方对接收到的原始数据进行哈希处理，生成一个新的哈希值，并将其与解密得到的哈希值进行比较。
如果两个哈希值相同，则验证成功，表明数据在传输过程中未被篡改，并且是由持有私钥的签名者所签名的。
如果黑客使用自己申请的合法的CA证书和公钥，即使这些证书和公钥被一个受信任的证书颁发机构签发，浏览器也可能无法完全识别出这些证书和公钥并非准备与之通信的服务器所持有。这种情况可能会导致一些安全问题，因为虽然证书和公钥是有效的，但却被错误地应用到了其他服务器上。 通常，浏览器在收到服务器发送的证书时会执行以下验证步骤： 1. 确认证书是否由受信任的CA签发。 2. 校验证书中的域名是否与当前连接的服务器域名匹配。 3. 检查证书是否在CRL中列出或使用OCSP协议检查证书状态。
一般浏览器或客户端校验证书时，都会先检查证书是否是“受信任的根证书颁发机构”颁发，再检查SSL证书中的证书吊销列表，再检查检查此SSL证书是否过期，再检查SSL证书的网站的域名是否与当前访问域名一致。如果使用一个合法签发的证书实际上可以通过大部分校验。
解决黑客使用自己申请的合法的证书和公钥进行替换的问题
证书上存在域名信息，每个域名都是独一无二的。而证书上是存在域名信息的，换句话说，在证书认证机构那里，其实CA证书和公钥是与对应的域名绑定的，浏览器可以从对应的域名出发来检测收到的证书和公钥的合法性和正确性
有了证书之后，当你的浏览器在访问某个 HTTPS 网站时，会验证该站点上的 CA 证书（类似于验证介绍信的公章）。如果浏览器发现该证书没有问题（证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期），那么页面就直接打开；否则的话，浏览器会给出一个警告，告诉你该网站的证书存在某某问题，是否继续访问该站点
解决：Charles代理的机制
关于Charles代理的运行逻辑，Charles实际上是通过中间人攻击的方式来拦截和解析HTTPS请求。在这种情况下，通信是在浏览器和服务器之间，但经过Charles代理的中间处理。Charles会将加密的HTTPS流量解密，查看请求和响应内容，然后将其重新加密并转发。因此，通信是在三方（浏览器、Charles代理、服务器）之间展开的。这种方法有利于开发人员调试和分析网络流量，但也可能被恶意使用来窃取敏感信息。 总的来说，Charles代理工具的操作原理确实会类似于中间人攻击，需要谨慎使用并保护好相关的CA证书，以防止信息被恶意拦截和篡改。
https工作原理
HTTPS，全称Hypertext Transfer Protocol Secure，是HTTP协议的安全版本。它在HTTP的基础上，通过引入SSL/TLS协议来实现数据加密和身份认证，从而确保数据传输过程中的安全性和完整性。当用户在浏览器中访问HTTPS网站时，浏览器会与服务器建立加密通道，所有传输的数据都会被加密，即使数据被截获，也无法被轻易解密。
HTTPS的工作原理简述：
- 客户端发起请求：浏览器向服务器发起HTTPS请求。
- 服务器响应并发送证书：服务器返回其SSL证书，证书中包含公钥和服务器身份信息。
- 客户端验证证书：浏览器验证证书的合法性和有效性，包括检查证书是否由受信任的CA签发、证书是否过期以及证书中的域名是否与访问的域名一致。
- 生成对称密钥：如果证书验证通过，客户端会生成一个随机的对称密钥，并使用服务器证书中的公钥加密该密钥后发送给服务器。
- 密钥交换完成：服务器使用自己的私钥解密对称密钥，此后双方使用该对称密钥进行加密通信。
三、SSL证书：身份的证明
SSL证书是一种数字证书，用于在HTTPS通信中验证服务器的身份。它包含服务器的公钥、服务器身份信息（如域名、组织名称等）以及CA的签名。通过验证SSL证书，客户端可以确认自己正在与正确的服务器进行通信。
SSL证书的类型：
- 域名验证型（DV）证书：仅验证域名所有权，适用于个人网站、博客等。
- 组织验证型（OV）证书：除域名验证外，还需验证申请者的组织信息，适用于企业官网、电子商务网站等。
四、数字签名：数据的守护者
数字签名是一种用于验证数据完整性和真实性的技术。它使用私钥对原始数据进行加密生成签名，然后使用公钥对签名进行解密验证。通过数字签名，接收方可以确认数据在传输过程中未被篡改，并验证数据的来源是否可信。
数字签名的应用场景：
- 电子合同：确保合同内容的真实性和完整性。
- 电子支付：验证支付信息的真实性和完整性。
- 软件分发：确保软件在分发过程中未被篡改。
五、私钥与公钥：加密与解密的钥匙
私钥和公钥是非对称加密算法中的一对密钥。私钥用于解密由公钥加密的数据或创建数字签名，而公钥则用于加密数据或验证数字签名。
- 私钥：必须妥善保管，只有私钥的所有者才能解密由公钥加密的数据或验证其签名。
- 公钥：可以公开给任何人，用于加密数据或验证签名。
结论
HTTPS、CA、SSL证书、数字签名、私钥与公钥等技术共同构建了网络通信的安全体系。通过这些技术的协同工作，我们可以确保数据传输的安全性、完整性和真实性，从而在网络世界中享受更加安全、便捷的服务。作为网络用户或开发者，了解这些技术的基本原理和实际应用，对于提升我们的网络安全意识和能力具有重要意义。