跳至主要內容

HTTPS 协议学习总结

安全技术web安全基础知识约 5860 字大约 20 分钟

前言

最近在复习一些基础知识，顺带整理了一下https的有关内容。

什么是https？

https协议(Hyper Text Transfer Protocol over SecureSocket Layer)，翻译过来就是建立在安全套接字层上的超文本传输协议(http)，很显然，https是为了确保http协议的安全性而出现的。https在http的基础上加入了SSL协议(SSL3.1后称TLS)以下均称TLS，通过TLS协议使得http数据包能够安全的在网络中进行传输。现在大多数的站点都已经使用了https协议进行通信，也就是在浏览器中看到的所谓的小绿锁🔐。

image-20210202142221315
image-20210202142221315

为什么需要https？

通过上面的介绍可以知道，使用https是为了确保http通道的安全性，那么这个安全性究竟体现在哪里呢？

在说https所解决的安全问题之前，我们首先需要了解一种攻击手法: 中间人攻击

中间人攻击（英语：Man-in-the-middle attack，缩写：MITM）在密码学和计算机安全领域中是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。

从上述资料中可以知道，中间人攻击实际上就是攻击者监听并截获了通信双方的数据，对这些数据加以修改后代替原有的发送方将修改后的信息发送给原先的接收方，在这个过程中，中间人就相当于是一个”透明代理“，通信双方并不知道有这个”中间人“的存在。

而要成功的进行中间人攻击是有条件的：

一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端，并且不被其他终端识破。中间人攻击是一个（缺乏）相互认证的攻击。

回到http数据包网络通信过程中，我们知道http协议的数据是在传输层通过TCP协议进行封装传输的，而TCP协议在传输的过程中则是以明文形式进行的，也就是在http数据包在网络中明文"裸奔"。

http
http

TCP协议虽确保了通信双方的可靠交付但是并没有对通信双方进行身份认证，也就是说，http客户端并不知道与自己通信的是不是想要访问的"真实"服务端，因此就给中间人攻击提供了机会。

由于HTTP存在被中间人攻击的问题，人们在思考如何解决这一安全问题的时候提出了https协议，https协议通过SSL层对http数据包进行加密，同时使用数字证书等手段对通信双方的身份进行验证，较好的解决了这一安全问题。

https具体工作过程

通过上面的介绍可以知道，https是将http协议通过TLS的封装后的一种安全协议。http与https在网络传输过程中的基本结构如下

​

https协议在传输的过程中首先将http原始请求包经过TLS层进行加密封装再送入传输层进行TCP传输。

基础知识

在介绍https工作原理之前，我们需要简单的了解一些密码学的基础知识

对称加密

对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。

对称加密其特点主要是效率高、速度快，但是安全性差，由于加解密使用相同的密钥，因此密钥管理负担较重。主要算法有DES、3DES、AES、RC5、RC6等。

非对称加密

非对称加密加、解密使用不同的密钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。反之，私钥加密的信息，只有公钥才能解密。

非对称加密由于其加解密密钥不同而得名，其安全性更高，密钥管理方便。但是加密和解密耗时长，效率差。

与对称加密相比，非对称加密无需在客户端和服务端之间共享密钥，只要私钥不发送给任何用户，即是公钥在互联网上被截获，也无法被解密，而只有公钥是没有任何攻击价值的。常见的非对称加密算法有RSA等，非对称加解密过程：

  1. 服务端生成一堆公钥和私钥
  2. 私钥仅由服务端保存，公钥通过互联网发送给客户端。
  3. 客户端使用公钥加密明文并在网络中传输给服务端
  4. 服务端使用自己持有的私钥解密密文得到对应的明文

数字签名

在一封信中，文末的签名是为了表示这封信是签名者写的。计算机中，数字签名也是相同的含义：证明消息是某个特定的人，而不是随随便便一个人发送的（有效性）；除此之外，数字签名还能证明消息没有被篡改（完整性）。

简单来说，数字签名（digital signature）是公钥密码的逆应用：用私钥加密消息，用公钥解密消息。

用私钥加密的消息称为签名，只有拥有私钥的用户可以生成签名。
用公钥解密签名这一步称为验证签名，所有用户都可以验证签名(因为公钥是公开的)

签名的生成，一般来说，不直接对消息进行签名，而是对消息的哈希值进行签名，步骤如下。

  1. 对消息进行哈希计算，得到哈希值
  2. 利用私钥对哈希值进行加密，生成签名
  3. 将签名附加在消息后面，一起发送过去

