HTTPS加密过程

HTTPS加密过程

HTTPS 是 HTTP + SSL

原本HTTP 是直接和传输层进行通信的，不经过加密。但是这就给了不法分子有机可乘。

HTTPS加密方式：在交换密钥阶段使用非对称加密方式，之后建立通信交换报文阶段则使用对称加密方式

名词解析

对称加密：加密和解密是同一个密钥。加密时就必须将密钥传送给对方，但是如何保证安全机制呢

非对称加密：加密和解密使用的密钥不一致。使用此加密方式，发送密文的一方使用公钥进行加密，对方收到密文后，用自己独特的私钥进行解密。利用这种方式，不需要发送私钥，也不必担心密钥被攻击者窃听盗走。

密钥安全交换

问：双方怎么才能得到私钥或公钥呢，怎么要能保证得到的密钥是正确的（不被篡改）？

答：下面就用到了 数字证书认证机构（CA，Certificate Authority）

CA 类似于识别伪造的机构，数字签名类似于公章，客户端相当于用户，服务端类似于官方，公钥证书类似用户从官方等到的商品

接收到证书的客户端可以在 CA 对证书上的数字签名进行验证，一旦验证成功，便可以确认两件事：

• 认证服务器的公钥的CA 是真实有效的 CA
• 服务器的公钥是值得信赖的

此处，服务端的公钥要安全的转交给客户端，安全的转交是一件比较困难的事情。因此，大多是浏览器发布的时候，会事先在内部植入常用认证机关的公钥。

• 服务器将自己的公钥放在 CA
• CA 用自己的私钥 向服务器的公钥 部署数字签名并颁发公钥证书（用于客户端验证证书）
• 客户端拿到服务器的公钥证书后，使用 CA 的公钥将证书信息发给CA，验证服务器的公钥证书的真实性
• 若验证是服务端的公钥证书是真实的，则使用此公钥证书对发送的报文进行加密，发给服务器
• 服务器用私钥进行解密

为什么要有CA机构

为了保证服务器的公钥是正确的，不是被攻击者篡改过的。因此浏览器在发布的时候，往往会将某些证书提前放置在CA，CA对服务器的公钥进行数字签名，当客户端验证获取的公钥证书时，便可以在CA 进行验证，CA就可以通过数字签名进行服务器公钥真实性的验证。

反向理解

当采用非对称加密时，服务器会生成两个密钥，是公钥和私钥。公钥以证书的形式发给用户，用户向服务器 发送信息的时候采用此密钥进行加密；私钥只存在于服务器端，用于解密。

但是用户要验证获取的公钥证书的真实性，因此要在CA 中进行验证

为了提供一个可靠的验证机制，在客户端获取服务器的公钥之前，CA用自己的私钥对服务器公钥证书进行数字签名，然后才颁发给客户端。

HTTPS 安全通信机制