HTTP

HTTP和HTTPS通信协议原理

一、HTTP基本概念

1.1 HTTP 超文本传输协议

HTTP 协议 是 Hyper Text Transfer Protocol（超文本传输协议） 的缩写，是用于在万维网（WWW:World Wide Web ）服务器 与 本地浏览器 之间传输超文本数据的传送协议。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.1版及最新的HTTP/2，HTTP/3.0的规范化工作正在进行之中。

HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。

目前主要的HTTP协议版本为HTTP/1.1， HTTP/2， HTTP/3。

HTTP 是一种无状态协议。无状态是指客户机和服务器之间不需要建立持久连接，这意味着当一个客户端向服务器发出请求，然后服务器返回响应，连接就被关闭了，在服务器端不保留连接的有关信息，HTTP 遵循请求/应答模型。

HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了 Web 浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此， HTTP 协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

Tips: HTTP状态码 (HTTP Status Codes)

1.2 HTTP 超文本传输协议是不安全的传输协议

HTTP 协议由于是明文传输，主要存在三大风险：窃听风险、篡改风险、冒充风险。

  • 窃听风险：HTTP协议使用明文传输数据，数据传输过程中可能被窃听。
  • 篡改风险：HTTP协议使用明文传输数据，服务端和客户端无法验证报文的完整性，数据传输过程中可能被篡改。
  • 冒充风险：服务端和客户端不验证通信双方是否，可能遭到伪装，无法保证数据发送到正确的集群上。比如你以为是在和淘宝服务器通信，但实际上是在和一个钓鱼网站通信。

1.3 安全通信的四大原则

一般认为安全的通信需要包括以下四个原则: 机密性、完整性，身份认证和不可否认。

  • 机密性：即对数据加密，解决了窃听风险，因为即使被中间人窃听，由于数据是加密的，他也拿不到明文；
  • 完整性：指数据在传输过程中没有被篡改，不多不少不变，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法；
  • 身份认证：确认对方的真实身份，即证明 “你妈是你妈” 的问题，这样就解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题；
  • 不可否认：即不可否认已发生的行为，比如小明向小红借了 1000 元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失。

接下来将一步步来看看 HTTPS 是如何实现以满足以上四大安全通信原则的。

二、公钥密码、数字签名和数字证书概述

2.1 对称加密 与 非对称加密 的基础概念

  • 对称加密

对称加密（Symmetric Encryption） 是一种加密算法，是指使用相同的密钥来加密和解密数据。这意味着加密和解密方都必须共享（使用）相同的密钥。对称加密是加密领域中最快的一种加密方式，因为它使用的是相对较小的密钥和简单的运算。

  • 非对称加密

非对称加密（Asymmetric Encryption） 又称 公钥密码，是一种密码学方法和技术，与对称加密不同，它使用使用一对密钥：公钥和私钥。公钥用于加密信息，而私钥用于解密信息。这种机制确保了即使公钥被公开，信息的安全性仍然得到保障，因为没有私钥无法解密信息。

非对称加密的特点：公钥加密的数据，只有私钥可以解密，私钥加密的数据，只有公钥可以解密。但是由于公钥是公开的，所以使用私钥加密的数据，可以被第三方使用配对的公钥解密，明文也随之公开了。

公钥密码主要用于以下应用场景：

  • 数据传输加密：如HTTPS协议；
  • 数字签名：用于验证信息来源和完整性；
  • 数字证书：用于身份验证和加密通信。

2.2 数字签名

数字签名（Digital Signature） 是基于公钥密码体制的一种技术，用于验证数据的完整性和身份的真实性。它通过以下三个基本特征来实现：

  • 报文鉴别：接收者能够核实发送者对报文的签名；
  • 报文的完整性：接收者不能伪造对报文的签名或更改报文内容；
  • 不可否认性：发送者事后不能抵赖对报文的签名。

