HTTPS--握手，证书及秘钥协商

Posted 2023-05-02

参考技术A 一、学习思路

二、HTTPS 协议层次

SSL和TLS为数据安全通信提供支持。

三、HTTPS设计思路

1、服务器生成公钥对A，把公钥和其他信息info发送给CA机构，申请证书；

2、CA机构，有一套自己的公钥对S，CA机构将info生成数字摘要，并使用S私钥对摘要进行加密，CA机构在操作系统系统有有一套证书，保存的是S公钥；

3、CA机构将info和加密后的数字摘要生成证书发送给服务器；

4、服务器进行https通信时，先发送证书；

5.6.7、客户端收到证书后，首先验证证书合法性，获取OS内部受信任的CA证书，使用OS公钥对证书摘要进行解密出hash值，再使用相同的hash算法对证书内容进行hash计算，比较两个hash值是否一致，一致则认为证书合法；

8、客户端验证证书合法后，client生成对称秘钥对，并使用公钥A将秘钥对加密，发送给服务器，之后的交互数据，则使用对称秘钥加密。（实际过程并未如此）

由此可见，整个HTTPS过程涉及到两对公钥对，一是用户加密数据通信的对称秘钥，放在数字证书中；二是CA机构的公钥对，放在OS内，用于验证证书是否合法

四、TLS握手

整个交互过程可以分为三个阶段：tcp握手，tls握手（明文或者密文），tls数据交互（密文）

tls握手用于验证双方及协商通信的加密秘钥。

一般的，tls握手过程是明文交互的，也可以使用RSA对称加密，双方协商一致就可以。

有三种情况的握手：

a、只验证服务器的SSL握手过程

b、验证服务器和客户端的SSL握手过程

c、恢复原有会话的SSL握手过程

下图展示了“a、只验证服务器的SSL握手过程”

注意，第4阶段，server key exchange是可选的，作为证书的补充

下列场景才会有server key exchange

协商采用了RSA加密，但服务器端的证书没有提供RSA公钥

协商采用了DH加密，但服务器端的证书没有提供DH参数

协商采用了fortezza_kea加密，但是服务端的证书没有提供参数

4.1、TLS会话缓存机制

为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS协议有两类会话缓存机制：

会话标识session ID和会话记录session ticket.

client -> server:  clienthello(session id)

server -> client:  serverhello, change cipher spec, encrypted handshake message

client -> server:  change cipherspec, encrypted handshake message

客户端再次和服务器建立连接，则在client中session

ID中携带记录的信息，发送给服务器。

服务器根据session ID检索缓存记录，如果没有检索到，则按正常的握手进行；

如果检索到，则返回change_cipher_spec与encrypted_handshake_message;

如果客户端能够验证通过服务器加密数据，则客户端同样发送change_cipher_spec与encrypted_handshake_message信息；

服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信；

4.2、客户端重连

客服端和服务器之间建立了有效TLS连接并通信；

客户端需要更新秘钥，主动发出client_hello信息；

服务器识别重建连接请求后，发送server_hello信息；

客户端和服务器开始新的重建连接过程；

4.3、服务器重连

客服端和服务器之间建立了有效TLS连接并通信；

客户端访问受保护的信息；

服务端返回hello_request信息；

客户端收到hello_request信息之后发送client_hello信息，开始重新建立连接；

五、证书

5.1、证书结构

版本：标识证书的版本（1,2和3）

序列号：标识证书的唯一标识符

签名算法：本证书所用签名算法

颁发者：证书颁发者的可识别名

使用者：证书拥有者的可识别名

公钥：证书发布的公钥

CRL：证书吊销列表，包含CA已经吊销的证书序列号及其吊销日期

证书策略：

使用者秘钥标识符

颁发机构秘钥标识符：用于证书链的验证

证书吊销列表（CRL）与证书状态在线查询协议（OCSP）

一般CA都只是每隔一定时间（几天或者几个月）才发布新的吊销列表，所以CRL不能及时反映证书状态。

而OCSP就能满足实时在线查询证书状态的要求。OCSP服务器会返回证书的三个状态：正常、吊销和未知。

在颁发机构信息访问提供了OCSP服务器地址 http://ocsp.wsign.com

