HTTPS

# 一. HTTPS特点

HTTPS = HTTP + SSL/TSL

TSL：

# 1. 内容加密

对称内容加密
非对称密钥交换

# 2. 数字证书身份认证

引入证书进行客户端、服务器的身份认证

服务器将生成的 CA证书传给客户端
客户端收到证书，解密证书签名。然后根据证书规则，验证证书的真伪
验证通过。解密服务器公钥key1，非对称生成新key2，再用服务器端key1加密发给服务端新的密钥；后续通过这个密钥进行对称加密

# 3. 数据完整性

通过校验数字签名，校验数据的完整性。网络传输中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改

流程见下图：

数字签名校验

首先来了解下哈希算法 (opens new window)，哈希算法能够将任意长度的字符串转化为固定长度的字符串，该过程不可逆，可用来作数据完整性校验。

服务器在发送报文之前做了3件的事：

用哈希算法对报文提取定长摘要
用私钥对摘要进行加密，作为数字签名
将数字签名附加到报文末尾发送给客户端

客户端接收到报文后：

用公钥对服务器的数字签名进行解密
用同样的算法重新计算出报文的数字签名
比较解密后的签名与自己计算的签名是否一致，如果不一致，说明数据被篡改过。

同样，客户端发送数据时，通过公钥加密报文摘要，服务器用私钥解密，用同样的方法校验数据的完整性。

# 二. 加密算法

# 对称加密

对称： 加密和解密使用同一个秘钥key

【客户端】：key对称加密后的data

【服务器】：利用公钥key对data解密

黑客获取公钥，客户端请求时不安全

无法认证客户端/服务器身份是否合法

# 非对称加密

非对称： 公钥pkey，私钥skey

【客户端】：向服务器请求pkey

【服务器】：给客户端发送pkey

【客户端】：向服务器发送数据，pkey加密

【服务器】：接收到客户端的数据，skey解密；并且通过skey先客户端发送数据

黑客获取公钥，公钥可以解私钥；服务端向客户端发送时不安全

无法认证客户端/服务器身份是否合法

公钥加密，私钥解密；——— 用于加密

公钥加密，只有私钥才能解密；用于文件内容加密

私钥加密，公钥解密； ——— 用于签名

拥有公钥者均可查看，但是只有私钥者才能更改；用于签名认证

# 三. CA证书

CA证书：权威官方机构颁发的秘钥证书，写死在操作系统中，每一个客户端会有不同的key

CA 证书内一般会包含以下内容：

证书的公钥
证书的数字签名 Hash 值 和 签名 Hash 算法
证书的颁发机构、版本
证书的使用者
证书的有效时间

【验证CA证书是否合法】

CA 证书中的 Hash 值，其实是用证书的私钥进行加密后的值（证书的私钥不在 CA 证书中）。然后客户端得到证书后，利用证书中的公钥去解密该 Hash 值，得到 Hash-a ；然后再利用证书内的签名 Hash 算法去生成一个 Hash-b 。最后比较 Hash-a 和 Hash-b 这两个的值。如果相等，那么证明了该证书是对的，服务端是可以被信任的；如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。除此之外，还会校验 CA 证书的有效时间和域名匹配等。

# 【🍳详解HTTPS加密】

先用非对称加密获取到公钥，然后生成对话密钥进行对称加密传输

过程分析：

发送请求：客户端发起一个HTTPS请求，连接到服务器的443端口
传送证书：服务端把自己的信息以 数字证书 的形式返回给客户端（证书内容有公钥，网站地址，证书颁发机构，失效日期等）。证书中有一个公钥来加密信息，私钥由服务器持有。
客户端验证证书的合法性：客户端收到服务器的响应后，客户端的TLS会先验证证书的合法性（证书中包含的地址与正在访问的地址是否一致，证书是否过期）。
生成随机密钥（RSA签名）：如果验证通过，或用户接受了不受信任的证书，客户端会生成一个随机的对称密钥（Hash生成的随机值session key），并用公钥（刚才的证书中包含）加密，让服务端用私钥解密，解密后就用这个对称密钥进行传输了。

验证完服务端身份后，客户端生成一个对称加密的算法和对应密钥，以公钥加密之后发送给服务端。此时被黑客截获也没用，因为只有服务端的私钥才可以对其进行解密。之后客户端与服务端可以用这个对称加密算法来加密和解密通信内容了。
服务端加密信息：服务端用私钥解密，得到了客户端传过来的session key密钥（随机值），然后把内容通过该值进行对称加密。
传输加密后的信息：服务端用密钥（随机值）对称加密后传输信息，可以在客户端被还原。
客户端解密信息：客户端用之前生成的密钥（随机值）解密服务端传过来的信息，于是获取了解密后的内容。

2012072310244445

【小结】

最重要的就是RSA加密体制，还有用于验证服务器是否持有私钥的步骤，又能牵涉到HASH算法。

验证成功后，通过对消息体的摘要进行HASH加密就能得到RSA签名了（为了保证信息没被篡改），给服务器解密，确认，正常通信。

# SSL握手过程

接下来我们就来详细讲一下 HTTPS 中的 SSL 握手建立过程

假设现在有客户端 A 和服务器 B ：

客户端 A 访问服务器 B ，比如我们用浏览器打开一个网页 https://www.baidu.com ，这时，浏览器就是客户端 A ，百度的服务器就是服务器 B 了。

首先，客户端 A 生成一个随机数num1，把随机数num1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B
服务器 B 知道这些信息后，然后确认一下双方的加密算法，然后服务端也生成一个随机数 num2 ，并将随机数 num2 和 CA 证书一同返回给客户端 A 。
客户端 A 得到 CA 证书后，会去校验该 CA 证书的有效性。校验通过后，客户端生成一个随机数num3 ，然后用证书中的公钥加密随机数 num3 并传输给服务端 B
服务端 B 得到加密后的随机数num3，然后利用私钥进行解密，得到真正的随机数num3
最后，客户端 A 和服务端 B 都有随机数num1、随机数num2、随机数num3，然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法。
客户端 A 通知服务端 B ，指明后面的通讯用对话密钥来完成，同时通知服务器 B 客户端 A 的握手过程结束。
服务端 B 通知客户端 A，指明后面的通讯用对话密钥来完成，同时通知客户端 A 服务器 B 的握手过程结束。
SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