TLS握手过程的深入思考（秋招春招面经）

有点难受吧。我投的安全岗，秋招面一个厂的时候突然问到了TLS。一直挖一直挖。这玩意其实一般后端面经都会有，。但是我没怎么重点准备这方面。。。或者说我太自信了吧，以为就算面到也能说上一些。因为这东西大一大二的时候就看过了。现在准备的基本都是渗透测试、攻防、护网相关的。没想到突然问TLS。好多都忘了。说不上很详细来。而面试官问的实在是太深了。直接把我吓到了。确实现在找工作面试挖的都很深。

算是收获了个教训了。我怎么就没好好准备这个呢。。。唉。

一定要重视基础。

TLS握手过程图

我们以一个单向认证过程为例。实际上还会有更复杂的。还会有双向验证的情况。抓包其实就能明白很多。建议还是自己抓包。能看得很清楚。这里说的只是一个比较简单的情况。其实大部分的博客说的都是这种情况。

TLS握手的简要步骤

这只是一个简单的例子 一个单向验证过程。应该也是个TLS1.2吧。实际的握手过程非常复杂。如果想最为深入的理解，应该查看原论文，查看有关数据，大黑书等等。并且自己用wireshark等抓包。

1.客户端发送 client hello消息

其中包含一系列的内容。TLS版本，加密算法集，随机数等。

2.服务器回应SSl内容

此时服务器回应server hello消息 其中也包括了TLS版本（共同支持的） 加密算法集 另一个随机数等

之后服务器还会发送Certificate消息 附加服务器证书

最后发送ServerHelloDone

浏览器（客户端）接收证书 确定证书是否真实。是否是受信任的证书颁发机构颁发的。

3.客户端交换密钥证书

客户端用证书附带的公钥，生成premaster secret（预主密钥），作为ClientKeyExchange消息发送。

服务器收到后使用私钥解密premaster secret。

然后客户端和服务器使用premaster secret 和各自的随机数生成相同的master ket（为什么相同，因为密码学 嘻嘻 这个其实就是对称加密的密钥 生成一个相同的密钥 就可以用来对称加密了）

浏览器发送ChangeCipherSpec消息，然后使用master key加密的Finished消息。

4.服务器交换密钥证书

服务器接收并验证。同样也给客户端发送ChangeCipherSpec和Finished消息。

浏览器接收并验证。握手完成。

总结

TLS1.2的大致过程：

TLS1.3

进行了优化。客户端上来就发送公钥。

其实我们还没有谈到双向验证的问题。之前是服务端发送证书给客户端验证 为的是验证服务器的身份。可是客户端的身份怎么验证呢？其实在客户端第一步发送时 就也可以直接发送公钥证书 服务器再验证。第二步 服务器返回hello消息 也带着自己的证书 客户端也进行一个验证。在这前两步 就可以做一个双向的验证。

衍生的一些思考

1.tls握手时 服务器返回公钥证书 ，是返回的公钥和证书，还是公钥证书？

这其实应该是个简单的问题。反正我是知道的。但是很多人容易搞混。总觉得公钥是公钥 证书是证书。

在TLS握手过程中，服务器返回的实际上是公钥证书，而非单独的公钥和证书。这个公钥证书是一个包含了公钥和其他相关信息的文件，通常由受信任的第三方机构（称为证书颁发机构，CA）签发。公钥证书的主要目的是验证服务器的身份，并确保客户端与正确的服务器进行通信。

公钥证书包含以下主要信息：

1. 公钥：服务器的公钥，用于加密客户端发送给服务器的数据或用于验证服务器发送的签名。
2. 证书持有者信息：证书所属者的身份信息࿰