【网络】计算机网络笔记——HTTPS 协议笔记

HTTPS 协议可以理解为 HTTP Secure,它并不是一个新协议,实际上仍然是通过 HTTP 协议进行通讯,只是同时利用 TLS/SSL 来加密封包,从而相比 HTTP 协议实现了更好的安全性。

可以说,HTTPS = HTTP + 加密 + 认证 + 完整性保护

HTTP 的缺点

在了解 HTTPS 之前,我们先来讨论一下 HTTP 协议有什么缺点。它的不足主要体现在以下几个方面:

  • 通信通过明文进行传输,不进行加密,容易被窃听
  • 并不会对双方的身份进行验证,可能被恶意主机伪装
  • 无法验证报文完整性,可能遭到篡改

窃听问题

由于 HTTP 协议并不提供加密的功能,因此无法对通信数据整体进行加密(请求信息和请求数据),因此它是采用明文进行传输的。这样的明文传输意味着在通信线路上任何一个位置都可以对通信内容进行窃听。

因此我们需要引入对信息的加密处理,加密的目的不是让窃听方看不到,而是让它看不懂,即使它窃听到了通信的内容,也无法破解数据包的信息。

要实现对内容的加密,我们有两种方式,对整个通信的加密和对数据内容的加密。

对通信整体的加密

由于 HTTP 协议并没有提供加密的机制,因此需要通过 SSL(Secure Socket Layer)安全套接字层TLS(Transport Layer Sercurity)安全层传输协议 的配合使用来对 HTTP 的通信内容进行加密。

通过 SSL 建立一条安全通信的线路后,我们就可以通过这条线路进行 HTTP 通信了,HTTP + SSL 也就构成了 HTTPS,也就是 HTTP over SSL。

image-20191224102702657

对数据内容加密

由于 HTTP 协议不提供加密机制,因此还可以仅仅对通信的内容进行加密,也就是仅仅对传递给 HTTP 的数据内容进行加密,这种情况下需要客户端对内容进行加密后,再交由 HTTP 协议处理。

由于这种方式没有对 HTTP 的报文本身进行加密,因此仍然有被篡改的风险

伪装问题

由于在 HTTP 协议中,我们并没有对通信的双方进行确认,因此实际上存在着如下的隐患:

  • 无法确定服务器是否是请求的 URI 对应的真正主机,
  • 无法确定返回的响应是否返回给了真正发送请求的客户端。
  • 无法确定通信的对方是否具有访问权限。
  • 无法判断请求的源头。
  • 无法阻止海量请求下的 DOS 攻击。

SSL 证书

通过 HTTP 协议显然无法确定通信方的身份,但是我们可以通过 SSL 实现,它不但提供了加密机制,还引入了一种 SSL 证书,用于确定对方的身份。

SSL 证书由一些值得信任的第三方机构统一进行颁发,可以用于证明服务器和客户端的身份,并且它难以进行伪造。

在客户端开始通信前,会首先通过证书验证对方身份,确认是自己真正的目的主机后,才会将数据发送。

篡改问题

HTTP 协议无法证明报文的完整性,无法确定报文在传递过程中是否遭到了篡改,因此存在着一种被『中间人攻击』的风险。

这样的恶意中间人会对 HTTP 传输的信息进行篡改,达到一些恶意的目的。

防止篡改

防止篡改可以通过 MD5、SHA-1 这种 hash 算法来进行校验,从而使得客户端可以确认自己收到的是不是正确的内容(这就是为什么有时候下载文件的网站还会提供该文件的 SHA-1 码的原因)。

但这些方式都需要用户自行进行验证,无法让浏览器自动帮助用户进行检查。

因此,可以使用 HTTPS 来实现,SSL 还提供了一种摘要的功能,通过摘要功能同样可以实现防篡改功能。

HTTPS

HTTPS 实际上就是 HTTP over SSL,它实际上就是披上了 SSL 外壳的 HTTP。在 HTTPS 协议的通信中,HTTP 不再直接与 TCP 进行通信,而是经过了 SSL 这一中间层,与 TCP 进行通信。通过这一 SSL 层,HTTP 协议就具备了加密身份验证完整性保护的功能。

