确实不安全!(HTTP协议传输)传统的HTTP传输协议，是一种明文传输协议。也就是通信过程中都没有对数据进行加密，很容易泄漏数据。
比如泄漏了重要的用户信息、被伪造数据发送、都会造成不小的问题。
所以有的朋友就想到可以自己对数据进行加密，但是这种自己加密数据的方法也存在了很多问题，比如：
不够安全。虽然数据加了密看似安全了，但是加密的密钥怎么管理呢?这是个大问题，保存在客户端?引入插件?感觉都不是什么比较好的办法，都还是有可能被破解。
兼容问题。自己对数据加密，那么就要涉及到对加密算法的管理了，而加密算法是在不断发展的，而这就要求客户端和服务器端要对加密保持更新兼容，而且不能实时进行更新，需要线下更新代码逻辑。所以这也是一个比较麻烦的问题。
性能问题。通过代码去加密解密这个过程也是比较耗时的，会影响到性能。
所以，在原有的HTTP协议基础之下就增加了一种协议——SSL/TLS协议，形成新的较安全的网络协议——HTTPS。
对数据进行加密～(HTTPS传输数据)在之前的网络数据传输过程中我说过，对数据进行解析的一系列应用层的工作都是交给了浏览器和操作系统的TCP协议栈。
所以HTTPS的加密解密工作自然也就是交给了浏览器，这样就不存在上述的性能问题了。
具体怎么做的呢?用到了对称加密算法：
客户端用对称密钥对数据进行加密。
客户端用对称密钥对数据进行解密。
有人就会问了，这不还是和刚才说到的一样吗?这个密钥怎么管理呢?
这就需要在正式传输数据之前想办法把这个对称密钥告诉对方了。而这个办法就是——非对称加密。
怎么告诉对方这个对称密钥?(非对称加密)大家都知道非对称加密是分私钥和公钥，也就是你通过公钥加密数据，然后我用私钥来解密。私钥只有自己有，所以只有自己能解开这个数据，即使中间人拿到数据，也破解不了。
放到实际客户端服务器通信中，就是服务器端将公钥发给客户端，然后客户端那这个公钥对对称密钥进行加密，并发给客户端，只有客户端有私钥可以解这个含有对称加密的密文。但是，公钥是明文传输的呀，那么中间人就可以利用这个公钥伪造数据了
所以怎么解决呢?就需要这个消息证明他是来自真正的服务器端，拿到真正的公钥，而不是伪造的，这就需要电子签名了。
我要证明我是我!(电子签名)湘情盾北京,天津高防服务器BGP租用
电子签名其实也是一种非对称加密的用法。
它的使用方法是：
A使用私钥对数据的哈希值进行加密，这个加密后的密文就叫做签名，然后将这个密文和数据本身传输给B。
B拿到后，签名用公钥解密出来，然后和传过来数据的哈希值做比较，如果一样，就说明这个签名确实是A签的，而且只有A才可以签，因为只有A有私钥。
反应实际情况就是：
服务器端将数据，也就是我们要传的数据(公钥)，用另外的私钥签名数据的哈希值，然后和数据(公钥)一起传过去。然后客户端用另外的公钥对签名解密，如果解密数据和数据(公钥)的哈希值一致，就能证明来源正确，不是被伪造的。
但是，这个用作签名的另外的私钥和另外的公钥怎么来的呢?这就需要强大的CA来验证了。
强大的后台机构～(数字证书)
证书颁发机构(CA,CertificateAuthority)即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。”实际情况中，服务器会拿自己的公钥以及服务器的一些信息传给CA，然后CA会返回给服务器一个数字证书，这个证书里面包括：
服务器的公钥签名算法服务器的信息，包括主机名等。CA自己的私钥对这个证书的签名然后服务器将这个证书在连接阶段传给客户端，客户端怎么验证呢?
细心的小伙伴肯定知道，每个客户端，不管是电脑、手机都有自带的系统根证书，其中就会包括服务器数字证书的签发机构。所以系统的根证书会用他们的私钥帮我们对数字证书的签名进行解密，然后和证书里面的数据哈希值进行对比，如果一样，则代表来源是正确的,数据是没有被修改的。
当然中间人也是可以通过CA申请证书的，但是证书中会有服务器的主机名，这个主机名(域名、IP)就可以验证你的来源是来源自哪个主机。
可以看到一般完整的SSL/TLS证书有三层结构：
第一层：根证书。也就是客户端自带的那些。第二层：中级证书。一般根证书是不会直接颁发服务器证书的，因为这种行为比较危险，如果发现错误颁发就很麻烦，需要涉及到跟证书的修改。所以一般会引用中间证书，根证书对中间证书进行签名，然后中间证书再对服务器证书进行签名，一层套一层。第三层：服务器证书。也就是跟我们服务器相关的这个证书了。
24小时无理由退换
5秒技术响应
7x24小时技术支持
域名自助过白
1V1专席秘书
湘情盾-笑笑