北京网站开发哪里好薇_网站建设建网站_百度搜索app免费下载_优秀软文范例800字

一、核心知识

（1）网站的Public key 通过CA的Private key 加密后得到证书。这个证书发送给User。

（2）User用CA的Public key去验证网站的证书。

（3）CA机构是TLS验证的桥梁、中介、互信机构。

二、具体内容

1. TLS 传输层安全协议 Transport Layer Security

• SSL： secure socket Layer 安全socket层协议，这是老的协议。
• 传输层安全协议，通过名字我们就知道TLS是作用在网络协议的哪一层了。

2. 安全3要素-- 保密、完整、身份验证

• Confidentiality: hides the content of the messages
• Integrity: detects when the messages have been tampered with
• Authentication: ensures that whoever is sending them is who he says he is.

3. 如何保证TLS的完整性

• 采用Hash算法，如SHA256

4. 如何保证TLS的保密性

• 在处理类似 Heartbleed 漏洞的问题后，推荐使用具有前向保密性（Forward Secrecy）的密钥交换机制，以提高安全性。比如：Diffie-Hellman 密钥交换方法（尤其是椭圆曲线模式），因为它可以提供前向保密性。
• 前向保密性（Forward Secrecy, FS）：即使某一时刻服务器的私钥被泄露，攻击者也无法解密之前记录的加密通信。前向保密性通过为每个会话生成临时的密钥来确保，即使主密钥泄露，也不会影响其他会话的安全性。
• Diffie-Hellman 密钥交换机制：与传统的 RSA 密钥交换不同，Diffie-Hellman 密钥交换在每次会话中动态生成密钥，支持前向保密性。特别是其椭圆曲线（Elliptic Curve Diffie-Hellman，ECDH）版本能够在提供高安全性的同时保持较低的计算开销。
• Heartbleed 漏洞的教训：Heartbleed 让人们意识到如果使用不具有前向保密性的 RSA 密钥交换机制，泄露的私钥可以用来解密先前所有通过 TLS 保护的通信。因此，使用前向保密的机制（如 Diffie-Hellman）成为新的推荐做法，增强了通信的长期安全性。

5. TLS的身份验证（重点）

• 如果身份验证不安全，你就不可能有通信安全。You. Cannot. Have. Secure. Communications. Without. Authentication.

5.1 证书=公钥+基本信息Certificates = Public keys + bunches infomations

• FQDN being authenticated
• “issued on” and “expires on” dates
• among other things
  Fully Qualified Domain Name
  An FQDN is structured hierarchically and usually consists of:
• Host name: The specific machine or service (like “www” or “mail”).
• Domain name: The domain to which the host belongs (like “example.com”).
• Top-level domain (TLD): The highest level in the domain hierarchy (like “.com”, “.org”, “.net”).

5.2 加密基本知识

• 加密，可以用 private 和 public key加密
  $$Enc(Priv,X)=X_{priv}$$
  $$Enc(Pub,X)=X_{pub}$$
• 解密： private 和 public 可以相互解密。private可以解private的，public不能解public。
  $$Dec(Pub,X_{priv})=X$$
  $$Dec(Priv,X_{pub})=X$$
  $$Dec(Priv,X_{priv})=X$$

5.3 案例：用户Alice想确认拿到的Key是真正的Frank发送的Public key。

5.3.1 通过4个版本的衍化展示TLS的基本流程（自己可以徒手画一画，加深理解）

5.4 几个重要概念