签名的验证

  1. 收到消息后，提取消息中的签名
  2. 用公钥对签名进行解密，得到哈希值1。
  3. 对消息中的正文进行哈希计算，得到哈希值2。
  4. 比较哈希值1和哈希值2，如果相同，则验证成功。

简单地说，数字签名就是使用私钥去加密消息摘要得到的密文。

数字证书

证书实际上就是对公钥进行数字签名，它是对公钥合法性提供证明的技术。

数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。数字证书对网络用户在计算机网络交流中的信息和数据等以加密或解密的形式保证了信息和数据的完整性和安全性。

考虑这样一种场景：我们对签名进行验证时，需要用到公钥。如果公钥也是伪造的，那怎么办？如果公钥是假的，验证数字签名那就无从谈起，根本不可能从数字签名确定对方的合法性。

在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信，这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥，具体做法就是服务器不直接向客户端发送公钥，而是要求受信任的第三方，也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。数字证书一般包含以下内容：

  1. 证书所有者的公钥
  2. 证书所有者的专有名称
  3. 证书颁发机构的专有名称
  4. 证书的有效起始日期
  5. 证书的过期日期
  6. 证书数据格式的版本号
  7. 序列号，这是证书颁发机构为该证书分配的唯一标识符
image-20210205153627722
image-20210205153627722

接下来又有问题了：验证证书中的数字签名需要另一个公钥，那么这个公钥的合法性又该如何保证？该问题可以无限循环下去，岂不是到不了头了？这已经是个社会学问题了。我们为什么把钱存进银行？因为我们相信银行，它是一个可信的机构（虽然也有破产的风险）。跟银行一样，我们需要一个可信的机构来颁发证书和提供公钥，只要是它提供的公钥，我们就相信是合法的。

这种机构称为认证机构(Certification Authority， CA)。CA就是能够认定”公钥确实属于此人”，并能生成公钥的数字签名的组织或机构。CA有国际性组织和政府设立的组织，也有通过提供认证服务来盈利的组织。

image-20210205154525604
image-20210205154525604

证书链

证书链，也称为证书路径，是用于认证实体合法身份的证书列表，具体到 HTTPS 通信中，就是为了验证服务器的合法身份。之所以使用证书链，是为了保证根证书 的安全，中间层可以看做根证书的代理，起到了缓冲的作用。

从经典问题谈起

我们从一个经典的问题开始：当我们在浏览器中输入一个启用了https的域名到我们看到页面回显，发生了什么？

在以往http的情况下，这个问题的答案相信许多人已经非常清晰了，但是若目标站点启用了https，又会有什么不一样的地方呢？

带着这个问题，我们重新来分析一下这个“加强版”的经典面试题。

域名解析

由于web服务是建立在TCP协议之上的，因此需要使用ip地址来进行通信，而域名解析就是通过域名去DNS服务器查询获取对应的IP的过程，也是这个经典问题的第一步。

建立TCP连接

浏览器拿到对应域名的IP地址后，准备向目标服务器发起连接请求，由于我们是向web服务器发起连接，因此是通过TCP协议进行连接的，自然也就有TCP的三次握手建立连接的过程。我们可以通过wireshark抓包来查看这一过程。

image-20210209111021113
image-20210209111021113

通过设置简单的过滤器，访问https://annevi.cn即可获取到三次握手的过程。我们顺带来具体的看一下。

  1. 首先是客户端向服务器发送一个SYN，表示要求建立连接，同时发送Seq=0,随后客户端进入SYN-SENT阶段。
  2. 服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，构造一个[SYN ACK]的数据包，同时将ack值设为seq+1。随后服务器端进入SYN-RCVD阶段。
  3. 客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文,设置seq+=1 ack则等于服务器端数据包的seq+1,随后客户端进入ESTABLISHED阶段。

完成上述基本步骤后，一个完整的TCP连接就成功建立了

img
img

TLS握手*

为了建立安全连接，通信双方在完成TCP的三次握手之后，紧接着就要进行TLS的四次握手，TLS握手的目的主要是为了：

  • 商定双方通信所使用的的 TLS 版本 (例如 TLS1.0, 1.2, 1.3等等)；
  • 确定双方所要使用的密码组合；
  • 客户端通过服务器的公钥和数字证书上的数字签名验证服务端的身份；
  • 生成会话密钥，该密钥将用于握手结束后的对称加密。
