HTTPS 小结

Linux点滴运维实践 2021-04-12

272

HTTPS 基础知识

什么是 PKI？

公开密钥基础建设（英语：Public Key Infrastructure，缩写：PKI），又称公开密钥基础架构、公钥基础建设、公钥基础设施、公开密码匙基础建设或公钥基础架构，是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，其目的在于创造、管理、分配、使用、存储以及撤销数字证书。（节选维基百科）

PKI是借助CA（权威数字证书颁发/认证机构）将用户的个人身份跟公开密钥链接在一起，它能够确保每个用户身份的唯一性，这种链接关系是通过注册和发布过程实现，并且根据担保级别，链接关系可能由CA和各种软件或在人为监督下完成。PKI用来确定链接关系的这一角色称为RA（Registration Authority, 注册管理中心），RA能够确保公开密钥和个人身份链接，可以防抵赖，防篡改。在微软的公钥基础建设下，RA又被称为CA，目前大多数称为CA。

PKI组成要素

从上面可以得知PKI的几个主要组成要素，用户（使用PKI的人或机构），认证机构（CA，颁发证书的人或机构），仓库（保存证书的数据库）等。

非对称加密

非对称加密，有公钥和私钥之分，并且他们总是成对出现，它们的特点就是其中一个加密的数据，只能使用另一个解密，即使它本身也无法解密，也就是说公钥加密的，私钥可以解密，私钥加密的，公钥可以解密，使用非对称加密算法特点消耗资源。

对称加密

对称加密指的是加密和解密的密钥都相同，它的特点是不安全，但加解密速度快，消耗资源少。

证书签名请求CSR

它是向CA机构申请数字证书时使用的请求文件，这里的CSR不是证书，而向权威证书颁发机构获得签名证书的申请，当CA机构颁发的证书过期时，你可以使用相同的CSR来申请新的证书，此时key不变。

数字签名

数字签名就是“非对称加密+摘要算法”，其目的不是为了加密，而是为了防抵赖或者他们篡改数据。其核心思想是：比如A要给B发送数据，A先用摘要算法得到数据的指纹，然后用A的私钥加密指纹，加密后的指纹就是A的签名，B收到数据和A的签名后，也用同样的摘要算法计算指纹，然后用A公开的公钥解密签名，比较两个指纹，如果相同，说明数据没有被篡改，确实是A发过来的数据。假设C想改A发给B的数据来欺骗B，因为篡改数据后指纹会变，要想跟A的签名里面的指纹一致，就得改签名，但由于没有A的私钥，所以改不了，如果C用自己的私钥生成一个新的签名，B收到数据后用A的公钥根本就解不开。(来源于网络)

数字证书格式

数字证书格式有很多，比如.pem，.cer或者.crt等。

PKI工作流程

下图来源于网络，上半部分最右边就是CA机构，可以颁发证书。证书订阅人，首先去申请一个证书，为了申请这个证书，需要去登记，告诉它，我是谁，我属于哪个组织，到了登记机构，再通过CSR，发送给CA中心，CA中心通过验证通过之后，会颁发一对公钥和私钥，并且公钥会在CA中心存一份；证书订阅人拿到证书以后，部署在服务器；

（图来源于网络）

当用户（信赖方）访问我们的web服务器时，它会请求我们的证书，服务器会把公钥发送给我们的客户端，客户端会去验证我们证书的合法性。

客户端是如何验证证书是否有效呢？CA中心会把过期证书放在CRL服务器上面，这个CRL服务会把所有过期的证书形成一条链条，所以他的性能非常的差，所以又推出了OCSP程序，OCSP可以就一个证书进行查询，它是否过期，浏览器可以直接去查询OCSP响应程序，但OCSP响应程序效率还不是很高。

OCSP的全称是Online Certificate Status Protocol，即在线证书状态协议。顾名思义，它是一个用于检查证书状态的协议，浏览器使用这个协议来检查证书是否被撤销。使用Chrome浏览器查看https://www.baidu.com的证书详情，可以看到OCSP的查询地址：

（oscp 查询地址）

