服务端与客户端建立https通信的过程:

一、认证:客户端第一次访问服务端时,要求服务端证明自己可被信任


1.证书:由服务端申请、第三方CA颁发的,存放在服务端的证书;

    证书包含:服务端的公钥、服务端的基本信息(明文)、CA的信息、签名(对服务端公钥、基本信息摘要进行hash计算得到hash值,然后使用CA的秘钥对该hash值进行加密后的密文)

SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。


2.证书作用:当客户端访问服务端时,服务端发送证书(给客户端检查)证明自己已在第三方CA登记,可被信任。

  参考:https://www.cnblogs.com/handsomeBoys/p/6556336.html

        https://blog.csdn.net/lwwl12/article/details/80691746     CA、根证书与数字证书

     https://www.cnblogs.com/fps2tao/p/10036910.html

     https://segmentfault.com/a/1190000002554673

 

注意:

2.1 客户端如何验证服务端发送的证书,证明服务端可被信任

  客户端需要事先安装第三方CA的根证书(CA中心颁发给CA中心自己的证书),该根证书下的所有证书都将被客户端信任。

   客户端拿到服务端的证书后,读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,

然后利用对应 CA 的公钥(CA根证书)解密签名,得到服务端公钥及其他信息;解密得到的信息与证书中公开的信息对比(),如果一致,则可以确认证书合法(即服务端被信任 ,服务端的公钥是其真实的公钥)

 

2.2 客户端可以要求验证服务端,同样,服务端也可以要求验证客户端 (这种情况较少,如金融服务要求验证客户端)

  原理基本相同,客户端有自己CA证书,访问服务端时,发送自己CA证书给服务端检查。

 

2.3 证书可以有第三方颁发,也可以由服务端自己制作(服务端自己颁发给自己的)。

  OpenSSL

 

二、密钥商定(TLS握手)

1.密钥商定:对称加密 + 非对称加密 

  得到通信加密的秘钥。

  参考:https://www.cnblogs.com/xiohao/p/9054355.html

2.开始使用商定的密钥https加密通信

 

附录: https 完整的认证+密钥商定过程

参考:https://segmentfault.com/a/1190000002554673

假设A与B通信,A是客户端,B是服务器端

----------- 加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。

A:我想和你安全的通话,我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。

B:我们用DES-RSA-SHA这对组合好了。
这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给A)。
目前没有别的可说的了。

A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)
(产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量(IV)和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)
我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)
注意,下面我就要用加密的办法给你发消息了!
(将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)
[我说完了]

B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)
注意,我也要开始用加密的办法给你发消息了!
[我说完了]

A: [我的秘密是...]

B: [其它人不会听到的...]

 

扫码关注我们
微信号:SRE实战
拒绝背锅 运筹帷幄