https基础知识

一、http传输的风险

HTTP请求过程中，客户端与服务器之间没有任何身份确认的过程，数据全部明文传输，所以很容易遭到黑客的攻击,所以 HTTP 传输面临的风险有:
1.窃听风险：黑客可以获知通信内容。
2.篡改风险：黑客可以修改通信内容。
3.冒充风险：黑客可以冒充他人身份参与通信。

二、基本概念

1.加密算法

概念：加密是通过 “加密算法” 将 “明文” 加密成 “密文”。

1.1 对称加密

1.1.1 概念：

在加密和解密的时候使用的秘钥是同一个, 这个秘钥就是一个定长的字符串

1.1.2 效率：

加密速度快, 加密效率高(相对于非对称加密) 主要原因: 对称加密的秘钥长度相对非对称加密较短, 秘钥越短加密时间越短 加密大文件, 大数据

1.1.3 强度：

加密等级相对较低(相对于非对称加密) 主要原因: 对称加密的秘钥长度相对非对称加密较短,秘钥越短加密强度越低

1.1.4 密钥分发难易程度

不能直接传输对称加密是在通信的两端通过这种方式完成数据的加解密, 两端需要有同一个秘钥，秘钥需要在一端生成, 然后发送给另一端 秘钥不能直接在网络中传输, 这样秘钥容易泄露

1.1.5 常见对称加密

例如：AES算法
加密强度大, 加密效率高
项目中的对称加密算法使用的是 AES
秘钥长度: 16字节, 24字节, 32字节
秘钥越长, 加密强度越高, 使用的时间也越长

1.2 非对称加密

1.2.1 概念

在加解密的时候, 使用是不同的秘钥, 一共是两个: 一个公钥,一个私钥，如果使用公钥加密, 那么必须要使用私钥解密，如果使用私钥加密, 那么必须要使用公钥解密

1.2.2 效率：

加密速度慢， 加密效率低 (相对于对称加密) 适合加密少量的数据

1.2.3 强度：

加密等级(强度)相对较高(相对于对称加密)

1.2.4 密钥分发难易程度

非对称加密的秘钥分发指定的是分发公钥, 因此没有分发困难的问题 可以随意分发,因为公钥是可以被公开的 非对称加密的私钥是不会分发的

1.2.5 常见非对称加密

例如：RSA算法
RSA (数字签名和密钥交换)
项目中使用的非对称加密算法就是 RSA
这种算法也是使用最广泛的一种非对称加密算法

2.摘要算法

2.1 概念：

摘要算法就是使用Hash函数将原始数据作为输入参数，生成固定长度的"字符串"，也就是说摘要
并不是原始数据加密后的密文，只是一个验证身份的令牌。所以我们无法通过摘要解密得到原始数据。

2.2 作用：

主要是验证数据是否被篡改。

2.3 常见的摘要算法：

常见的加密算法：MD5 SHA

3.签名

签名就是使用私钥对数据的hash值进行加密

4.加密算法和密钥的关系

如果用代码来表示：

y = f(x,k)
x:明文（数据）
k:密钥
f:算法
y:密文（加密后的数据）

三、网站申请https证书流程

1.服务器生产密钥对

在要部署https的web服务器上生成密钥对(公钥和私钥)

2.准备好网站相关信息

将网站的域名、生成的公钥、营业执照、申请者信息等相关信息封装成一个.CSR文件。然后这个文件发送给CA机构（证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构）。

3.审查申请者信息

验证申请者提供信息的真实性，如组织是否存在、企业是否合法、该组织是否拥有本域名的所有权等
CA机构一般有 2 种认证方式：

3.1 域名认证

一般通过对管理员邮箱认证的方式，这种方式认证速度快，但是签发的证书中没有企业的名称，只显示网站域名，也就是我们经常说的域名型https证书

3.2 企业文档认证

需要提供企业的营业执照。国外https证书申请CA认证一般需要1-5个工作日。

4.CA机构加密生成证书

CA机构的主要意义主要在于，防止server传输公钥给客户端的时候被人劫持并且仿造密钥，而是
由第三方（CA）对setver端的公钥、域名等进行加密之后在传输给客户端

5.将证书发给申请者（服务端）

6.完整流程

1 、服务端人员使用RSA算法生成两个密钥，一个用来加密一个用来解密。将负责加密的那个密钥公布出去，所以我们称之为公钥(Public Key)，而用来解密的那个密钥，不能对外公布，只有服务端持
有，所以我们称之为私钥(Private Key)。服务端在将Public Key进行分发证书之前需要向CA机构申请给将要分发的公钥进行数字签名。(服务器公钥负责加密，服务器私钥负责解密)

2 、生成数字签名公钥证书：对于CA机构来说，其也有两个密钥，我们暂且称之为CA私钥和CA公钥。CA机构将服务端的Public Key作为输入参数将其转换为一个特有的Hash值。然后使用CA私钥将这个
Hash值进行加密处理，并与服务端的Public Key绑定在一起，生成数字签名证书。其实数字签名证书的本质就是服务端的公钥+CA私钥加密的Hash值。(CA私钥负责签名，CA公钥负责验证)

3 、服务器获取到这个已经含有数字签名并带有公钥的证书，将该证书发送给客户端。当客户端收到该公钥数字证书后，会验证其有效性。大部分客户端（操作系统）都会预装CA机构的公钥，也就是CA公钥。客户端使用CA公钥对数字证书上的签名进行验证，这个验证的过程就是使用CA公钥对CA私钥加密的内容进行解密，将解密后的内容与服务端的Public Key所生成的Hash值进行匹配，如果匹配成
功，则说明该证书就是相应的服务端发过来的。否则就是非法证书。流程如下：