img
img

下面将介绍一下TLS握手的过程

Client Hello

客户端生成并发送一段随机字符串以及所支持的加密算法，如图：

image-20210214185926765
image-20210214185926765
Server Hello

服务器发送"Server Hello"消息对客户端进行回应，该消息包含了数字证书，服务器选择的密码组合和"server random"随机字符串

image-20210214185419536
image-20210214185419536
验证

客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：

  1. 检查数字签名
  2. 验证证书链
  3. 检查证书的有效期
  4. 检查证书的撤回状态 (撤回代表证书已失效)
Pre-master secret

客户端在前面的步骤中已经获取到了服务端所给予的公钥，因此就可以发送使用这个公钥加密之后的另一个随机字符串"pre-master secret (预主密钥)"，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。

解密 Pre-master secret

服务器使用私钥解密Pre-master secret,获取其明文。

生成共享密钥

客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY，用于后面的对称加密传输。

客户端就绪

客户端发送经过共享密钥 KEY加密过的 finished信号。

服务端就绪

服务器发送经过共享密钥 **KEY **加密过的finished信号。

达成安全通信

握手完成，双方使用对称加密进行安全通信。

总结

总的来说，TLS的四次握手主要概括如下：

客户端发出请求，向服务端提供以下信息：

  1. 支持的协议版本，比如 TLS 1.0 版。
  2. 一个客户端生成的随机数，稍后用于生成"对话密钥"。
  3. 支持的加密方法，比如 RSA 公钥加密。
  4. 支持的压缩方法。

服务器回应以下信息：

  1. 确认使用的加密通信协议版本，比如 TLS 1.0 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  2. 确认使用的加密方法，比如 RSA 公钥加密，返回加密公钥
  3. 服务器证书

客户端回应

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

服务器

  1. 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证是否与浏览器发来的一致。
  2. 使用密码加密一段握手消息，发送给浏览器。
SSL : TLS 握手过程
SSL : TLS 握手过程

可以看到，https 建立连接需要7次握手(TCP 3次 TLS 4次)

TLS 的安全问题

OpenSSL心脏滴血漏洞

2014年4月8日，互联网上曝出了严重一个漏洞称为Heartbleed，该漏洞由安全公司Codenomicon和谷歌安全工程师发现。Heartbleed漏洞，造成许任何人在互联网上阅读系统的内存保护脆弱的OpenSSL的软件版本。 这种妥协密钥用于识别服务提供者和加密流量,用户名和密码的和实际的内容。 这允许攻击者窃听通信、窃取数据直接从服务和用户和模拟服务和用户。

原理

OpenSSL 在实现 TLS 和 DTLS 的心跳处理逻辑时，存在编码缺陷。OpenSSL 的心跳处理逻辑没有检测心跳包中的长度字段是否和后续的数据字段相符合，攻击者可以利用这点，构造异常的数据包，来获取心跳数据所在的内存区域的后续数据。这些数据中可能包含了证书私钥、用户名、用户密码、用户邮箱等敏感信息。该漏洞允许攻击者，从内存中读取多达64KB的数据。

常见场景

  • 使用了openssl扩展库加密的网络协议
  • https
  • SSL VPN
  • 邮件服务器

测试方案

nmap

nmap -sV -p 443 --script ssl-heartbleed.nse [Target]

https://filippo.io/Heartbleed/

http://wangzhan.360.cn/heartbleed/

Downgrade（降级攻击）

降级攻击是一种对计算机系统或者通信协议的攻击，在降级攻击中，攻击者故意使系统放弃新式、安全性高的工作方式，反而使用为向下兼容而准备的老式、安全性差的工作方式，降级攻击常被用于中间人攻击，讲加密的通信协议安全性大幅削弱，得以进行原本不可能做到的攻击。 在现代的回退防御中，使用单独的信号套件来指示自愿降级行为，需要理解该信号并支持更高协议版本的服务器来终止协商，该套件是 TLS_FALLBACK_SCSV(0x5600)

MITM（中间人攻击）

MITM(Man-in-the-MiddleAttack) ，是指攻击者与通讯的两端分别创建独立的联系，并交换其所有收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个对话都被攻击者完全控制，在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。一个中间人攻击能成功的前提条件是攻击者能够将自己伪装成每个参与会话的终端，并且不被其他终端识破。

