HTTPS原理

## 提问

- 为什么用了 HTTPS 就是安全的？
- HTTPS 的底层原理如何实现？
- 用了 HTTPS 就一定安全吗？
- 什么是TLS双向认证？
- 客户端是如何确保服务端身份？
- 服务端如何确保客户端身份？HTTPS报文在传输过程被篡改了怎么办？
- 如何保证安全呢？你说安全就安全吗，究竟是怎么实现的呢？绝对安全吗？

有人的地方就有江湖，有江湖的地方就没有绝对的安全。但 SSL/TLS 确实可以极大程度保证信息安全。

Q1: CA 介绍

CA: 证书授权中心 (certificate authority)
它呢，类似于国家出入境管理处一样，给别人颁发护照；
也类似于国家工商管理局一样，给公司/企业颁发营业执照。
为了让服务端的公钥被大家信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

在 HTTP 里面，证书都是签发给域名持有人的。

CA 签发证书的过程：

1) 我自己的网站，需要使用 https 通信，那么我向“证书机构”申请数字证书的时候，就需要向他们提供相应的信息，这些信息以特定文件格式(.csr)提供的，这个文件就是“证书请求文件”；为了确保我提供的信息在互联网的传输过程中不会被有意或者无意的被破坏或篡改，我们有如下的机制来对传输的内容进行保护：首先在本地生成一个密钥对，利用这个私钥对"我们需要提供的信息"进行加密，从而生成 证书请求文件(.csr), 这个证书请求文件其实就是私钥对应的公钥证书的原始文件，里面含有对应的公钥信息；

1）申请认证：服务器需自己生成公钥私钥对 pub_svr & pri_svr，同时根据 pub_svr 生成请求文件 csr，提交给 CA 机构，csr 中含有公钥、组织信息、个人信息（域名）等信息。(图一中 server.req 就是 csr 请求文件)

2）审核信息：CA 机构通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。

3）签发证书：如信息审核通过，CA 机构会向申请者签发认证文件：证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。（图一中生成 server.crt）

4）返回证书：client 如果请求验证服务器，服务器需返回证书文件。（图一中 handshake 传回 server.crt）

5）client验证证书：client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。
客户端会内置信任 CA 的证书信息（包含公钥），如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。(图一中 check 可选，我们可以选择不验证服务器证书的有效性)

6）秘钥协商：验证通过后，server 和 client 将进行秘钥协商。接下来 server 和 client 会采用对称秘钥加密。(对称加密时间性能优)（图一中 pre-master/change_cipher_spec/encrypted_handshake_message 过程）

7）数据传输：SSL server 和 SSL client 采用对称秘钥加密解密数据。
————————————————
版权声明：本文为CSDN博主「ustccw」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ustccw/article/details/76691248

- 网站建设人员，我注册了一个域名，我要向CA机构申请一个HTTPS证书。来证明我是合法的域名持有人。
- 网站持有人通过收费或免费等方法，去找CA机构申请证书，如何证明自己身份呢？

Q1：数字证书

数字证书是由权威的CA（Certificate Authority）机构给服务端进行颁发，CA机构通过服务端提供的相关信息生成证书，证书内容包含了持有人的相关信息，服务器的公钥，签署者签名信息（数字签名）等，最重要的是公钥在数字证书中。

一个证书中含有三个部分:"证书内容，散列算法，加密密文"，证书内容会被散列算法hash计算出hash值，然后使用CA机构提供的私钥进行RSA加密。

## HTTPS 的实现原理

HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：


### 证书验证阶段(又称TLS握手阶段)
- 浏览器发起 HTTPS 请求
- 服务端返回 HTTPS 证书
- 客户端验证证书是否合法，如果不合法则提示告警
### 数据传输阶段
- 当证书验证合法后，在本地生成随机数
- 通过公钥加密随机数，并把加密后的随机数传输到服务端
- 服务端通过私钥对随机数进行解密
- 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

### 为什么数据传输是用对称加密？
首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；

另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

- 为什么需要 CA 认证机构颁发证书？

浏览器拿到了服务端的数字证书后，要怎么校验该数字证书是真实有效的呢？

数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。
说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。

我们用证书来认证公钥持有者的身份（服务端的身份），那证书又是怎么来的？又该怎么认证证书呢？

为了让服务端的公钥被大家信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。