HTTP和HTTPS协议，看一篇就够了

2018年07月19日 14:25:57 不同 阅读数 42932

 

版权声明：专属于不同的博客，转发请附上博客出处 https://blog.csdn.net/xiaoming100001/article/details/81109617

大纲

1、前言：

先来观察这两张图，第一张访问域名http://www.12306.cn，谷歌浏览器提示不安全连接，第二张是https://kyfw.12306.cn/otn/regist/init，浏览器显示安全，为何会这样子呢？2017年1月发布的Chrome 56浏览器开始把收集密码或信用卡数据的HTTP页面标记为“不安全”，若用户使用2017年10月推出的Chrome 62，带有输入数据的HTTP页面和全部以无痕模式浏览的HTTP页面都会被标记为“不安全”，此外，苹果公司强制全部iOS App在2017年1月1日前使用HTTPS加密。

2、HTTP和HTTPS发展历史

什么是HTTP?

超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为普遍的一种网络协议,全部的WWW文件都必须遵照这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

发展历史：

版本	产生时间	内容	发展示状
HTTP/0.9	1991年	不涉及数据包传输，规定客户端和服务器之间通讯格式，只能GET请求	没有做为正式的标准
HTTP/1.0	1996年	传输内容格式不限制，增长PUT、PATCH、HEAD、 OPTIONS、DELETE命令	正式做为标准
HTTP/1.1	1997年	持久链接(长链接)、节约带宽、HOST域、管道机制、分块传输编码	2015年前使用最普遍
HTTP/2	2015年	多路复用、服务器推送、头信息压缩、二进制协议等	逐渐覆盖市场

这个Akamai公司创建的一个官方的演示，使用HTTP/1.1和HTTP/2同时请求379张图片，观察请求的时间，明显看出HTTP/2性能占优点。

多路复用：经过单一的HTTP/2链接请求发起多重的请求-响应消息，多个请求stream共享一个TCP链接，实现多留并行而不是依赖创建多个TCP链接。

什么是HTTPS？

《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种经过计算机网络进行安全通讯的传输协议，经由HTTP进行通讯，利用SSL/TLS创建全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
PS:TLS是传输层加密协议，前身是SSL协议，由网景公司1995年发布，有时候二者不区分。

参考链接：

1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/
2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
3.https://tools.ietf.org/html/rfc1945
4.https://http2.github.io/http2-spec/
5.https://www.zhihu.com/question/34074946

3、HTTP VS HTTPS

HTTP特色：

1. 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，好比访问一个网站须要反复进行登陆操做
2. 无链接：HTTP/1.1以前，因为无状态特色，每次请求须要经过TCP三次握手四次挥手，和服务器从新创建链接。好比某个客户机在短期屡次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，因此每次须要从新响应请求，须要耗费没必要要的时间和流量。
3. 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
4. 简单快速、灵活
5. 通讯使用明文、请求和响应不会对通讯方进行确认、没法保护数据的完整性

下面经过一个简单的抓包实验观察使用HTTP请求传输的数据：

结果分析：HTTP协议传输数据以明文形式显示

针对无状态的一些解决策略：

场景：逛电商商场用户须要使用的时间比较长，须要对用户一段时间的HTTP通讯状态进行保存，好比执行一次登录操做，在30分钟内全部的请求都不须要再次登录。

1. 经过Cookie/Session技术
2. HTTP/1.1持久链接（HTTP keep-alive）方法，只要任意一端没有明确提出断开链接，则保持TCP链接状态，在请求首部字段中的Connection: keep-alive即为代表使用了持久链接

HTTPS特色：

基于HTTP协议，经过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护

经过抓包能够看到数据不是明文传输，并且HTTPS有以下特色：

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

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

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

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

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

非对称加密过程须要用到公钥进行加密，那么公钥从何而来？其实公钥就被包含在数字证书中，数字证书一般来讲是由受信任的数字证书颁发机构CA，在验证服务器身份后颁发，证书中包含了一个密钥对（公钥和私钥）和全部者识别信息。数字证书被放到服务端，具备服务器身份验证和数据传输加密功能。

4、HTTP通讯传输

客户端输入URL回车，DNS解析域名获得服务器的IP地址，服务器在80端口监听客户端请求，端口经过TCP/IP协议（能够经过Socket实现）创建链接。HTTP属于TCP/IP模型中的运用层协议，因此通讯的过程实际上是对应数据的入栈和出栈。

