一文全解什么是HTTPS协议？HTTP和HTTPS协议有才能区别？

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　什么是HTTP协议?

　　HTTP协议全称Hyper Text Transfer Protocol，翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层。

　　

　　HTTP协议通过请求/响应的方式，在客户端和服务端之间进行通信。

　　

　　这一切看起来很美好，但是HTTP协议有一个致命的缺点：不够安全。

　　HTTP协议的信息传输完全以明文方式，不做任何加密，相当于是在网络上“裸奔”。这样会导致什么问题呢?让我们打一个比方：

　　小灰是客户端，小灰的同事小红是服务端，有一天小灰试图给小红发送请求。

　　

　　但是，由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。

　　

　　

　　

　　如何进行加密呢?

　　小灰和小红可以事先约定一种对称加密方式，并且约定一个随机生成的密钥。后续的通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。

　　

　　

　　这样做是不是就绝对安全了呢?并不是。

　　虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。

　　

　　这可怎么办呢?别担心，我们可以使用非对称加密，为密钥的传输做一层额外的保护。

　　非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密;也可以用私钥加密，用公钥解密。

　　在小灰和小红建立通信的时候，小红首先把自己的公钥Key1发给小灰：

　　

　　收到小红的公钥以后，小灰自己生成一个用于对称加密的密钥Key2，并且用刚才接收的公钥Key1对Key2进行加密(这里有点绕)，发送给小红：

　　小红利用自己非对称加密的私钥，解开了公钥Key1的加密，获得了Key2的内容。从此以后，两人就可以利用Key2进行对称加密的通信了。

　　在通信过程中，即使中间人在一开始就截获了公钥Key1，由于不知道私钥是什么，也无从解密。

　　

　　是什么坏主意呢?中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰。

　　小灰不知道公钥被偷偷换过，以为Key3就是小红的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给小红。

　　这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红。

　　这样一来，两个人后续的通信尽管用Key2做了对称加密，但是中间人已经掌握了Key2，所以可以轻松进行解密。

　　

　　是什么解决方案呢?难道再把公钥进行一次加密吗?这样只会陷入鸡生蛋蛋生鸡，永无止境的困局。

　　这时候，我们有必要引入第三方，一个权威的证书颁发机构(CA)来解决。

　　到底什么是证书呢?证书包含如下信息：

　　

　　为了便于说明，我们这里做了简化，只列出了一些关键信息。至于这些证书信息的用处，我们看看具体的通信流程就能够弄明白了。

　　流程如下：

　　1.作为服务端的小红，首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。

　　2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端小红。

　　3.当小灰向小红请求通信的时候，小红不再直接返回自己的公钥，而是把自己申请的证书返回给小灰。

　　

　　4.小灰收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以小灰只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。

　　接下来，小灰按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。

　　验证成功后，小灰就可以放心地再次利用机构公钥，解密出服务端小红的公钥Key1。

　　5.像之前一样，小灰生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给小红。

　　6.最后，小红用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。

　　在这样的流程下，我们不妨想一想，中间人是否还具有使坏的空间呢?

　　

　　

　　

　　

　　

　　

　　

　　注：最新推出的TLS协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的。

　　
HTTP特点：

    无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
    无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
    基于请求和响应：基本的特性，由客户端发起请求，服务端响应
    简单快速、灵活
    通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性


HTTPS特点：
    内容加密：采用混合加密技术，中间者无法直接查看明文内容
    验证身份：通过证书认证客户端访问的是自己的服务器
    保护数据完整性：防止传输的内容被中间人冒充或者篡改

    **混合加密：**结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密，所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据。

    **数字摘要：**通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。

    **数字签名技术：**数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。

    收方能够证实发送方的真实身份；
    发送方事后不能否认所发送过的报文；
    收方或非法者不能伪造、篡改报文。


总结：

安全性考虑：
    HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
    SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行

    中间人攻击（MITM攻击）是指，黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM，被动MITM只窃取通信数据而不修改，而主动MITM不但能窃取数据，还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。

成本考虑：
    SSL证书需要购买申请，功能越强大的证书费用越高
    SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
    根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。
    HTTPS连接缓存不如HTTP高效，流量成本高。
    HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
    HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

　　—————END—————

过期罐头有你更精彩！