浏览器在访问https网站是，先检查此证书是否已经被吊销，如果证书已经被吊销，则会显示警告信息： “此组织的证书已被吊销。安全证书问题可能显示试图欺骗您或截获您向服务器发送的数据。建议关闭此网页，并且不要继续浏览该网站。 ”

5.2、信任链

CA组织结构是一个树结构，一个root CA下面有多个mid CA，而mid CA又可以包含多个mid CA。

root CA和mid CA都可以颁发证书给用户，颁发的分别是root证书和中间证书，最终用户用来认证公钥的证书被称为end-user证书。

如果end-user证书是mid CA颁发的，那么握手阶段，需要把中间证书也一并发给客户端。

证书链验证过程：

六、秘钥协商过程

在TLS握手阶段确定了双方使用的密码学套件。

(秘钥协商、证书验证、数据加密是三个独立的过程)

举例：

TLS_ DHE_RSA _WITH_ AES_256_CBC_SHA

DHE_RSA ：表示握手过程中使用的非对称加密算法（秘钥交换用的是DHE, 证书用的RSA）,如果WITH只有一个，那么表示交换信息和证书用的是同一个算法

        （可选的主要的密钥交换算法包括:RSA, DH, ECDH, ECDHE。可选的主要的证书算法包括：RSA, DSA, ECDSA。两者可以独立选择，并不冲突）

AES_256_CBC_SHA ：表示加密信道的对称加密算法和hash算法

 

七、秘钥交换算法

双方在握手过程中，通过秘钥交换算法，确定后续通信的秘钥

常用的秘钥交换算法：RSA、DH类秘钥交换算法

7.1、RSA秘钥交换过程：

A->B

B：把公钥放在证书中

A：使用随机数算法，生成一个秘钥key，用公钥加密，发送给B。

RSA面临的问题：一旦私钥外泄（私钥参与了协商过程），那么key就能解密之前监听的所有的密文（向前不安全），安全性取决于私钥是否保存完好。

7.2、更安全的DH类秘钥交换算法

DH类秘钥算法有：DH, DHE, ECDH, ECDHE

DH(静态DH算法，秘钥交换始终选择相同的私钥，因此，每次的共享私钥都相同)

DHE(临时DH算法，每个连接生成一个临时的DH秘钥，因此同一秘钥永远不会被使用两次。向前保密)

7.3、DHE秘钥交换算法(基于离散对数难题)简单说明：

    A->B

    A：生成一个随机数X（作为自己的私钥），a= g^x mod p (g的x次方对p取模)，p 是个大素数，g是生成数，将a发送给B        

    B：生成一个随机数Y（作为自己的私钥），b= g^y mod p，将b发送给A。

   A: 计算 key1 = b^x mod p

    B：计算 key2 = a^y mod p

    根据数学逻辑，key1=key2,所以秘钥交换成功

DHE安全性体现在：传输的只是a、b、p、g,中间没有传输私钥x和y，在已知这四个数很难得出x和y（依赖于离散），保证了安全。

DH秘钥计算举例：

假设 g =10， p = 7，x = 3, a = 6，y = 11 , b = 5

key1 = ((g^x)mod p)^y mod p = ((10^3)mod 7)^11 mod 7 =6

key2 = ((g^y)mod p)^x mod p = ((10^11)mod 7)^3 mod 7 =6

7.4、基于ECDHE的秘钥交换算法（基于椭圆离散对数难题）

ECDHE的运算是把DHE中模幂运算替换成了点乘运算，速度更快，可逆更难

A->B

A：生成一个随机数Ra，计算Pa(x,y) = Ra * Q(x, y)，Q(x, y)为全世界公认的某个椭圆曲线算法的基点。将Pa(x, y)发送至服务器。

B：生成随机值Rb，计算Pb(x,y)= Rb * Q(x, y)。将Pb(x, y)发送至客户端。

A：计算Sa(x,y) = Ra * Pb(x, y)

B：计算Sb(x,y) = Rb * Pa(x, y)

算法保证了Sa =Sb = S，提取其中的S的x向量作为密钥（预主密钥）

HTTPS初始

https会话 1客户端 2服务器端

1 ---http三次握手--- 2

1<--------------->2 协商建立ssl会话 选择加密协议 sslv3