数字签名通常包括以下几个步骤：

  • 计算摘要：发送方用哈希算法生成报文的摘要；
  • 摘要加密：发送方用自己的私钥对摘要进行加密，形成数字签名；
  • 摘要验证：接收方用发送方的公钥对签名进行解密，得到摘要，并用同样的哈希算法重新生成摘要进行比对，以验证报文的完整性和真实性。

简单点说数字签名就是私钥加密消息摘要，而非加密原文，分为下面几个步骤：

  1. 消息摘要：使用哈希算法把原文生成一份摘要。
  2. 私钥加密：使用私钥对摘要进行加密，得到数字签名。
  3. 发送消息和签名：把原数据和加密后的数据摘要打包一起发给对方。
  4. 验证：接收方使用发送方的公钥来解密数字签名，得到摘要。然后接收方对收到的消息使用同样的哈希算法得到一个新的摘要。如果这两个摘要匹配，说明消息未被篡改，且确实是由私钥的所有者签名的。

RSA、DSA、ECDSA 和 Elliptic Curve Diffie-Hellman (ECDH) 是一些常见的 非对称加密算法。这些算法每个有其独特的优点和应用场景，比如 RSA 用于数字签名，ECDH 适用于密钥协商。与对称加密相比，非对称加密算法的性能都比较差。

数字签名广泛应用于以下场景：

  • 电子邮件：用于验证邮件发送者的身份；
  • 电子合同：用于证明合同的签署者身份和合同内容；
  • 电子发票：用于验证发票的真实性和完整性。

2.3 数字证书

数字证书（Digital Certificate） 是由权威机构（CA）颁发的一种电子文档，用于在网络中验证用户的身份和提供数据加密服务。数字证书通常遵循X.509标准，包含以下主要部分：

  • 证书所有者的公开密钥：用于加密通信双方的数据；
  • 证书有效期：证书的有效时间段；
  • 证书颁发机构（CA）的签名：证明证书的真实性和有效性。

数字证书的工作原理如下：

  • 证书持有者向CA申请证书，提供个人信息和公钥；
  • CA验证申请者的身份和公钥，然后生成数字证书，并在证书上签名；
  • 证书持有者将数字证书用于身份验证和加密通信。

Tips: CA机构或授权的注册机构（RA）对证书申请人进行身份鉴别，包括核查有效身份证明文件、授权代表的授权文件和身份证件等。CA机构会复核申请材料，并拒绝不符合要求或高风险的申请。

数字证书广泛应用于以下场景：

  • 网站安全：如HTTPS协议；
  • 电子邮件安全：如S/MIME协议；
  • 移动设备安全：如手机支付、移动办公等。

我们常见的.pem、.pfx、.cer后缀的文件就是X.509证书，X.509是最广泛使用的数字证书格式，由X.509标准定义，用于身份验证和加密。在互联网上，如HTTPS、SSL/TLS等安全通信中，服务器通常使用X.509证书来证明其身份。

X.509证书是一种遵循X.509标准(RFC 5280)的数字证书，用于验证网络通信中的实体身份。它包含了公钥、证书认证机构（CA）信息、有效期、序列号以及证书持有者的其他元数据。

X.509 证书标准有三个增量版本，每个后续版本都向标准添加了证书字段：

  • 1988 年发布的版本 1 (v1)，遵循证书的初始 X.509 标准。
  • 1993 年发布的版本 2 (v2)，向版本 1 中包含的字段添加了两个字段。
  • 2008 年发布的版本 3 (v3)，即 X.509 标准的当前版本。此版本添加了对证书扩展名的支持。

X.509数字证书全解析: https://mp.weixin.qq.com/s/zl-UKHLCkLRNQo5g6GHtzw

  • 证书认证机构（CA）

CA（Certifcate Authority） 是指受用户信任，负责创建和分配证书的权威机构。证书认证机构也可以为用户创建密钥。比如大家经常访问的百度网站的 https 证书就是由 GlobalSign 认证机构颁发的。

一些知名的CA机构如下：

  • VeriSign：美国的一家领先提供商，提供SSL/TLS证书和企业验证服务，如DigiCert和GeoTrust。
  • Thawte：曾是全球最大的SSL证书提供商之一，2000年初 VeriSign 以 5.76亿美元收购 Thawte，Thawte 成为了 VeriSign 的全资子公司。
  • Symantec：提供全面的网络安全解决方案，包括SSL/TLS证书（现名DigiCert）。
  • Comodo：以其经济实惠的SSL证书而知名，广泛用于中小企业和个人网站。
  • GlobalSign：提供数字证书和安全服务，支持各种行业标准。
  • Let’s Encrypt：非营利组织，提供免费的SSL/TLS证书，促进互联网的加密使用。
  • DigiCert：通过并购扩张，提供高级别的安全证书和服务。
  • Cisco Web Security Academy：专注于企业网络安全的证书，如CCNA Cybersecurity等。

这些机构通常会颁发包括 SSL/TLS（如HTTPS）、EV SSL（扩展验证，用于增强网站的信任度）、代码签名（验证软件开发者身份）等多种类型的证书。每个证书都有其适用场景和特点，选择时要考虑安全性、成本和合规性等因素。

  • PKI

公开密钥基础建设（英语：Public Key Infrastructure，缩写：PKI），又称公开密钥基础架构、公钥基础建设、公钥基础设施、公开密码匙基础建设或公钥基础架构，是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，其目的在于创造、管理、分配、使用、存储以及撤销数字证书。（维基百科）

PKI是借助CA（权威数字证书颁发/认证机构）将用户的个人身份跟公开密钥链接在一起，它能够确保每个用户身份的唯一性，这种链接关系是通过注册和发布过程实现，并且根据担保级别，链接关系可能由CA和各种软件或在人为监督下完成。PKI用来确定链接关系的这一角色称为RA（Registration Authority, 注册管理中心），RA能够确保公开密钥和个人身份链接，可以防抵赖，防篡改。在微软的公钥基础建设下，RA又被称为CA，目前大多数称为CA。

PKI的几个主要组成要素：用户（使用PKI的人或机构）、认证机构（CA，颁发证书的人或机构）、仓库（保存证书的数据库）等。

  • 证书签名请求CSR

证书签名请求CSR 是指向CA机构申请数字证书时使用的请求文件，这里的CSR不是证书，而向权威证书颁发机构获得签名证书的申请，当CA机构颁发的证书过期时，可以使用相同的CSR来申请新的证书，此时key不变。

  • 数字证书

数字签名 就是“非对称加密+摘要算法”，其目的不是为了加密，而是为了防抵赖或者他人篡改数据。其核心思想是：比如A要给B发送数据，A先用摘要算法得到数据的指纹，然后用A的私钥加密指纹，加密后的指纹就是A的签名，B收到数据和A的签名后，也用同样的摘要算法计算指纹，然后用A公开的公钥解密签名，比较两个指纹，如果相同，说明数据没有被篡改，确实是A发过来的数据。假设C想改A发给B的数据来欺骗B，因为篡改数据后指纹会变，要想跟A的签名里面的指纹一致，就得改签名，但由于没有A的私钥，所以改不了，如果C用自己的私钥生成一个新的签名，B收到数据后用A的公钥根本就解不开。

CA：也就是常说的根证书，操作系统默认集成了很多权威机构的根证书，因此不必再自己安装和信任一遍。

HTTPS 证书：通常包括一个公钥证书和一个私钥，它们由权威机构（CA）签发，这些权威机构通常是要收费的，也有免费的机构，类似Let’s Encrypt。另一种方式是自己签发，不过需要让客户端信任自己签发的CA证书，目的是为了让自己签发的域名证书通过校验。

证书签发：就是用权威机构帮你生成一个私钥，并使用它的根证书和这个私钥对你的域名进行证书签发，最后将签发后的公钥证书和这个私钥给你。

证书是建立信任的关键，包括 CA 根证书、https 证书和自签名证书。CA 提供权威认证，而自签名证书适用于开发环境。

2.4 SSL/TLS

SSL（Secure Socket Layer） 安全套接层协议，是位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL 通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。

SSL 协议可分为两层：

  • SSL 记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如 TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  • SSL 握手协议（SSL Handshake Protocol）：它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TLS（Transport Layer Security ） 安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性。TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）

SSL/TLS 协议为了解决 HTTP 协议的缺点，希望达到：

  • 所有信息都是加密传播，第三方无法被窃听。
  • 具有校验机制，一旦被篡改，通信双方立刻会发现。
  • 配备身份证书，方式身份被冒充。

SSL 是一个二进制协议，与 HTTP 完全不同，其流量是承载在另一个端口上的（通常是 443），如果 SSL 和 HTTP 的流量都从 80 端口到达，大部分 web 服务器会将二进制 SSL 流量理解为错误的 HTTP 并关闭连接。

SSL证书 是一种数字证书，可以由组织或个人购买，并允许Web服务器和浏览器之间的安全连接。它通过将加密密钥绑定到组织的详细信息来做到这一点。

证书包含有关证书持有者的姓名、证书序列号和到期日期、证书持有者的公钥副本以及证书颁发机构的数字签名等信息。这会对网站进行身份验证，证明它确实是它声称的网站，而不是冒充该网站的黑客。

在服务器向客户端发送公钥这一过程中，客户端可能会收到黑客假冒服务器发送的假的公钥。为了安全考虑，就需要用到 SSL 证书了。在通信时，服务器将证书发送给客户端，客户端会对证书的真伪进行校验，保证了安全。

从本质上讲，它会验证该站点是否如其所说。

SSL 与 TLS 二者之间关系 TLS 是 SSL3.0 的后续版本。TLS 与 SSL3.0 之间存在着显著的差别，主要是它们所支持的加密算法不同，所以 TLS 与 SSL3.0 不能互操作。

SSL 是 Netscape 开发的专门用户保护 Web 通讯的，目前版本为 3.0。最新版本的 TLS 是 IETF（Internet Engineering Task Force，Internet 工程任务组）制定的一种新的协议。最新版本的 TLS1.0，它建立在 SSL3.0 协议规范之上，是 SSL3.0 的后续版本。两者差别极小，可以理解为 SSL3.1。

三、HTTPS概述

3.1 HTTPS协议简介

HTTPS 是 Hypertext Transfer Protocol Secure（安全套接字层超文本传输协议） 的缩写，是在 HTTP 的基础上加入了TLS（Transport Layer Security 安全传输层协议）/SSL（Secure Sockets Layer 安全套接层协议），TLS/SSL协议具有身份验证、信息加密 和 完整性校验 的功能，可以避免HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险。可看成是添加了加密和认证机制的HTTP，使用对称加密、非对称加密、证书等技术进行进行客户端与服务端的数据加密传输，最终达到保证整个通信的安全性。在HTTPS数据传输的过程中，需要用TLS/SSL对数据进行加密，然后通过HTTP对加密后的密文进行传输。

HTTPS使用对称加密和非对称加密相结合的方式来实现内容加密。对称加密方式存在如何安全地将密钥发送对方的问题；非对称加密使用两个密钥，公钥加密则需要私钥解密，私钥加密则需要公钥解密。不能私钥加密，私钥解密。非对称加密不需要发送用来解密的私钥，所以可以保证安全性，但是和对称加密比起来，速度非常的慢，所以还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。 为了数据传输的安全，HTTPS 通过 SSL/TLS（安全套阶层）来加密数据包，SSL再通过数字证书来验证服务器的身份，以此来实现数据在客户端到服务器之间的传输安全。