直接访问 OCSP 存在隐私和性能两个问题，一方面，浏览器直接去请求第三方CA(Certificate Authority, 数字证书认证机构)，会暴露网站的访客(Let’s Encrypt会知道哪些用户在访问Fundebug)；另一方面，浏览器进行 OCSP 查询会降低HTTPS性能，导致访问你的站点缓慢。

什么是OCSP stapling？正式名称为TLS 证书状态查询扩展，可代替在线证书状态协议（OCSP）来查询 x.509 证书状态。服务器在 TLS 握手时发送事先缓存的 OCSP 响应，用户只需要验证该响应的有效性而不用再向数据证书认证机构（CA）发送请求，说白了，服务器代替客户端去进行 OCSP 查询，缓存查询结果，然后在与客户端进行 TLS 连接时返回给客户端。

为了解决上面 OCSP 存在的2个问题，就有了OCSP stapling，由网站服务器去进行 OCSP 查询，缓存查询结果，然后在与浏览器进行 TLS 连接时返回给浏览器，这样浏览器就不需要再去查询了，这样就解决了隐私和性能问题。如 nginx 服务器有一个 ocsp 开关，当我们打开这个开关以后，会有 nginx 服务器主动的去 OCSP 服务器去查询，这样大量的客户端直接从 web 服务器就可以直接获取到证书是否有效。

listen 443 ssl;
ssl_certificate etc/nginx/ssl/xxx.com/cert.pem;
ssl_certificate_key etc/nginx/ssl/xxx.com/key.pem;

# 启用OCSP响应验证，OCSP信息响应适用的证书
ssl_stapling on;
ssl_stapling_verify on;

# 选项应指向CA的根证书
ssl_trusted_certificate path/to/xxx.pem;

#添加 resolver 解析 OSCP 响应服务器的主机名，valid表示缓存60s
resolver 8.8.8.8 8.8.4.4 216.146.35.35 216.146.36.36 valid=60s;

# resolver_timeout 表示解析超时时间
resolver_timeout 2s;

HTTPS 证书申请与颁发（自签）

使用 openssl 生成服务器端 RSA 密钥（私钥）证书

[root@VM_0_13_centos ~]# openssl genrsa -des3 -out server.key 1024
Generating RSA private key, 1024 bit long modulus
..................++++++
.......++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:
[root@VM_0_13_centos ~]#

这里输入两次密码：k8svip

RSA 私钥证书

[root@VM_0_13_centos ~]# cat server.key
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B9361AB192C57F19

wHYwg6gBko+JYLzhfRGmSoasuzYhXEzztCzr8/9PHqIfgDX7w/KHfneD7oTXBdmz
VziAV2+2lUqyw9CGbiFfD0TBrSW8nOV+ZAGWjcosgrVFhPNc/Lx287pSt3+XO3Aj
NC8LsvNmMhZiHqiX1mcZA2JdKopVZungRISCeLdPrGu6schxJICHCP/f3Sfw4aYq
Ag7oAQd/KWk7mOHm7xFM/jECjVaiuhMCOylP0v5lXp5l/tRU/uGmcogJJCy/he/l
KkrDloEQvgfdREmMK75Halhn8ybPjgiV6FjrrYgLVNvuRxAPawNxDqdxLzAxZm3Y
nj1lFsPzxaD+f88riufMn/AU8CSlr52BTmab1zSwJoXOCm0rZUa3RkHZGS5wWzRq
67S1UCaNQ7Sh6Skkf2oDaktBiYiz9lpEppd4bQQ0G7L0LisynyoRKXua1pyGpOBW
l+ndHePo/o7VVQxPuCm/m+ZxcB8npIORBecg9oWkbndLXfuFYEcXQCDqcDmmL3A4
qBaGRc/VItCec5iAoLzmZpCnVvr6nuR07I/yNujsoUoi5cUEDalrb3BIX4yZUne8
2T1oQ3vSl/qHAK0iH6Eewlq5jqd1wysUMj0WpgZBkgKeRyC/EniSJE3Lz1zxZrZU
WHGYmmDiq2W82k0YLpK5uS/Mo+XAhhcODiuK/9P0dZi/DGBCNqk8aHUNXashv/KG
SQDS7iMvZ2Hk2ME5OGp8etzHmjCJkV8H7799wV5GzSlSsYjCupx2toSLh94t7gLV
Qt2NzvNPvZkymo6SfPDlrXqWX4Ph0jAdrIViyWLaR10Xqe5mTbupQw==
-----END RSA PRIVATE KEY-----
[root@VM_0_13_centos ~]#