报文从运用层传送到运输层，运输层经过TCP三次握手和服务器创建链接，四次挥手释放链接。

为何须要三次握手呢？为了防止已失效的链接请求报文段忽然又传送到了服务端，于是产生错误。

好比：client发出的第一个链接请求报文段并无丢失，而是在某个网络结点长时间的滞留了，以至延误到链接释放之后的某个时间才到达server。原本这是一个早已失效的报文段，可是server收到此失效的链接请求报文段后，就误认为是client再次发出的一个新的链接请求，因而就向client发出确认报文段，赞成创建链接。假设不采用“三次握手”，那么只要server发出确认，新的链接就创建了，因为client并无发出创建链接的请求，所以不会理睬server的确认，也不会向server发送数据，但server却觉得新的运输链接已经创建，并一直等待client发来数据。因此没有采用“三次握手”，这种状况下server的不少资源就白白浪费掉了。

为何须要四次挥手呢？TCP是全双工模式，当client发出FIN报文段时，只是表示client已经没有数据要发送了，client告诉server，它的数据已经所有发送完毕了；可是，这个时候client仍是能够接受来server的数据；当server返回ACK报文段时，表示它已经知道client没有数据发送了，可是server仍是能够发送数据到client的；当server也发送了FIN报文段时，这个时候就表示server也没有数据要发送了，就会告诉client，我也没有数据要发送了，若是收到client确认报文段，以后彼此就会愉快的中断此次TCP链接。

5、HTTPS实现原理

1. client向server发送请求https://baidu.com，而后链接到server的443端口。

2. 服务端必需要有一套数字证书，能够本身制做，也能够向组织申请。区别就是本身颁发的证书须要客户端验证经过，才能够继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。

3. 传送证书
   这个证书其实就是公钥，只是包含了不少信息，如证书的颁发机构，过时时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。

4. 客户端解析证书
   这部分工做是由客户端的TLS来完成的，首先会验证公钥是否有效，好比颁发机构，过时时间等等，若是发现异常，则会弹出一个警告框，提示证书存在问题。若是证书没有问题，那么就生成一个随即值（秘钥）。而后用证书对该随机值进行加密。

5. 传送加密信息
   这部分传送的是用证书加密后的秘钥，目的就是让服务端获得这个秘钥，之后客户端和服务端的通讯就能够经过这个随机值来进行加密解密了。

6. 服务段加密信息
   服务端用私钥解密秘密秘钥，获得了客户端传过来的私钥，而后把内容经过该值进行对称加密。

7. 传输加密后的信息
   这部分信息是服务端用私钥加密后的信息，能够在客户端被还原。

8. 客户端解密信息
   客户端用以前生成的私钥解密服务端传过来的信息，因而获取了解密后的内容。

问题：
1.怎么保证保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

2.证书如何安全传输，被掉包了怎么办？

• 数字证书包括了加密后服务器的公钥、权威机构的信息、服务器域名，还有通过CA私钥签名以后的证书内容（通过先经过Hash函数计算获得证书数字摘要，而后用权威机构私钥加密数字摘要获得数字签名)，签名计算方法以及证书对应的域名。当客户端收到这个证书以后，使用本地配置的权威机构的公钥对证书进行解密获得服务端的公钥和证书的数字签名，数字签名通过CA公钥解密获得证书信息摘要，而后根据证书上描述的计算证书的方法计算一下当前证书的信息摘要，与收到的信息摘要做对比，若是同样，表示证书必定是服务器下发的，没有被中间人篡改过。由于中间人虽然有权威机构的公钥，可以解析证书内容并篡改，可是篡改完成以后中间人须要将证书从新加密，可是中间人没有权威机构的私钥，没法加密，强行加密只会致使客户端没法解密，若是中间人强行乱修改证书，就会致使证书内容和证书签名不匹配。
• 那第三方攻击者可否让本身的证书显示出来的信息也是服务端呢？（假装服务端同样的配置）显然这个是不行的，由于当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证实你是服务端域名的拥有者，而第三方攻击者是没法提供这些信息因此他就是没法骗CA他拥有属于服务端的域名

6、运用与总结

安全性考虑：

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

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

成本考虑：

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