说明：这里我只记录https中的传输层安全(Transport Layer Security，TLS)一些细节 个人总结如有不恰当的地方还请礼貌指正
1 https是使用非对称加密实现对称加密的协商，通过非对称加密确定一个受信任的来自目标服务器的公钥，通过这个公钥来协商一个对称加密的秘钥之后的传输都使用这个对称秘钥来加密传输。
2 现在的问题就是如何确保这个公钥是受信任的 首先明确一点：来自我们目标服务器 没有别修改的公钥就是受信任的，如何保证这个过程没有被修改和替换呢，https中使用一个权威的第三方机构来保证具体步骤如下：
3 首先服务器生成一对公钥和私钥 这对公钥私钥用于和client协商一次请求中的对称密钥（对称秘钥是通过公钥传输给server的）为了保证公钥在传输的过程中不被修改和替换 server会先向CA机构申请一个代表server的证书该证书由ca创建 证书包含了具体server的一些信息和Ca的一些信息比如ca的名称证书的拥有者证书的有效期 签名的加密算法 等基本信息，证书中还包含一个特殊的东西：数字签名。数字签名是ca跟具server提供的信息使用MD得到的一个固定长度的数据后使用ca自己的私钥加密后的数据。server在每次收到client的请求是都将证书发送给client 当然这个发送的过程中中间节点也能收到这个证书 但是中间节点对这个证书动的手脚或者替换这个证书 client都能知道。一旦client发现证书被动过手脚 client报证书验证不通过错误此次请求失败。
4 client验证证书的过程：client拿到证书后首先会从系统中找出ca的公钥 解密出数字签名的原始数据 然后更具证书中的算法和证书上的数据 自己重新计算一遍 之后对比两个 数据数据是否一致如果一致则 证书是受信任的 这里中间节点如果要对证书使坏分两点 中间节点自己也有一个合法的ca颁发的证书 然后将自己的证书的信息改成 server的信息 将修改的后的证书替换原证书发送给clinet 这个时候client拿到修改后的证书 最后对比元数据肯定是不通过的 最后验证失败。还有一种就是中间节点同时修改信息和数字签名 这样修改的证书逻辑上就是一个完整的证书了 但由于client拿的公钥无法解密出数字签名的原始数据最终依然验证失败（client只含有受信任的ca的公钥）
5 现在假定client证书验证通过 确定证书没毛病之后 会从证书中取出server的公钥 client使用这个公钥加密自己生成的一个对称加密的秘钥发送给server 这个过程是不会出现安全问题的因为私钥只在server中 server收到公钥加密后的数据后使用私钥解密拿到最终的对称加密秘钥 之后的通信过程就都是使用这个对称加密秘钥来保证通信的安全。