BEAST (野兽攻击）

BEAST(CVE-2011-3389) BEAST是一种明文攻击，通过从SSL/TLS加密的会话中获取受害者的COOKIE值（通过进行一次会话劫持攻击），进而篡改一个加密算法的 CBC（密码块链）的模式以实现攻击目录，其主要针对TLS1.0和更早版本的协议中的对称加密算法CBC模式。

CRIME（罪恶攻击）

CRIME(CVE-2012-4929)，全称Compression Ratio Info-leak Made Easy，这是一种因SSL压缩造成的安全隐患，通过它可窃取启用数据压缩特性的HTTPS或SPDY协议传输的私密Web Cookie。在成功读取身份验证Cookie后，攻击者可以实行会话劫持和发动进一步攻击。

SSL 压缩在下述版本是默认关闭的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 OpenSSL 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用较旧版本的 OpenSSL）。

如果你使用一个早期版本的 nginx 或 OpenSSL，而且你的发行版没有向后移植该选项，那么你需要重新编译没有一个 ZLIB 支持的 OpenSSL。这会禁止 OpenSSL 使用 DEFLATE 压缩方式。如果你禁用了这个，你仍然可以使用常规的 HTML DEFLATE 压缩。

POODLE漏洞（卷毛狗攻击）

2014年10月14号由Google发现的POODLE漏洞，全称是Padding Oracle On Downloaded Legacy Encryption vulnerability，又被称为“贵宾犬攻击”（CVE-2014-3566），POODLE漏洞只对CBC模式的明文进行了身份验证，但是没有对填充字节进行完整性验证，攻击者窃取采用SSL3.0版加密通信过程中的内容，对填充字节修改并且利用预置填充来恢复加密内容，以达到攻击目的。

TLS POODLE（TLS卷毛狗攻击）

TLS POODLE(CVE-2014-8730) 该漏洞的原理和POODLE漏洞的原理一致，但不是SSL3协议。由于TLS填充是SSLv3的一个子集，因此可以重新使用针对TLS的POODLE攻击。TLS对于它的填充格式是非常严格的，但是一些TLS实现在解密之后不执行填充结构的检查。即使使用TLS也不会容易受到POODLE攻击的影响。

CCS

CCS(CVE-2014-0224) 全称openssl MITM CCS injection attack，Openssl 0.9.8za之前的版本、1.0.0m之前的以及1.0.1h之前的openssl没有适当的限制ChangeCipherSpec信息的处理，这允许中间人攻击者在通信之间使用0长度的主密钥。

FREAK

FREAK(CVE-2015-0204) 客户端会在一个全安全强度的RSA握手过程中接受使用弱安全强度的出口RSA密钥，其中关键在于客户端并没有允许协商任何出口级别的RSA密码套件。

DROWN（溺水攻击/溺亡攻击）

2016年3月发现的针对TLS的新漏洞攻击——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用过时的、弱化的一种RSA加密算法来解密破解TLS协议中被该算法加密的会话密钥。 具体说来，DROWN漏洞可以利用过时的SSLv2协议来解密与之共享相同RSA私钥的TLS协议所保护的流量。 DROWN攻击依赖于SSLv2协议的设计缺陷以及知名的Bleichenbacher攻击。

通常检查以下两点服务器的配置

  • 服务器允许SSL2连接，需要将其关闭。
  • 私钥同时用于允许SSL2连接的其他服务器。例如，Web服务器和邮件服务器上使用相同的私钥和证书，如果邮件服务器支持SSL2，即使web服务器不支持SSL2，攻击者可以利用邮件服务器来破坏与web服务器的TLS连接。

Openssl Padding Oracle

Openssl Padding Oracle(CVE-2016-2107) openssl 1.0.1t到openssl 1.0.2h之前没有考虑某些填充检查期间的内存分配，这允许远程攻击者通过针对AES CBC会话的padding-oracle攻击来获取敏感的明文信息。

参考资料

  • https://segmentfault.com/a/1190000012731888
  • https://segmentfault.com/a/1190000021559557
  • https://zhuanlan.zhihu.com/p/22142170
  • https://juejin.cn/post/6844904089495535624#heading-14
  • https://zhuanlan.zhihu.com/p/22917510
  • https://payloads.online/archivers/2018-04-27/5
上次编辑于: 2024/10/15 09:42:43
贡献者: anneviliu