不只是 HTTP 协议,像 SMTP、Telnet 等应用层协议,都可以通过加入 SSL 层,来实现安全通信。

加密方式

对称加密

对称加密只需要服务端和客户端双方都持有同样的一个密钥,服务端通过密钥对明文进行加密,之后传递给客户端。客户端收到加密后的数据后,通过同样的密钥进行解密,就可以获取到原始的数据。

它的加密速度和解密速度是很快的,但仍然存在不足之处:由于密钥是需要服务端与客户端进行同步的,那就意味着密钥需要从其中一方传递给另外一方。在这个传输的过程中密钥仍然存在被截取的风险。一旦密钥被截取,那么对称加密就没有意义了。

也就是说,传递数据的被截取风险变为了传递密钥的被截取风险。

常见的对称加密的算法有:AES、DES、3DES、TDEA、Blowfish、RC4、RC5、IDEA 等。

非对称加密

非对称加密的思路是通过让服务端和客户端各持有一个自己的公钥和私钥实现的。公钥对外是公开的,而私钥则只有自己知道。

它有着这样的规则:

  • 用公钥加密的数据只有通过私钥才能解开,这往往用于信息的加密解密。
  • 用私钥加密的数据只有通过公钥才能解开,这往往用于身份的验证。

例如一个信息传递过程就变成了这样:

  • 客户端向服务端发起请求,服务端将自己的公钥返回给客户端。
  • 客户端收到服务端的公钥,用它对数据进行加密后发送给服务端。
  • 服务端收到加密数据后,用只有自己知道的私钥对数据进行解密。

非对称加密可以保证安全性,信息难以被截取。但它的不足之处在于加密速度相对较慢,加密算法复杂。

常见的非对称加密算法有:RSA、DSA/DSS、Elgamal、Rabin、D-H、ECC 等。

HTTPS 中的加密方式

为了兼顾安全和效率,HTTPS 同时使用了对称加密与非对称加密

它采用的策略是,对 HTTP 数据包通过对称加密

对于对称加密的密钥,则采用非对称加密

身份验证

仅仅依靠加密,仍然存在一定问题,因为客户端无法确保服务端的公钥就是自己需要的目的服务端的公钥。

因此,客户端还需要对服务端给的密钥进行身份验证,这个验证通过数字证书认证机构(CA)所颁发的公钥证书实现。

数字证书认证机构是一种服务端和客户端都信任的机构,客户端可以通过它们颁发的证书,对服务端的公钥进行验证。

数字认证流程

数字认证的流程如下:

  1. 服务器方向 CA 机构提出公钥的申请,将公钥和一些相关信息交给 CA 机构。
  2. CA 机构认证服务器方的身份后,会对申请的信息(包括公钥)用自己的私钥加密从而生成一个数字证书,之后将数字证书返还给服务器方。
  3. 服务器会将这个 CA 机构颁发的数字证书发给客户端,收到证书的客户端会通过 CA 机构的公钥来对数字证书进行解密从而进行身份验证并获取公钥。
  4. 一旦验证通过,客户端便可明确两件事: 一,认证服务器的公开密钥的是真实有效的数字证书认证机构。二, 服务器的公开密钥是值得信赖的。

这个 CA 机构的公钥往往是浏览器、操作系统所内置的,因此可以保证是值得信赖的。

通信过程

因此,一次 HTTPS 协议下的请求,就需要经过这样的过程:

  1. 获取公钥:客户端向服务端发起 HTTPS 请求,端口为 443 端口。服务端返回 CA 机构颁布的数字证书给客户端。
  2. 身份验证:客户端收到数字证书通过 CA 机构的公钥进行解密,从而进行身份验证并获取公钥。
  3. 生成共享密钥:客户端确认公钥安全性后,生成一串随机数作为共享密钥。
  4. 发送加密共享密钥:客户端对生成的共享密钥通过服务端公钥进行加密,之后发送给服务端。
  5. 返回数据:服务端对客户端的数据进行非对称解密得到共享密钥,将要传输的信息通过它进行加密,之后发送给客户端
  6. 解析数据:客户端收到数据后,对其通过共享密钥进行对称解密,得到服务端返回的数据。