HTTPS的特点：

  • 内容加密：混合加密方式，对称加密和非对称加密，数据传输采用对称加密， 非对称加密只作用在证书验证阶段
  • 验证身份：通过证书认证客户端访问的是正确的服务器。 防止”中间人“攻击
  • 数据完整性：防止传输的数据被中间人篡改。

https传输/握手过程：

  • 客户端发起 HTTPS 请求
  • 服务端返回证书（包含公钥）
  • 客户端对证书进行验证（用公钥验证签名）
  • 验证通过后本地生成用于对称加密算法的随机数（密钥）
  • 通过证书中的公钥对随机数进行加密发送给服务端，
  • 服务端接收后通过私钥解密得到随机数，
  • 之后的数据交互通过对称加密算法进行加解密。

SSL握手过程（与上面对应）：

  • 客户端向服务器发送Client Hello消息，传送客户端支持的协议版本信息、随机数、加密算法列表，压缩算法列表等
  • serverhello（服务器选择使用的协议版本，加密套件，压缩算法，随机数等）+certificate（身份认证和密钥交换）+serverhellodone（通知客户端serverhello发送结束）
  • Client Key Exchange（用公钥加密后的随机数）+Change Cipher Spec（通知服务器后续通信将采用新协商的加密算法和密钥）+Encrypted Handshake Message（用密钥加密的握手消息）
  • Change Cipher Spec+Encrypted Handshake Message

3.2 HTTPS 协议通信原理

  • 对称加密：HTTPS 最终传输超文本数据的加密形式

既然 HTTP 是明文传输的，那给报文加密不就行了，既然要加密，肯定需要通信双方协商好密钥吧。一种是通信双方使用同一把密钥，即对称加密的方式来给报文进行加解密。

对称加密具有加解密速度快，性能高的特点，也是 HTTPS 传输超文本数据的最终采用的加密形式。

但是，这里有一个关键问题：对称加密的通信双方要使用同一把密钥，这个密钥是如何协商出来的？如果通过报文的方式直接传输密钥，之后的通信其实还是在裸奔，因为这个密钥会被中间人截获甚至替换掉，这样中间人就可以用截获的密钥解密报文，甚至替换掉密钥以达到篡改报文的目的。 有人说对这个密钥加密不就完了，但对方如果要解密这个密钥还是要传加密密钥给对方，依然还是会被中间人截获的，这么看来：直接传输密钥无论怎样都无法摆脱俄罗斯套娃的难题，是不可行的。

  • 非对称加密：解决对称密钥的传输问题

直接传输密钥，无论从哪一端传都是不行的，那使用非对称加密是否可行？

非对称加密 即加解密双方使用不同的密钥，一把作为公钥，可以公开的，一把作为私钥，不能公开，公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。

Tips: 私钥加密这个说法其实并不严谨，准确的说私钥加密应该叫私钥签名。因为私钥加密的信息公钥是可以解密的，而公钥是公开的，任何人都可能拿到，用公钥解密叫做 签名验证。

这样的话，对于 Server 来说，保管好私钥，发布公钥给其它 Client, Client 只要使用公钥把对称加密的密钥加密后传给 Server 即可。如此一来由于公钥加密只有私钥能解密，而私钥只有 Server 有，所以能保证 Client 向 Server 传输是安全的，Server 解密后即可拿到对称加密密钥，这样 Client端 和 Server端 交换了密钥之后就可以用对称加密密钥进行通信了。

但是问题又来了， Server 怎么把公钥安全地传输给 Client 呢？如果直接传公钥，也会存在被中间人调包（窃听、篡改、冒充）的风险。

  • 数字证书：解决公钥传输信任问题

如何解决公钥传输问题呢？

