。。。。。。。。。。。。。。。。。。。。。。。。。。

证书授权 私钥  是唯一的 中间代理 可能会解密读取  但不能修改

......如何防止被解密读取？

有知道的吗？

tls 会话期间双方协商的密钥交换算法,从服务器发往客户端的数字证书,以及客户端收到服务器的数字证书后,使用浏览器预先内置的各种证书颁发机构的公钥对其中特定内容解密,如果解密成功说明证书
没有被伪造（保密性）,同时没有被篡改（完整性），而且验证了对方的身份。
确实，存在组织机构的合法证书被盗取或者丢失的可能性，这样该证书就会被攻击者冒用。因此组织机构需要向原始颁发证书的机构申请吊销证书，后者将该证书作废，并更新证书吊销列表。对于 firefox，启动时会定期去特定的 URL 下载这个证书吊销列表。windows 也有一个特定的服务会定期
去微软的证书吊销列表服务器下载，用于支持 IE 识别最新的有效证书。

除非组织机构的私钥泄露，否则攻击者拦截加密的tls/https消息也无法解密其中内容

我的意思是这样的，举个例子，客户端A 要https至 服务器B，而实际链路里面 A 到 B 是要经过 代理X的。就像 A 是 firefox, B是百度，你在firefox里面敲 d79K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2T1j5h3W2V1N6g2)9J5k6h3y4G2L8g2!0q4x3#2)9^5x3q4)9^5x3W2!0q4y4#2)9^5c8g2!0n7x3q4!0q4y4g2)9&6b7#2!0m8z5q4!0q4y4W2!0m8c8W2)9&6y4q4!0q4z5q4!0n7c8g2)9^5x3#2!0q4z5q4!0m8c8W2!0m8x3g2!0q4y4g2!0n7b7#2)9^5x3W2!0q4y4#2)9&6b7g2)9^5y4q4!0q4y4W2)9&6z5q4!0m8c8W2!0q4c8W2!0n7b7#2)9^5b7#2!0q4y4g2!0m8y4W2)9^5x3W2!0q4y4W2)9&6c8g2)9&6b7@1q4Q4c8e0k6Q4z5e0N6Q4b7e0m8Q4c8e0k6Q4b7U0y4Q4z5e0g2Q4c8e0N6Q4z5f1u0Q4b7U0c8Q4c8e0k6Q4z5p5g2Q4b7e0g2Q4c8e0g2Q4z5o6S2Q4b7U0m8n7i4@1g2r3i4@1u0o6i4K6S2o6i4@1f1^5i4K6R3H3i4K6S2o6i4@1f1#2i4@1u0r3i4K6R3#2i4@1f1&6i4@1p5I4i4@1u0n7i4@1f1@1i4@1t1^5i4@1q4p5i4@1f1&6i4K6V1%4i4@1t1@1i4@1f1&6i4K6R3H3i4K6W2m8i4@1f1^5i4@1u0r3i4K6R3%4h3q4!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5g2)9^5x3W2!0m8x3#2!0q4z5g2)9&6y4#2!0m8c8g2!0q4z5g2!0m8x3W2)9&6z5q4!0q4y4g2!0n7x3q4!0n7x3g2!0q4y4W2)9&6c8q4!0m8y4g2!0q4y4q4!0n7b7g2)9^5y4W2!0q4c8W2!0n7b7#2)9^5b7#2!0q4y4g2)9^5y4g2!0n7y4#2!0q4y4q4!0n7c8q4)9&6x3#2!0q4y4g2!0m8y4W2)9^5x3W2!0q4y4q4!0n7z5q4)9^5b7W2!0q4c8W2!0n7b7#2)9&6b7b7`.`.

1、A在firefox里面敲 cedK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2T1j5h3W2V1N6g2)9J5k6h3y4G2L8b7`.`.
2、X截取到A要跟B握手的信息 client_hello_A_2_B（停止点 A_X_1）
3、X发起到B的握手信息 client_hello_X_2_B，内容跟截取到A的一样（ip地址等信息另计）
4、B回复X server_hello, certificate, server_hello_done，这样，X获得了B的数字证书（停止点B_X_1）
5、回到 停止点A_X_1，X回复A server_hello, certificate, server_hello_done（注意：这里的证书是 X的数字证书）。这样，A得到的是X的数字证书
.........
最后，X分别与A和B都进行了握手，A发给B的信息在X里都被成功解码后再转发给B，也就是X监测了A发给B的信息，尽管使用了 tls 加密。

如果是自己手动写程序还好，但因为是使用firefox去访问baidu，你根本不知道firefox收到的会是代理X的数字证书（注意：X的数字证书也是合法的），而不是baidu的证书。

请问上面这种情况该如何处理才能避免？

你描述的这个情况原则上仅在局域网内才有可能会发生,所谓的"代理"通过 ARP 欺骗来截获并转发受害者与 https 服务器之间的流量。
解决之道是,采用静态的 ARP 表,或者不定期检查你配置的网关 IP 与其 MAC 地址之间的映射关系,让非法的 MAC 地址无法与网关地址关联起来。

一旦握手数据包离开了本地网络，遇到“代理”的几率真的不会比你坐在家里看电视遇到陨石袭击的几率还要高出多少了。

首先，你必须明白你与百度或其它站点之间的链路存在哪些“节点”，可以通过命令行工具 tracert 或 traceroute 来跟踪到目标服务器之间的所有节点，一般而言，你会先连接到你的ISP，然后数据包通过ISP的路由器转发给下一跳节点。
除非你与ISP连接的物理线路之间被人安插了数据包窃听工具，否则“代理”不太可能出现在这个位置。

接下来，考虑握手的数据包被你的ISP转发给广域网上其它的ISP（比如从电信服务提供商网络进入联通服务提供商网络），在这个环节，由ISP负责你的握手数据包的安全，保证其中的链路不存在所谓的“代理”。

ISP可以随时监测它们自己运维的网络的安全性，从而保证不会有你的“代理”插入其中。类似地，负责将你要访问的目标站点接入Internet的ISP保证了它俩之间不存在任何“代理”。

如此一来，你的“代理”在数据包传输的所有路径中都不存在，唯一可能的位置就是由局域网内部发起的 ARP 欺骗攻击，防御办法前面讲过了，网络上也有许多文章可以参考。

另外，关于你说的第5点：现在（其实是很久以前就开始推行了）有一种增强型的数字证书，它可以识别证书所有者的身份，换言之，“代理”无法冒充百度（以及所有其它使用此类证书的站点）来与你的浏览器建立会话。

试想一下，如果不是这样的话，电子商务，网上银行这些极端依赖于https的站点，它们的业务要如何开展？
如果你担心“代理”随处可在，随意就能够“解码”用户的网银账密来盗领，你可以从家里或公司的网络出发，沿着出口网线接入ISP的方向漫步，然后搜索路边的电信设备，或者是否有可疑的人物在附近执行数据包嗅探？
你还可以向你的ISP咨询“代理”实际存在的可能性和避免措施。。。。