通过私钥创建签名请求的证书CSR

[root@VM_0_13_centos ~]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:CN
State or Province Name (full name) []:BeiJing
Locality Name (eg, city) [Default City]:BeiJing
Organization Name (eg, company) [Default Company Ltd]:k8svip
Organizational Unit Name (eg, section) []:k8s.vip
Common Name (eg, your name or your server's hostname) []:k8s.vip
Email Address []:k8svip@163.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:123456
An optional company name []:k8svip
[root@VM_0_13_centos ~]#

CSR 请求证书

[root@VM_0_13_centos ~]# cat server.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIB9DCCAV0CAQAwgYUxCzAJBgNVBAYTAkNOMRAwDgYDVQQIDAdCZWlKaW5nMRAw
DgYDVQQHDAdCZWlKaW5nMQ8wDQYDVQQKDAZrOHN2aXAxEDAOBgNVBAsMB2s4cy52
aXAxEDAOBgNVBAMMB2s4cy52aXAxHTAbBgkqhkiG9w0BCQEWDms4c3ZpcEAxNjMu
Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vh29C280/j1+V2m81t8R
/7yp+YGooiPcbdyJ1+TnVBOe5JOijaMQjMD4HFljW32/XITuw2UGf6hUgrH/c2fY
G5BAeAq/7PF3vkiVam6tcQkzoMQGm5Lk7R//VrGUhevm/5KdL093XNFjjHDpXjyB
yxQEHXJBYhEVIEX6YtWyvQIDAQABoC4wFQYJKoZIhvcNAQkCMQgMBms4c3ZpcDAV
BgkqhkiG9w0BCQcxCAwGMTIzNDU2MA0GCSqGSIb3DQEBCwUAA4GBALFrbZ0rn5Ul
kfe3mBmCQiQgv5gQwbcy9QmY3/nT6UsRPzxwGktstL75f6LAEXYM54UJozrcwbAq
7wKA5xwP1jTbiWR9syGWfrlkcnrOw0QLMiSupJh8zdXS9S+bINeT6jNMG36AsyUF
3Byd37YRkKqLZA6Jav1aWKa/nd/6OwTb
-----END CERTIFICATE REQUEST-----
[root@VM_0_13_centos ~]#

去除私钥口令

[root@VM_0_13_centos ~]# cp server.key server.key.bak
[root@VM_0_13_centos ~]# openssl rsa -in server.key.bak -out server.key
Enter pass phrase for server.key.bak:
writing RSA key
[root@VM_0_13_centos ~]# cat server.key
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQC7vh29C280/j1+V2m81t8R/7yp+YGooiPcbdyJ1+TnVBOe5JOi
jaMQjMD4HFljW32/XITuw2UGf6hUgrH/c2fYG5BAeAq/7PF3vkiVam6tcQkzoMQG
m5Lk7R//VrGUhevm/5KdL093XNFjjHDpXjyByxQEHXJBYhEVIEX6YtWyvQIDAQAB
AoGBAIkcAS/sx9yVyGcag7hL3EGS2T/xXgW/1BzJhwSMTTm8J1AlcsSGWA5gHRWV
7ponWSCF+vc8b+1dEZwWjtQWfkEOVrE9cBDT8uKuoUozcXVS5Hc4iE4TiCQZzhnb
TrS6jYqEU+5vBihgAgSa0yPJaBlRwY9nnzbWGdx0Pi1wW2GpAkEA7CPb6B37mESK
IQhT6Z9vG7CTq6qo7WVYg7Dxp6DNfC8krKSRQYSqodK4fRKz76mFSpf0FS9lLsCF
ICZPizk08wJBAMuIQEwYorgpvgjje78n68eNkNYs5Wu8Ld5KlnbY+sOXyHcIAVKX
QId2lUER0K5Bq92RohPtwnzNYIZXQ3heJY8CQDT0obc/KhHupO9dd7v3liomgidI
QVPjm2MFBlxqMkq8I8RXr3966e0aXWcnD5UadhrRUtqBY3aFlBUuoj39mUMCQQC7
0V7sGevGoJaB41JlYvR8MJIQYlvPoFZ/hDr3L2GwrtdJqHR3/6WHnBE9e7Ajrexo
SaTUWRqZSnihX9OeNtrXAkEAxlnVHMo0C1nmqioPbesbh1Gyy+FQ9xg+ERg4JMDn
IAZItYJPAWEJJpPbANXS/FH+xLcj3KtdM2Is/0k9Ec0/Cg==
-----END RSA PRIVATE KEY-----
[root@VM_0_13_centos ~]#

我们使用 openssl 生成服务器端 RSA 密钥（私钥）证书的时候，使用了 -des3 算法，使用了密码：k8svip，如果我们要想生成 crt 自签发证书时，需要把密码去掉，并且我们配置nginx时，使用的也是无密码的私钥。这里需要输入：k8svip 解密，得到 ssl 能加载的密钥。

生成自签发证书

[root@VM_0_13_centos ~]# openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
Signature ok
subject=/C=CN/ST=BeiJing/L=BeiJing/O=k8svip/OU=k8s.vip/CN=k8s.vip/emailAddress=k8svip@163.com
Getting Private key
[root@VM_0_13_centos ~]#

crt证书如下

[root@VM_0_13_centos ~]# cat server.crt
-----BEGIN CERTIFICATE-----
MIICgzCCAewCCQD4AZLRb4u6fTANBgkqhkiG9w0BAQsFADCBhTELMAkGA1UEBhMC
Q04xEDAOBgNVBAgMB0JlaUppbmcxEDAOBgNVBAcMB0JlaUppbmcxDzANBgNVBAoM
Bms4c3ZpcDEQMA4GA1UECwwHazhzLnZpcDEQMA4GA1UEAwwHazhzLnZpcDEdMBsG
CSqGSIb3DQEJARYOazhzdmlwQDE2My5jb20wHhcNMjAwOTEyMDYyODM2WhcNMzAw
OTEwMDYyODM2WjCBhTELMAkGA1UEBhMCQ04xEDAOBgNVBAgMB0JlaUppbmcxEDAO
BgNVBAcMB0JlaUppbmcxDzANBgNVBAoMBms4c3ZpcDEQMA4GA1UECwwHazhzLnZp
cDEQMA4GA1UEAwwHazhzLnZpcDEdMBsGCSqGSIb3DQEJARYOazhzdmlwQDE2My5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALu+Hb0LbzT+PX5XabzW3xH/
vKn5gaiiI9xt3InX5OdUE57kk6KNoxCMwPgcWWNbfb9chO7DZQZ/qFSCsf9zZ9gb
kEB4Cr/s8Xe+SJVqbq1xCTOgxAabkuTtH/9WsZSF6+b/kp0vT3dc0WOMcOlePIHL
FAQdckFiERUgRfpi1bK9AgMBAAEwDQYJKoZIhvcNAQELBQADgYEAG76SHZGNfpcE
0W2jCVIF4bSx3p9pNysMnS4bF6PZAoV/8eImaeU6X16V9CEopt71NFn9dZMjUVgi
k3MnxMFySZgCjKBc4sc8GmbSG302K/849OX8ZCVrcclWC0B82LY66yPipeDJTwBu
Tg9WIyBCZfgBsDEW0+qzuLhifdtgaC0=
-----END CERTIFICATE-----
[root@VM_0_13_centos ~]#

nginx 配置

server {
    listen 443 ;
    server_name k8s.vip;
    autoindex off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    ssl on;
    ssl_certificate root/server.crt;
    ssl_certificate_key root/server.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
    ssl_prefer_server_ciphers on;

   location  {
        index index.html;
        root data/nginx/html/;
    }
}

浏览器访问

TLS 报文报文分析

整体报文如下图所示：

SSL建立握手的目的是什么？

1. client 与 server 确认对方身份进行验证，防止第三方冒充，通过证书实现；

2. client 与 server交换session key，用于连接后数据对称加密传输和hash校验。

SSL 握手过程

1. Client 发送 ClientHello，指定版本，随机数（RN），所有支持的密码套件（CipherSuites），如下图：

因为我们的浏览器是多样化的，比如Chrom，比如IE，火狐，而且我们的浏览器在不停的变更，所以不同的浏览器支持的安全套件和加密算法，都是不同的，所以在第一步Client Hello中，主要告诉服务器，我支持哪些加密算法。

2. server 回应 Server Hello, Certificate, Server Key Exchange, Server Hello Done，如下图：

服务端在返回了Server Hello数据包之后，紧接着向客户端返回自己的证书和一个 Server Key Exchange报文，用于秘钥协商，最后再发送一个Server Hello Done告诉客户端SSL第一次握手结束了。

2.1 Server 回应 ServerHello，指定版本，随机数，选择 CipherSuites，会话ID（Session ID）如下图：

服务端发送Server Hello，告诉浏览器我支持的加密算法，以及服务器更倾向使用哪种加密算法的安全套件，服务器（nginx为例）会在这里，选择一套它最喜欢的加密套件，发送给客户端，如果想复用Session, 也就是说nginx服务器打开了 Session cache，希望在1天内断开连接的客户端，不用再次协商密钥，在这一步，它可以直接复用之前的密钥，所以第二步Server Hello信息中，主要会发送我们究竟选择哪一种安全套件；

这里的 session id，如果 SSL 连接断开，再次连接时，可以使用该属性重新建立连接，在双方都有缓存的情况下可以省略握手的步骤，server 端也会生成随机的 RN，用于生成 session key 使用server 会从 client 发送的 Cipher suite 列表中跳出一个，这里挑选的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。

2.2 Server 发送 Certificate 证书信息，如下图：

server的证书信息，只包含public key（公钥），server端会将该public key对应的 private key 保存好，用于证明 server 是该证书的实际拥有者，那么如何验证呢？原理很简单：client随机生成一串数，用server这里的 public key 加密(显然是RSA算法)，发给 server，server 用private key解密后返回给 client，client 与原文比较，如果一致，则说明 server 拥有 private key，也就说明与 client 通信的正是证书的拥有者，因为 public key 加密的数据，只有 private key 才能解密，目前的技术还没发破解。利用这个原理，也能实现 session key 的交换，加密前的那串随机数就可用作 session key，因为除了 client 和 server，没有第三方能获得该数据了。原理很简单，实际使用时会复杂很多，数据经过多次 hash，伪随机等的运算，前面提到的 client 和 server 端得 RN 都会参与计算。

这一步服务器会把自己的公钥证书发送给浏览器客户端，这个公钥证书中是包含证书链的，所以浏览器可以找到自己的根证书库，去验证服务器发送过来的证书是否是有效的。

2.3 Server 发送 Server Key Exchange，如下图：

Server Key Exchange报文，用于秘钥协商。

2.4 Server 发送 Server Hello Done，如下图：

服务器最后发送一个Server Hello Done告诉客户端SSL第一次握手结束了。

3. Client 发送 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message，如下图：

客户端在收到服务端发送来的Sever Hello Done包之后，开始验证证书的有效性，如果证书有效之后，才会继续进行这一步，验证证书有效性主要包括：证书链是否可信、证书是否吊销、证书有效期、域名检验。

3.1 Client 发送 Client Key Exchange 用于与 Server 交换session key，如下图：

client 拿到 server 的 certificate 公钥后，就可以开始利用 certificate 里的 public key 进行 session key 的交换了，客户端计算产生随机数字pre-master，并且用服务端公钥加密，发送给服务端，客户端以后具有自己的随机数A和服务端的随机数B，结合pre-master计算出协商得到的对称密钥；

3.2 Client 发送 Change Cipher Spec ，指示 Server 从现在开始发送的数据都是加密过的，如下图：

客户端通知服务器后续的新数据包都采用协商的秘钥进行加密通信。