飞道的博客

【网络】HTTPS协议详解

2022-11-02 17:59 358人阅读  评论(0)

😀大家好，我是白晨，一个不是很能熬夜😫，但是也想日更的人✈。如果喜欢这篇文章，点个赞👍，关注一下👀白晨吧！你的支持就是我最大的动力！💪💪💪

文章目录

📗前言

前面的文章我们已经介绍了HTTP协议（对于HTTP还不太了解的同学可以先去学习HTTP协议），但是如果你现在经常上网，你就会发现很多协议的前面都是https，而不是http。

https://blog.csdn.net/baichendada/article/details/126925361

上面就是一个常见的博客链接，可以看到，CSDN使用的就是HTTPS协议，那么为什么现在很多企业都会选则使用HTTPS协议，HTTPS和HTTP协议有什么相同点和不同点，HTTPS协议又好在哪里呢？

以上问题，我将会在下面详细展开说明，相信阅读完这篇文章，你会对应用层协议有更深一层的认识。

📘HTTPS协议

♟️1. HTTP协议的弊端

HTTP由于它的简洁快速而被广泛使用，但是简洁快速也意味着功能上的不完善。HTTP协议有三大弊病阻碍了HTTP协议的发展。

  • 通信时使用明文，可能被窃听

由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密。即HTTP 报文使用明文（指未经过加密的报文）方式发送。

前面我们讲解了TCP/IP协议的五层模型，我们知道，HTTP属于应用层，需要通过物理层进行传输，而报文在物理层传输的时候是任何机器都可以进行获取的，相当于数据在网线上裸奔。这时如果有一个恶意的中间人疯狂进行抓包，那么这个中间人就会拿到你的报文，更为糟糕的是，你的报文是没有进行加密的。中间人拿到报文后，就可以读取到你的私人信息。

  • HTTP协议不会验证通信方身份

HTTP协议不仅是无状态的协议，更难受的是HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等类似问题。

这样的话，任何人只要知道服务器公网的地址就可以对其进行访问，可能会出现以下问题：

  • 用户无法确定自己访问的服务器是 自己想访问的服务器 还是 伪装过的恶意服务器。
  • 服务器无法确定自己发送出去的报文是被 真实的用户 还是 恶意伪装的客户端 接收到了。
  • 服务器上可能存在只有特定用户才能访问的资源，但是身份无法验证可能会导致资源外泄。
  • 服务器即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS攻击（Denial of Service，拒绝服务攻击）。
  • 无法证明报文的完成性，无法判断报文是否已遭到篡改

由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内， 即使请求或响应的内容遭到篡改，也没有办法获悉。换句话说，没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。

比如，有一个恶意的中间人把你的报文进行抓包，并且修改报文内容，用你的身份对服务器进行恶意攻击，这就完成了一次劫持攻击。 像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（ Man-in-the-Middle attack， MITM）。

🃏2. HTTPS相关知识

2.1 加密解密相关知识

  • 对称加密

加密和解密同用一个密钥的方式称为共享密钥加密（ Common key crypto system），也被叫做对称密钥加密。

我们可以使用对称加密对HTTPS报文进行加密，这样就可以保证传输时，即使被中间人窃取，其中的内容也不会泄露。

但是对称加密有一个很大的弊端，就是密钥一旦被中间人获取，那么一切信息都将会被窃取。你可能会说，那我让密钥不泄露不就可以了？

真的会这么简单吗？试想一下你正在和一个网站进行通信，如果要让中间人拿不到密钥，那么密钥肯定不能是公开的。一般来说，每个网站都会有自己的加密机制，所以我们首先要拿到这个密钥。这就出现了一个很严重的问题，密钥该如何在网络上进行传输。如果使用明文传输，那么密钥很容易就会被获取，后面的加密对于中间人相当于透明；如果服务端一开始使用密钥加密，那么客户端根本就解密不了，就成了蛋生鸡、鸡生蛋的问题。

所以，单独的对称加密是无法做到传输信息安全的。

  • 非对称加密

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

非对称加密的特性：

  • 对于一个公钥，有且只有一个对应的私钥。
  • 公钥是公开的，并且不能通过公钥反推出私钥。
  • 通过私钥加密的密文只能通过公钥能解密，通过公钥加密的密文也只能通过私钥能解密。

另外，公钥和私钥具有数学上的联系，要想根据密文和公开密钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值， 这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

这种方式就可以解决第一次通信的问题，客户可以通过公钥对报文进行加密，服务端会通过私钥进行解密，这样就可以获取到用户的信息。那么，用户如何解密服务器的报文呢？或者说非对称加密只实现了单向安全，如何才能保证双方通信安全呢？

这个问题白晨会在后续展开，接着继续探索吧。（点击跳转到答案）

2.2 数据签名

  • 数据摘要

数字摘要是将任意长度的消息变成固定长度的短消息，它类似于一个自变量是消息的函数，也就是Hash函数。数字摘要就是采用单向Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的字符串。这一串字符串又称为数字指纹，它有固定的长度，而且不同的明文摘要成字符串，其结果总是不同的，而同样的明文其摘要必定一致。

这里要强调一点，Hash散列不是加密算法，因为它根本不需要解密，只需要验证（用同一份明文生成同一份字符串，不同明文生成的字符串总是不同）。

常见的摘要算法：

  • MD5：是RSA数据安全公司开发的一种单向散列算法，MD5被广泛使用，可以用来把不同长度的数据块进行暗码运算成一个固定位位的数值（通常是128位）。

简单来说，数字摘要就是通过对一串数据进行Hash散列处理，使其生成一串固定长度的字符串。

  • 数据签名

对于数据签名要进行加密生成的一串密文被称为数据签名。 它的作用是验证发送端的身份和报文的完整性。

HTTP不能验证报文的完整性和判断报文是否被修改，如果使用数据签名，客户端将要发送的明文通过Hash散列和加密算法生成对应的数据签名，将要发送的明文加密后和数据签名一起发送，服务端通过解密算法拿到明文以及数据摘要（数据签名解密以后就是数据摘要），服务端通过同样的Hash散列算法对明文求其数据摘要。如果两个摘要相等，说明报文完整，未被篡改过，反之，说明数据不完整或者被篡改了。

2.3 数字证书

数字证书这一名词来自于英文digital certificate的翻译。数字证书从本质上来说是一种电子文档，是由数字证书认证机构（ CA， Certificate Authority）和其相关机关颁发的公开密钥证书。

这里要强调的是 CA 并不是一个特定的机构，而是数字证书认证机构的统称，国内外都有。CA机构更是只有少数权威的，很多中级CA机构和个人认证机构发布的证书都会被浏览器识别为虚假证书，并且也只有少数权威机构颁布证书会被浏览器保存。

数字证书的所包含的内容有：

  • 申请者的基本信息：域名等

  • 证书颁发机构的名称

  • 证书本身的数字签名

  • 证书申请者的公钥

  • 证书签名用到的Hash算法等

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。我们来介绍一下数字证书认证机构的业务流程：

  1. 服务器的运营人员向数字证书认证机构提出公开密钥的申请。
  2. 数字证书认证机构在判明提出申请者的身份之后，会用数字证书认证机构的私钥对已申请的公开密钥做数据签名，然后分配这个已签名的公开密钥， 并将该公开密钥放入公钥证书后绑定在一起。
  3. 客户端需要证书时，客户端将会将证书传输给客户端以验证自己的身份。

有了数字证书就可以验证对方的身份并且可以拿到对方放出的加密公钥。那么，拿到对面证书的时候，如何保证他不是伪造的或者是被篡改过的呢？

证书内容中含有证书本身的数字签名以及签名所用到的Hash算法，验证时，证书的明文经过Hash算法得到数字摘要，数字签名用数字证书认证机构的公开密钥（提前获得）进行解密得到数字摘要，两个数字摘要进行对比，相同则证书完整。

2.4 SSL/TSL