其具体过程如下(出自《图解 HTTP》):

  1. SSL 握手
    1. 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。
    2. 服务器可进行 SSL 通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
    3. 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
    4. 服务器发送 Server Hello Done 报文通知客户端,最初阶段的 SSL 握手协商部分结束。
  2. SSL 连接建立
    1. SSL 第一次握手结束之后,客户端以 Client Key Exchange 报文作为回应。报文中包含一个经过服务器公钥加密的随机密码串,它就是共享密钥
    2. 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器此后的报文会采用共享密钥加密。
    3. 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准。
    4. 服务器同样发送 Change Cipher Spec 报文。
    5. 服务器同样发送 Finished 报文。
    6. 服务器和客户端的 Finished 报文交换完毕之后,SSL 连接就成功建立。
  3. 数据通信
    1. 开始进行应用层协议的通信,即发送 HTTP 请求。
    2. 服务器返回 HTTP 响应。

在以上流程中,应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡改,从而保护报文的完整性。

这个报文摘要其实也是一种 hash 算法,只是 SSL 层会自动地进行处理,对完整性进行验证,而不再需要用户自行处理。

SSL 与 TLS 的关系

HTTPS 使用了 SSL 和 TLS 两个协议,SSL 由网景公司首先倡导,负责了 SSL3.0 之前的开发。

而 SSL 协议目前交由 IETF 进行管理,IETF 以 SSL3.0 为基础,先后制定了 TLS1.0、TLS1.1 等。

因此 TLS 是以 SSL 为原型开发的协议。一般我们可以把它们视为同一种协议,简称 SSL。

为何没有将 HTTP 全部替换为 HTTPS

既然 HTTPS 具有安全可靠的特性,为何没有被广泛应用呢?

  • HTTPS 虽然提高了 HTTP 请求的安全性,但同时加密、解密、证书的验证也带来了效率的影响。
  • 很多服务器提供的数据并不那么迫切的需要安全性,它们仅仅需要传输一些简单的信息,对安全性并没有那么敏感。
  • CA 机构提供的数字证书是需要花钱购买的,因此有的服务器并不想要花这笔钱。

总结

HTTPS 实质上是指 HTTP over SSL,并不是一个全新的协议,它在 HTTP 与 TCP 之间加入了一层 SSL 层,通过 SSL 层可以实现加密身份验证完整性校验功能,从而解决 HTTP 存在的窃听伪装篡改问题。

窃听问题:HTTPS 的加密采用了一种对称与非对称加密的结合的混合加密,来保证报文的安全性,不会被恶意的中间人所窃听。通过对称加密对 HTTP 报文内容进行加密,而对称加密的密钥则通过非对称加密进行传输,从而保证了安全性。

伪装问题:为了保证公钥是来自目标服务端,需要通过 CA 机构颁发的数字证书来进行验证,这个数字证书中包含了服务端的公钥信息,并由 CA 机构的私钥进行了加密。操作系统、浏览器中往往自带了很多 CA 机构的公钥,只需要通过这些 CA 机构的公钥对获取到的数据进行解密,即可进行公钥的身份验证并获取公钥。

篡改问题:通过在数据发送前通过 hash 算法生成一个摘要,每当收到数据后对数据进行同样的 hash 从而生成验证摘要,对这个验证摘要与发送过来的摘要进行比对,即可判断数据的完整性,从而防止篡改。

TLS 协议实际上就是基于 SSL 协议实现的,可以理解为 SSL 协议的后续版本。

参考资料

《图解 HTTP》

【网络协议】HTTPS协议浅析

点赞

发表评论

电子邮件地址不会被公开。必填项已用 * 标注

%d 博主赞过: