Skip to content

Latest commit

 

History

History
193 lines (107 loc) · 14.1 KB

Http与Https的区别.md

File metadata and controls

193 lines (107 loc) · 14.1 KB
Raw

HTTP与HTTPS的区别

HTTP(超文本传输协议)

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

  • 1997年发布HTTP/1.1: 持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码。

    长连接是指的TCP连接，也就是说复用的是TCP连接。即长连接情况下，多个HTTP请求可以复用同一个TCP连接，这就节省了很多TCP连接建立和断开的消耗。

    此外，长连接并不是永久连接的。如果一段时间内（具体的时间长短，是可以在header当中进行设置的，也就是所谓的超时时间），这个连接没有HTTP请求发出的话，那么这个长连接就会被断掉。

  • 2015年发布HTTP/2:多路复用、服务器推送、头信息压缩、二进制协议等。

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

缺点:

  • 通信使用明文（不加密），内容可能会被窃听
  • 不验证通信方的身份，因此有可能遭遇伪装
  • 无法证明报文的完整性，所以有可能已遭篡改

优点:

  • 传输速度快

HTTP请求响应过程

你是不是很好奇，当你在浏览器中输入网址后，到底发生了什么事情？你想要的内容是如何展现出来的？让我们通过一个例子来探讨一下，我们假设访问的 URL 地址为 http://www.someSchool.edu/someDepartment/home.index，当我们输入网址并点击回车时，浏览器内部会进行如下操作

  • DNS服务器会首先进行域名的映射，找到访问www.someSchool.edu所在的地址，然后HTTP客户端进程在80端口发起一个到服务器www.someSchool.edu的TCP连接（80端口是HTTP的默认端口）。在客户和服务器进程中都会有一个套接字与其相连。
  • HTTP客户端通过它的套接字向服务器发送一个HTTP请求报文。该报文中包含了路径someDepartment/home.index的资源，我们后面会详细讨论HTTP请求报文。
  • HTTP服务器通过它的套接字接受该报文，进行请求的解析工作，并从其存储器(RAM 或磁盘)中检索出对象 www.someSchool.edu/someDepartment/home.index，然后把检索出来的对象进行封装，封装到HTTP响应报文中，并通过套接字向客户进行发送。
  • HTTP服务器随即通知TCP断开TCP连接，实际上是需要等到客户接受完响应报文后才会断开TCP连接。
  • HTTP客户端接受完响应报文后，TCP连接会关闭。HTTP客户端从响应中提取出报文中是一个HTML响应文件，并检查该HTML文件，然后循环检查报文中其他内部对象。
  • 检查完成后，HTTP客户端会把对应的资源通过显示器呈现给用户。

至此，键入网址再按下回车的全过程就结束了。上述过程描述的是一种简单的请求-响应全过程，真实的请求-响应情况可能要比上面描述的过程复杂很多。

HTTPS

Https并非是应用层的一种新协议。只是http通信接口部分用SSL(安全套接字层)和TLS(安全传输层协议)代替而已。即添加了加密及认证机制的HTTP称为HTTPS(HTTP Secure).

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

如何保证安全

一般来说网络安全关心三个问题:CIA(confidentiality, integrity, availability).
那https在这三方面做的怎么样呢？

  • https保证了confidentiality（你浏览的页面的内容如果被人中途看见，将会是一团乱码。不会发生比如和你用同一个无线网的人收到一个你发的数据包，打开来一看，就是你的密码啊银行卡信息啊)
  • intergrity(你浏览的页面就是你想浏览的，不会被黑客在中途修改，网站收到的数据包也是你最初发的那个，不会把你的数据给换掉，搞一个大新闻)
  • 最后一个availability几乎没有提供（虽然我个人认为会增加基础DOS等的难度，但是这个不值一提），不过https还提供了另一个A，authentication(你连接的是你连接的网站，而不是什么人在中途伪造了一个网站给你，专业上叫Man In The Middle Attack)。
    那https具体保护了啥？简单来说，保护了你从连接到这个网站开始，到你关闭这个页面为止，你和这个网站之间收发的所有信息，就连url的一部分都被保护了。同时DNS querying这一步也被保护了， 不会发生你输入www.google.com实际上跑到了另一个网站去了。

使用两把密钥的公开密钥加密

公开密钥加密使用一对非对称的密钥。一把叫做私钥，另一把叫做公钥。私钥不能让其他任何人知道，而公钥则可以随意发布，任何人都可以获得。使用公钥加密方式，发送密文的一方使用对方的公钥进行加密处理，对方收到被加密的信息后，再使用自己的私钥进行解密。利用这种方式，不需要发送用来解密的私钥，也不必担心密钥被攻击者窃听而盗走。

过程

  • 服务器把自己的公钥登录至数字证书认证机构。
  • 数字证书机构把自己的私有密钥向服务器的公开密码部署数字签名并颁发公钥证书。
  • 客户端拿到服务器的公钥证书后，使用数字证书认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名。以确认服务器公钥的真实性。
  • 使用服务器的公开密钥对报文加密后发送。
  • 服务器用私有密钥对报文解密。

HTTPS通信的步骤

  • 客户端发送报文进行SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表（加密算法及密钥长度等）。
  • 服务器应答，并在应答报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接受到的客户端加密组件内筛选出来的。
  • 服务器发送报文，报文中包含公开密钥证书。
  • 服务器发送报文通知客户端，最初阶段SSL握手协商部分结束。
  • SSL第一次握手结束之后，客户端发送一个报文作为回应。报文中包含通信加密中使用的一种被称Pre-master secret的随机密码串。该密码串已经使用服务器的公钥加密。
  • 客户端发送报文，并提示服务器，此后的报文通信会采用Pre-master secret密钥加密。
  • 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够完成成功，要以服务器是否能够正确解密该报文作为判定标准。
  • 服务器同样发送Change Cipher Spec报文。
  • 服务器同样发送Finished报文。
  • 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。
  • 应用层协议通信，即发送HTTP响应。
  • 最后由客户端断开链接。断开链接时，发送close_nofify报文。

HTTPS的工作原理

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下:

  • 浏览器将自己支持的一套加密规则发送给网站。

  • 网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

  • 获得网站证书之后浏览器要做以下工作:

    • 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
    • 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
    • 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

  • 网站接收浏览器发来的数据之后要做以下的操作:

    • 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
    • 使用密码加密一段握手消息，发送给浏览器。

  • 浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。另外，HTTPS一般使用的加密与HASH算法如下:

  • 非对称加密算法:RSA，DSA/DSS
  • 对称加密算法:AES，RC4，3DES
  • HASH算法:MD5，SHA1，SHA256

其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输。正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，于是更多的是采用了假证书的手法来欺骗客户端，从而获取明文的信息，但是这些手段都可以被识别出来，

优点

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处:

  • 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
  • HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
  • HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
  • 谷歌曾在2014年8月份调整搜索引擎算法，并称比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高。

缺点

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的:

  • HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
  • HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
  • SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
  • SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
  • HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

Https 请求慢的解决办法

  1. 不通过DNS解析，直接访问IP

  2. 解决连接无法复用

    http/1.0协议头里可以设置Connection:Keep-Alive或者Connection:Close，选择是否允许在一定时间内复用连接（时间可由服务器控制）。但是这对App端的请求成效不大，因为App端的请求比较分散且时间跨度相对较大。

    方案1.基于tcp的长连接 (主要） 移动端建立一条自己的长链接通道，通道的实现是基于tcp协议。基于tcp的socket编程技术难度相对复杂很多，而且需要自己定制协议。但信息的上报和推送变得更及时，请求量爆发的时间点还能减轻服务器压力（避免频繁创建和销毁连接）

    方案2.http long-polling 客户端在初始状态发送一个polling请求到服务器，服务器并不会马上返回业务数据，而是等待有新的业务数据产生的时候再返回，所以链接会一直被保持。一但结束当前连接，马上又会发送一个新的polling请求，如此反复，保证一个连接被保持。 存在问题： 1）增加了服务器的压力 2）网络环境复杂场景下，需要考虑怎么重建健康的连接通道 3）polling的方式稳定性不好 4）polling的response可能被中间代理cache住 ……

    方案3.http streaming 和long-polling不同的是，streaming方式通过再server response的头部增加“Transfer Encoding:chuncked”来告诉客户端后续还有新的数据到来 存在问题： 1）有些代理服务器会等待服务器的response结束之后才将结果推送给请求客户端。streaming不会结束response 2）业务数据无法按照请求分割 ……

    方案4.web socket 和传统的tcp socket相似，基于tcp协议，提供双向的数据通道。它的优势是提供了message的概念，比基于字节流的tcp socket使用更简单。技术较新，不是所有浏览器都提供了支持。