SSL/TLS是一种密码通信框架，他是世界上使用最广泛的密码通信方法。SSL/TLS综合运用了密码学中的对称密码，消息认证码，公钥密码，数字签名，伪随机数生成器等，可以说是密码学中的集大成者。

SSL(Secure Socket Layer)安全套接层，是1994年由Netscape公司设计的一套协议，并与1995年发布了3.0版本。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TLS(Transport Layer Security)传输层安全，是IETF在SSL3.0基础上设计的协议，实际上相当于SSL的后续版本。

TLS可以视为SSL的升级版，以后会用SSL协议统称SSL和TLS。当前主流的版本是 SSL3.0 和 TLS1.0 。

HTTP协议是直接和TCP/IP协议打交道的，这样的话安全性得不到保证，为了让HTTP协议具有安全的特性，让HTTP协议先通过SSL协议，进行加密、认证、验证完整性，保证HTTP的安全性，再让SSL协议和TCP/IP打交道，这样就能保证数据安全。

用一张图来简单理解SSL协议基本结构：

在正式讲解HTTPS协议之前，必须先讲一下SSL协议的握手过程。

  • SSL握手过程

首先要解释一下什么是握手，类似于两个人初识，会相互问对方是哪里人，工作是什么等，客户端和服务端打交道的时候必须先沟通双方使用的编码格式，使用的加密算法等，这样相互交换基本信息，为接下来通信确定通信方式的过程就叫做握手。

握手过程一共分为5步：

  1. 客户端给出协议版本号、一个由客户端生成的随机数（Client random）以及客户端支持的加密算法。
  2. 服务端确认双方使用的加密方法，并发送数字证书以及一个服务器生成的随机数给客户端（Server random）。
  3. 客户端确认证书有效（具体验证过程见这里），然后生成一个新的随机数（Premaster secret），接着使用从证书中获取的公钥，加密这个随机数，发送给服务端。
  4. 服务端用自己的私钥解密这个随机数，获取Premaster secret。
  5. 客户端和服务端根据约定的加密方法，使用前面的三个随机数，生成接下来通信要使用的会话密钥（Session key），会话密钥是一个对称密钥，接下来的通信将使用会话密钥。

上述过程关于密钥有三点值得注意：

  1. 服务端公钥存放在服务端注册的数字证书中。
  2. 服务端的公钥和私钥只在握手阶段使用，在生成会话密钥后，以后的通信全部都是使用会话密钥进行对称加密和解密。
  3. 生成会话密钥需要三个随机数——Client random、Server random、Premaster secret。

这里要特别注意：握手阶段的通信都是明文的，如果有中间人进行抓包，就可以知道双方选择的加密方式，所以，第一个和第二个随机数是很容易被获取的。因此，加密的关键就在了第三个随机数（Premaster secret）上，这个随机数传输使用了非对称加密，所以几乎是不可能被获取的，这样也就保障了通信安全。

  • SSL的劣势

SSL需要消耗大量的内存和CPU资源来对数据进行加密和解密，这样会大大降低通信的效率，提升通信的时长。所以HTTPS的通信效率是不如HTTP的效率的，这有什么解决办法吗？

在软件方面，要么就是优化加密解密算法，使其占用的资源减少，但是过于简单的加密解密算法又会被轻易的攻破，所以在密码学取得更大的突破之前这个做法是不可取的。现在唯一的方法就是提升硬件的算力，或者使用针对于SSL优化的硬件。

  • SSL具体通信过程

只作为了解部分，有时间的朋友们可以详细了解一下。

🪅3. HTTPS协议

HTTPS （全称：Hypertext Transfer Protocol Secure ），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 。

以上定义来自于百度百科，简单的理解就是 HTTPS 就是套了一层 SSL 壳的 HTTP 。在讲解HTTPS相关知识的时候，我发现好像基本上HTTPS协议能讲的细节知识都讲好像都已经讲了。所以接下来，白晨就把HTTPS的整体框架串一遍。

3.1 HTTPS是披着SSL外壳的HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（ Secure Socket Layer）和 TLS（ Transport Layer Security）协议代替而已。同时，SSL不仅可以承载HTTP协议，也可以承载HTTP协议或者SMTP/POP3协议等。

大的框架上来说，HTTP协议正是有了SSL才具有了加密、身份验证、完整性验证等能力。

3.2 HTTPS采用混合加密机制

H T T P 耗时 = T C P 握手 + 通信时间 H T T P S 耗时 = T C P 握手 + S S L 握手 + 通信时间 + 加密解密耗时 HTTP耗时 = TCP握手 + 通信时间\\ HTTPS耗时 = TCP握手 + SSL握手 + 通信时间 + 加密解密耗时 HTTP耗时=TCP握手+通信时间HTTPS耗时=TCP握手+SSL握手+通信时间+加密解密耗时

可以看到HTTPS由于要通过SSL进行安全保障，需要消耗大量时间，并且非对称加密要比对称加密要更加耗费时间。所以，应充分利用两者各自的优势， 将多种方法组合起来用于通信。

在交换密钥环节使用公开密钥加密方式， 之后的建立通信交换报文阶段则使用共享密钥加密方式。

  • HTTPS能完全取代HTTP吗？

既然HTTPS这么安全，那么我们可以直接放弃使用HTTP吗？

答案是不能，HTTPS的安全是建立在牺牲了效率的基础之上的，HTTPS平均会比HTTP协议慢上2~100倍，这对于本来就要处理大量请求的服务器是致命的。

所以，一般在传输私密信息的时候使用HTTPS协议，而在传输非敏感信息时使用HTTP协议传输，这样就能最大化HTTP和HTTPS各自的优势。

3.3 HTTPS证书

在进行SSL握手阶段，服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。 公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥， 对那张证书上的数字签名进行验证， 一旦验证通过，客户端便可明确两件事：

  1. 认证服务器的公开密钥的是真实有效的数字证书认证机构。
  2. 服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。 使用通信方式时，如何安全转交是一件很困难的事， 因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

🪆4. HTTPS通信机制

  1. 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（ Cipher Suite）列表（所使用的加密算法及密钥长度等）。
  2. 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
  3. 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
  4. 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
  5. SSL 第一次握手结束之后，客户端以 Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
  6. 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
  7. 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
  8. 服务器同样发送 Change Cipher Spec 报文。
  9. 服务器同样发送 Finished 报文。
  10. 服务器和客户端的 Finished 报文交换完毕之后， SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
  11. 应用层协议通信，即发送 HTTP 响应。
  12. 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP
    的通信。

用一幅图来具体地展示这个过程：

HTTPS的通信机制参考自《图解HTTP》

📙后记

本篇文章详细地讲解了HTTPS协议、加密解密相关知识、数字签名、数字证书、SSL/TSL等相关知识，其中概念性的知识比较多，涉及到的知识面也比较广。白晨也是参考了许多书籍和博客，画了不少图片以便于大家第一次接触这些陌生概念时不会这么难以接受。当然，对于如SSL/TSL、以及加密算法等知识，白晨并没有将其展开，有兴趣了解的朋友们可以自己查资料学习。

我们是从上到下讲解TCP/IP模型的，前三篇网络文章已经将应用层的代表协议和使用讲解完毕，下一篇文章，白晨将会分享传输层的代表协议TCP协议，通过了解TCP协议，你会对HTTP通信以及报文传输有一个更深层的理解。

  • 参考书籍及博客：

如果讲解有不对之处还请指正，我会尽快修改，多谢大家的包容。

如果大家喜欢这个系列，还请大家多多支持啦😋！

如果这篇文章有帮到你，还请给我一个大拇指 👍和小星星 ⭐️支持一下白晨吧！喜欢白晨【网络】系列的话，不如关注👀白晨，以便看到最新更新哟！！！

我是不太能熬夜的白晨，我们下篇文章见。


转载：https://blog.csdn.net/baichendada/article/details/127428561
查看评论
* 以上用户言论只代表其个人观点，不代表本网站的观点或立场