从现实生活中的场景找答案：员工入职时，企业一般会要求提供学历证明，显然不是什么阿猫阿狗的本本都可称为学历，这个学历必须由第三方权威机构（Certificate Authority，简称 CA）即教育部颁发。同理，Server 也可以向 CA 申请证书，在证书中附上公钥，然后将证书传给 Client，证书由站点管理者向 CA 申请，申请的时候会提交 DNS 主机名等信息，CA 会根据这些信息生成证书。 这样当 Client 拿到证书后，就可以获得证书上的公钥，再用此公钥加密对称加密密钥传给 Server 即可。看起来确实很完美，不过在这里要考虑两个问题:

问题一：如何验证证书的真实性？如何防止证书被篡改？

想象一下上文中提到的学历，企业如何认定你提供的学历证书是真是假呢？答案是用学历编号，企业拿到证书后用学历编号在学信网上一查就知道证书真伪了，学历编号其实就是我们常说的数字签名，可以防止证书造假。

回到 HTTPS 上，证书的数字签名该如何产生的呢？步骤如下 ：

  1. 首先使用一些摘要算法（如 MD5）将证书明文（如证书序列号，DNS 主机名等）生成摘要，然后再用第三方权威机构的私钥对生成的摘要进行加密（签名）。

消息摘要是把任意长度的输入揉和而产生长度固定的伪随机输入的算法，无论输入的消息有多长，计算出来的消息摘要的长度总是固定的。一般来说，只要内容不同，产生的摘要必然不同（相同的概率可以认为接近于 0），所以可以验证内容是否被篡改了。

为什么要先生成摘要再加密呢，不能直接加密？

因为使用非对称加密是非常耗时的。如果把整个证书内容都加密生成签名的话，客户端验签也需要把签名解密，证书明文较长，客户端验签就需要很长的时间，而用摘要的话，会把内容很长的明文压缩成小得多的定长字符串，客户端验签的话就会快得多。

  1. 客户端拿到证书后，首先，使用第三方权威机构的公钥对签名进行解密（验签），得到验签的结果（摘要）。然后，用同样的摘要算法对证书明文计算摘要。两者一比对就可以发现报文是否被篡改了。

为什么要用第三方权威机构（Certificate Authority，简称 CA）私钥对摘要加密呢？

因为摘要算法是公开的，中间人可以替换掉证书明文，再根据证书上的摘要算法计算出摘要后把证书上的摘要也给替换掉！这样 Client 拿到证书后计算摘要发现一样，误以为此证书是合法就中招了。所以，必须要用 CA 的私钥给摘要进行加密生成签名，这样的话 Client 得用 CA 的公钥来给签名解密，拿到的才是未经篡改合法的摘要（私钥签名，公钥才能解密）。

Server 将证书传给 Client 后，Client 的验签过程如下：

这样的话，由于只有 CA 的公钥才能解密签名，如果客户端收到一个假的证书，使用 CA 的公钥是无法解密的，如果客户端收到了真的证书，但证书上的内容被篡改了，摘要比对不成功的话，客户端也会认定此证书非法。

Tips: CA 公钥如何安全地传输到 Client ？

  • 如果还是从 Server 传输到 Client，依然无法解决公钥被调包的风险。实际上此公钥是存在于 CA 证书上，而此证书（也称 Root CA 证书）被操作系统信任，内置在操作系统上的，无需传输，如果用的是 Mac 的同学，可以打开 keychains 查看一下，可以看到很多内置的被信任的证书。

1. Windows 系统查看CA证书：

  • 按 Windows + R 键 打开 运行 对话框，输入 certmgr,msc 点击 确认 按钮 或 直接 按 Enter，这将打开 Windows 证书管理器。
  • 在证书管理器左侧面板中可以看到 “受信任的根证书颁发机构” 文件夹，CA证书通常就存储在这里。
  • 点击 “受信任的根证书颁发机构” 文件夹 -> 证书 文件夹，然后在右侧面板中可以看到安装在 Windows 系统上的所有 CA 证书的列表。