数字签名 = Enc(Priv, hash(msg)）= 将信息做hash变换后，并加密。

• 签名应该是不可篡改的。
  自验证 self-Signature
• 开发或者其他原因，TLS不用CA去验证，由自己签发和认可。

6. 实操

6.1 通过CA机构创建证书的步骤

1. 创建 private key 和 Certificate Signing Request (CSR)
2. 将 CSR 发送给 CA,
   注意；private key永远要保密，不能分享给别人，CA机构也不行！
3. 根据CA机构的要求进行验证。验证通过后，获取了CA机构签名的数字证书。
4. 将该数字证书放在服务器中
5. 配置应用使用该证书 和 Private key。比如Linux，可能是配置Nginx 或者 Apache2

如何创建Private key 和 CSR

#创建 key 和 CSR
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out request.csr从已有的key创建 CSR
openssl req -new -key example.key -out example.csr#创建 private key
openssl genrsa -out example.key 2048

6.2 开发时，创建自认证的证书

# 从CSR创建CRT（自认证时使用）
openssl x509 -req -days 365 -in request.csr -signkey private.key -out certificate.crt

7. 问题就结束了吗？

7.1 CA机构给我返回的是一系列证书，都是什么？

• 证书链：中间证书s + root 证书

7.2 证书链的作用

证书链的存在是为了确保服务器证书的可信性，通过一系列的验证来建立信任。证书链连接了服务器证书、中间证书（如果有）、和根证书。其主要原因如下：

• 信任传递
  根证书（由受信任的证书颁发机构 [CA] 签署）本身预装在操作系统或浏览器中，被认为是可信的。通过证书链，信任可以从根证书逐级传递给中间证书，最后传递到服务器证书。即使浏览器没有直接信任服务器的证书，通过信任链，最终也能确认该证书的可信性。
• 简化管理
  证书颁发机构可以使用中间证书来分层管理证书的签发。根证书由 CA 直接签发，持有者是操作系统或浏览器信任的根机构。而 CA 可以授权中间机构生成中间证书，用来签发服务器证书。这种做法减少了直接使用根证书的频率，从而保护根证书的私钥，降低私钥泄露的风险。
• 增强安全性
  使用中间证书分层管理有助于提高安全性。即使中间证书的私钥泄露，也不会危及整个信任体系，只需吊销中间证书即可，而无需替换根证书。
• 灵活性
  中间证书使得证书颁发机构可以分发不同的签发权限。这样，不同的中间证书可以根据需要签发不同类型的服务器证书，增加了签发证书的灵活性。
• 减少信任风险
  如果证书链中某个中间证书的安全受到威胁，CA 可以撤销该中间证书，而无需撤销整个 CA 的根证书。这有助于将风险局部化并降低影响范围。

7.3 Public key在哪里？如何传递给客户？

- Public key在CRT文件里！！
在 TLS 协议中，公钥（public key） 是在证书生成过程中创建的，并通过证书传递给客户端。具体步骤如下：

• 公钥生成
  公钥是在服务器生成其密钥对时创建的。密钥对由私钥和公钥组成：

• 私钥保存在服务器上，不能外泄。

• 公钥将被嵌入到数字证书中，供客户端验证服务器的身份和加密通信使用。
  服务器的密钥对通常使用非对称加密算法（如 RSA 或 ECC）生成。非对称加密算法的特点是使用公钥进行加密，私钥进行解密。

• 公钥传递
  当客户端（如浏览器）访问服务器时，公钥会通过服务器的数字证书传递给客户端。这一过程发生在 TLS 握手的开始阶段。
  具体步骤：

  • 服务器将其数字证书发送给客户端。这个证书是由可信的证书颁发机构（CA）签发的，证书中包含服务器的公钥以及其他相关信息（如证书的持有者、有效期等）。
  • 客户端验证数字证书的合法性，确保证书是由可信的 CA 签发，且没有被篡改或撤销。
  • 验证通过后，客户端会使用该公钥加密一个随机生成的会话密钥（session key），用于接下来的对称加密通信。

• 如何传递给客户端
  公钥传递给客户端的过程如下：

  1. TLS 握手开始：客户端向服务器发起连接请求，服务器返回其数字证书。
  2. 服务器证书传递：证书中包含服务器的公钥。客户端通过验证证书确认服务器身份。
  3. 公钥使用：客户端使用服务器的公钥加密一个随机生成的会话密钥（用于后续的对称加密通信）。
  4. 密钥交换：服务器使用自己的私钥解密会话密钥，之后的通信就基于对称加密进行。

7.4 CSR（证书请求）和CRT（证书）有什么区别？

• CSR：是申请证书时生成的文件，包含公钥及相关信息，提交给 CA 请求签发证书。

• CRT：是 CA 颁发的数字证书，包含公钥及由 CA 签名的信息，用于服务器身份验证和加密通信。

• CSR（证书签名请求）：一份包含了申请者公钥及其他信息的文件，服务器管理员在申请证书时生成并提交给证书颁发机构（CA）。

• 包含内容：

  • 公钥（服务器端生成的公钥）
  • 组织信息（如域名、公司名称、所在地等）
  • 签名信息（使用服务器的私钥对 CSR 进行签名）

• 用途：CSR 是向证书颁发机构请求颁发数字证书的请求文件，证书颁发机构会基于 CSR 文件中的信息进行验证并生成数字证书（CRT 文件）。

• 如何生成：通常通过服务器命令生成（如使用 OpenSSL），过程中生成了一个私钥和 CSR。

• CRT（证书）： 是证书颁发机构根据 CSR 文件生成并签发的数字证书，包含了申请者的公钥及其他验证信息。

  • 包含内容：
    • 公钥（从 CSR 提取的公钥）
    • 颁发机构签名（由 CA 使用其私钥签署）
    • 其他信息（如有效期、证书用途、颁发机构的名称等）
  • 用途：CRT 文件是用于验证服务器身份的数字证书，客户端（如浏览器）可以通过验证 CRT 来确认服务器的真实性，并使用公钥进行安全通信。
  • 如何使用：安装在服务器上，与私钥一起用于加密通信。

7.5 客户端如何验证证书链？从根证书开始，还是服务器证书？

在 TLS 握手过程中，客户端验证证书链时，从服务器端提供的证书开始，逐步验证到根证书（root certificate）。具体验证过程如下：

• 从服务器证书开始
  客户端首先接收到服务器发送的数字证书，它是证书链中的第一环（最靠近服务器）。客户端检查服务器证书是否有效，例如是否在有效期内，是否匹配访问的域名等。
• 验证中间证书
  服务器的数字证书通常是由中间证书颁发机构（Intermediate Certificate Authority, ICA）签署的，客户端会从服务器证书中获取中间证书的引用，接着验证中间证书的合法性。
  客户端可以通过本地缓存或者从服务器提供的链中获取中间证书，并确认它是否由更高一级的 CA 颁发。如果中间证书没有直接存储在本地，客户端可能需要从互联网获取该中间证书。
• 验证根证书
  当验证到中间证书后，客户端会继续验证到链的最后一级——根证书（root certificate）。根证书是由证书颁发机构（CA）直接签署的，通常已经预安装在操作系统或浏览器的受信任证书存储中。
  • 如果根证书存在于本地受信任的证书列表中，客户端会将该证书视为可信。
  • 如果根证书不在受信任的证书列表中，客户端将会拒绝连接，并向用户发出警告，表示无法验证服务器的合法性。