1 <------------- 2 服务端将自己的证书发给客户端

1 ............. 验证证书 安全性 完整性

1-------------->2 客户端生成一个随机的对称秘钥 将2的公钥加密后的堆成密码 发给服务器端

1 <----------- 2 服务端拿着秘钥 加密数据给客户端

协商成成密码：秘钥交换 IKE Internet Key Exchange

Diffie-Hellman 协议

A ----->B p,g (大素数，生成数)

A: x 自己内部生成

B: y 自己内部生成

A: g^x%p ------>B

B: g^y%p ------->A

A: (g^x%p) ^x=g^yx%p

B:(g^x%p) ^y=g^xy%p

不需要自己记密码了，每次发送生成一个新秘钥

光有这一点不行，密码自动生成了，无法验证B的身份

A用自己的私钥加密 特征码， 然后发送给B B用A的公钥解密特征码 能解密 身份验证了 。

B拿着同样的算法去计算这段数据的特征码。（单项加密）并比较A发来的特征码 如果一样 数据完整性一样。

A 随机生成一个数字 来对称加密整个信息，然后把这个数字通过B的公钥来加密

B拿到信息 先用自己的私钥解密A的数字 然后用 数字对称加密所有的信息

A为了传递给B的时候B可以认可， A就把自己的公钥提交给第三方机构，做公证。

第三方机构给A一个数字证书，里面有 A的姓名地址 公钥 ， 还有第三方机构自己的自签名证书

发证机关先计算 A的信息的 特征码 并且 把这个特征码用自己的私钥加密。 这个签名 可以用 第三方机构的公钥解密

这一切的一切的保证，靠的都是A的公钥。

证书

• 自签名证书
• 免费或商业证书

免费证书和商业证书本质上是一样的，都是可以被系统承认的证书，只是申请方式不同而已。

证书结构

配置一个HTTPS服务所需要的证书包括几个部分：

• Server Key（RSA服务器私钥）
• CSR（Certificate Signing Request） 证书签名请求
• CRT（X509 Certificate） X509证书

PKI public key infrastructure

公钥基础设施；PKI是一种遵循标准的利用公钥加密技术为电子商务的开展提供一套安全基础平台的技术和规范。

CA certificate authority

证书授证中心，作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

PKi 一共有2种

TLS/SSL x509

TLS SSL 都差不多

TLS transport layer security 传输层安全 tls v1

SSL secure socket layer sslv3

OpenGPG

X509证书包含了：

公钥及有效期间

证书的合法拥有者

证书该如何被使用

CA的信息

CA签名的校验码

各个扩展名

PEM - Privacy Enhanced Mail,打开看文本格式,以"-----BEGIN..."开头, "-----END..."结尾,内容是BASE64编码.

查看PEM格式证书的信息:openssl x509 -in certificate.pem -text -noout

Apache和*NIX服务器偏向于使用这种编码格式.

DER - Distinguished Encoding Rules,打开看是二进制格式,不可读.

查看DER格式证书的信息:openssl x509 -in certificate.der -inform der -text -noout

Java和Windows服务器偏向于使用这种编码格式.

这是比较误导人的地方,虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫"PEM"或者"DER",常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.

CRT - CRT应该是certificate的三个字母,其实还是证书的意思,常见于*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.

CER - 还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.

KEY - 通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.

查看KEY的办法:openssl rsa -in mykey.key -text -noout

如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout -inform der

CSR - Certificate Signing Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请,其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好.做过iOS APP的朋友都应该知道是怎么向苹果申请开发者证书的吧.

查看的办法:openssl req -noout -text -in my.csr (如果是DER格式的话照旧加上-inform der,这里不写了)

PFX/P12 - predecessor of PKCS#12,对*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥)这样会不会不安全？应该不会,PFX通常会有一个"提取密码",你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码,如何把PFX转换为PEM编码？

openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes

这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.

生成pfx的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt

其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.

JKS - 即Java Key Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫"keytool"的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS,不过在此就不多表了.

PEM转为DER openssl x509 -in cert.crt -outform der -out cert.der

DER转为PEM openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

(提示:要转换KEY文件也类似,只不过把x509换成rsa,要转CSR的话,把x509换成req...)