2. Linux 系统查看CA证书：

  • Linux系统中，CA证书的默认位置通常在以下目录：
  • /etc/pki/ca：这是存放CA根证书、中间证书颁发机构（CA）和证书授权（CA）的目录。
  • /etc/pki/tls/certs：存放CA的公钥证书。
  • /etc/pki/tls/private：存放CA的私钥。
  • /etc/pki/tls/ca.crt：系统可能会在这个位置链接到CA证书。

3. Mac 系统查看CA证书：

  • Mac 系统中，在启动台打开 keychains（钥匙串访问） APP -> 点击 打开钥匙串访问 按钮 -> 点击左侧菜单栏的 系统根证书 菜单按钮，即可查看系统内置的被信任的证书。

Server 传输 CA 颁发的证书给客户端，客户收到证书后使用内置 CA 证书中的公钥来解密签名，验签即可，这样的话就解决了公钥传输过程中被调包的风险。

问题二：如何防止证书被调包？

实际上任何站点都可以向第三方权威机构申请证书，中间人也不例外。获得认证的证书由于都是 CA 颁发的，所以都是合法的。那么此时中间人是否可以在传输过程中将正常站点发给 Client 的证书替换成自己的证书呢？ 答案是：不行。因为客户端除了通过验签的方式验证证书是否合法之外，还需要验证证书上的域名与自己的请求域名是否一致，中间人中途虽然可以替换自己向 CA 申请的合法证书，但此证书中的域名与 Client 请求的域名不一致，Client 会认定为不通过！

但是，上面的证书调包给了我们一种思路，什么思路？大家想想， HTTPS 既然是加密的， charles 这些中间人为啥能抓到明文的包呢？其实就是用了证书调包这一手法，想想看，在用 charles 抓 HTTPS 的包之前我们先要做什么，当然是安装 charles 的证书。

这个证书里有 charles 的公钥，这样的话 charles 就可以将 Server 传给 Client 的证书调包成自己的证书，Client 拿到后就可以用自己安装的 charles 证书来验签等，验证通过之后就会用 charles 证书中的公钥来加密对称密钥了。整个流程如下： 由此可知，charles 这些中间人能抓取 HTTPS 包的前提是：Client 信任它们的 CA 证书，然后就可以通过替换证书的方式进行瞒天过海，所以我们千万不要随便信任第三方的证书，避免安全风险。

3.3 HTTPS 的优缺点

  • HTTPS 的优点

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

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

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

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

四、补充：DNS协议

DNS域名系统（Domain Names System）：是进行域名和与之相对应的 IP 地址进行转换的服务器，将域名和IP地址相互映射的一个分布式数据库。

域名查询方式:

  • 递归查询：如果 A 请求 B，那么 B 作为请求的接收者一定要给 A 想要的答案;
  • 迭代查询：如果接收者 B 没有请求者 A 所需要的准确内容，接收者 B 将告诉请求者 A，如何去获得这个内容，但是自己并不去发出请求;

解析域名的过程如下：

  1. 首先搜索浏览器的 DNS 缓存，浏览器缓存中维护着一张域名与 IP 地址的对应表；
  2. 若没有命中，则继续搜索操作系统的 DNS 缓存；
  3. 若仍然没有命中，则操作系统将域名发送至本地域名服务器，本地域名服务器采用递归查询自己的 DNS 缓存，查找成功则返回结果；
  4. 若本地域名服务器的 DNS 缓存没有命中，则本地域名服务器向上级域名服务器进行迭代查询：
  • 首先本地域名服务器向根域名服务器发起请求，根域名服务器返回顶级域名服务器的地址给本地服务器；
  • 本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址；
  • 本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的 IP 地址；
  1. 本地域名服务器将得到的 IP 地址返回给操作系统，同时自己将 IP 地址缓存起来；
  2. 操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起；
  3. 至此，浏览器就得到了域名对应的 IP 地址，并将 IP 地址缓存起；