https简介以及仿https的加密tcp安全通道的简要设计思路

        今天， 我们来说说https,  也就是安全的http.

        怎么个安全法？ 那肯定是要对传输的数据进行加密， 为了效率， 我么可以考虑用对称加密算法， 如典型的AES.  那么问题来了， 客户端和服务端怎样才能拥有相同的对称秘钥key呢？  显然， 可以考虑从客户端端随机生成一个秘钥， 然后传递了服务端， 这不就行了吗？ 是的。

        但是， 传递这个秘钥的过程， 是一个不靠谱的过程， 如果秘钥被坏人中途截获怎么办？ 显然， 坏人也是可以用秘钥key来解密传输内容的， 安全性无从说起。

        那怎么办呢？  可以考虑这样一种情况， 如果客户端有RSA公钥， 那么就可以对对称秘钥key进行加密保护， 传递给服务端， 即使中途被截获， 也不怕， 因为必须要有RSA私钥才能解开内容， 所以， 这样就保护了对称秘钥key不被中途截获， 问题貌似就解决了。 恩。

        但是， 这又引入了一个新的问题， 客户端的RSA公钥和服务端的RSA私钥是怎么分配的？ 必然要从一段传递到另外一端啊。 我们考虑， 在服务端生成RSA公钥和RSA私钥， 然后服务端传递给客户端， 这不就OK了吗？  公钥是公开的， 坏人知道了公钥又能如何？ 恩。

        可是， 坏人可以在中间过程生成一对假的RSA秘钥对， 然后把坏人把假的RSA公钥发给客户端， 坏人自己持有假的RSA私钥， 于是， 客户端实际上在跟中间的坏人进行通信， 客户端浑然不知。这就引入了一个新的问题： 客户端怎么知道自己手上的RSA公钥是服务端派发的还是中间坏人的呢？  这里就引入了数字证书的概念。

        第三方机构对服务端的RSA公钥进行认证（确保真实无误，且没有篡改）， 那么问题就完全解决了。 怎么实现的呢？ 第三方认证