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

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

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

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

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

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

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

        第三方机构对服务端的RSA公钥进行认证（确保真实无误，且没有篡改）， 那么问题就完全解决了。 怎么实现的呢？ 第三方认证中心用自己的RSA私钥对服务端（目的是发给客户端）的RSA公钥进行保护， 客户端拿个第三方机构的RSA公钥来解出服务端的RSA公钥， blablablalbla，  于是认为服务端的RSA公钥可信。 那么问题来了， 客户端怎么获取到第三方机构的RSA公钥呢？ 这就是涉及到认证的流程了，扯多了， 会涉及到根证书的概念。 会有一点点复杂。 有兴趣的朋友， 可以看看认证流程和原理。

        有很多数字认证公司， 就是专门干这些事的， 专门派发数字证书， 完成数字认证。

        说了这么多， 而且都是用文字说明的， 比较绕了。 最好是画图来理解。 如上就是https的大致原理， 其实也比较简单。

         接下来， 我们来看tcp安全通道的设计， 我为什么想说这个呢？ 因为我之前碰到过。 仿https的简单方案可以如下：

         1.  服务端生成RSA密钥对， 然后在合作中， 服务端的同事直接把RSA公钥发给客户端同事。（可以通过QQ发， 通过微信发， 或者写在文档文档中）

         2.  客户端随机随机生成对称秘钥key， 然后用RSA公钥加密， 发送到服务端。

         3.  服务端用RSA私钥来解密， 得到对称秘钥key。

         4.   客户端和服务端用用对称秘钥key对通信内容进行AES加密。

          安全， 搞定。 不多说。

          我都是用文字来说明的， 喷的时候， 请轻点， 谢谢。