详解SSL密钥协商过程以及SSL重协商

ssl 密钥协商过程详解

由于非对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。

SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图（摘自TLS协议）。

Client                                              Server

ClientHello                  ——–>
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<——–      ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                    ——–>
[ChangeCipherSpec]
<——–            Finished
Application Data            <——->    Application Data

简单的说便是：SSL客户端（也是TCP的客户端）在TCP链接建立之后，发出一个ClientHello来发起握手，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个ServerHello，这里面确定了这次通信所需要的算法，然后发过去自己的证书（里面包含了身份和自己的公钥）。Client在收到这个消息后会生成一个秘密消息，用SSL服务器的公钥加密后传过去，SSL服务器端用自己的私钥解密后，会话密钥协商成功，双方可以用同一份会话密钥来通信了。

五 密钥协商的形象化比喻

如果上面的说明不够清晰，这里我们用个形象的比喻，我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。

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

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

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

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

A: [我的秘密是…]

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

六 加密的计算
上一步讲了密钥的协商，但是还没有阐明是如何利用加密密钥，加密初始化向量和hmac的密钥来加密消息的。
其实其过程不过如此：
1 借助hmac的密钥，对明文的消息做安全的摘要处理，然后和明文放到一起。
2 借助加密密钥，加密初始化向量加密上面的消息。

但是，有时候也有遇到SSL重协商，那么遇到重协商失败时应该怎样处理，下面就以openssl为例，处理重协商失败的办法
1.使用openssl在tcp上建立加密通道
2.在7秒到14秒之间，随时有可能进行重新协商
3.协商过程中，C/S端不停止调用SSL_read和SSL_write

通过代码可以看出：
1.SSL_read/write首先检查是否需要重协商
2.需要重协商的情况下，检查业务读写缓冲区中是否数据，有数据等待处理完
3.业务读写缓冲区没有数据的情况下，设置RENEGOTIATE标志，从这个点开始SSL_in_init则判断成功
4.后面在读写之前，都需要先握手协商

结果：
1.s3_pkt.c中，ssl3_read_bytes产生unexpected alerts

跟踪分析：
1.客户端在发送client_hello后
2.准备接收server hello
3.ssl3_read_bytes收到的数据为业务数据

理论上这种事有可能的：
1.客户端发现读写缓冲区为空
2.进入重协商阶段
3.业务数据从server端发出
4.客户端发出client hello后，收到业务数据

openssl理论上应该可以避免该问题，继续跟踪。
====================================================================分割线

经过对代码的跟踪：
确定问题代码:
s3_pkt.c ssl3_read_bytes
在tls协商阶段，收到业务报文，此时只能是SSL_read调用，否则就向对端发送fatal alerts

if (s->s3->in_read_app_data &&
(s->s3->total_renegotiations != 0) &&
((
(s->state & SSL_ST_CONNECT) &&
(s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
(s->state <= SSL3_ST_CR_SRVR_HELLO_A)
) || (
(s->state & SSL_ST_ACCEPT) &&
(s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
(s->state >= SSL3_ST_SR_CLNT_HELLO_A)
)
))
{
s->s3->in_read_app_data=2;
return(-1);
}
else
{
printf(“ERROR(%s, %d): rr->type(%d)!!, s->s3->in_read_app_data: %d”
“, s->s3->total_renegotiations: %d\n”,
__FILE__, __LINE__, rr->type, s->s3->in_read_app_data, s->s3->total_renegotiations);
al=SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_READ_BYTES,SSL_R_UNEXPECTED_RECORD);
goto f_err;
}

现在客户端问题解决，服务端问题来了。服务端写send_server_hello出错了。 TLS_accept: error in SSLv3 write server hello B
=========================================================================分割线
由于服务端采用长度为0的定时器，开足马力的发送数据，此时出现这种情况：
1.S端调用SSL_write，生成了加密数据，但是socket对应的内核发送缓冲区满了，此时数据驻留在tls中
2.此时C端regegotiate，发送了client_hello
3.S端SSL_read读取到后，rwstate为SSL_READ，state进入SSL_ST_ACCEPT，调用handshake(ssl3_accept)
4.ssl3_accept状态迁移CW_SERVER_HELLOA，调用到ssl3_write_bytes设置rwstate为SSL_NOTHING，最终调用到ssl3_write_pengding，进行如下判断：

if ((s->s3->wpend_tot > (int)len)
|| ((s->s3->wpend_buf != buf) &&
!(s->mode & SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER))
|| (s->s3->wpend_type != type))
{
printf(“+++++++(%s, %d)++++++++++++++++++, len: %d”
“s->s3->wpend_tot: %d, s->s3->wpend_buf:%p, buf: %p,”
” s->mode:%d, s->s3->wpend_type: %d, type: %d, s->rwstate: %d\n”,
__FILE__, __LINE__,  len, s->s3->wpend_tot, s->s3->wpend_buf, buf,
s->mode, s->s3->wpend_type, type, s->rwstate);
SSLerr(SSL_F_SSL3_WRITE_PENDING,SSL_R_BAD_WRITE_RETRY);
return(-1);
}

5.函数栈返回，调用SSL_get_error获取错误，SSL_want_read和SSL_want_write检查rwstate为SSL_READ和SSL_WRITE，此时为SSL_NOTHING，严重错误
TLS上层断开
解决办法：
修改状态机，让写缓冲满进行握手为正常状态。（改库代码，太不友好）
看一下各个版本，其中有没有提到解决该问题的
解决办法：调用SSL_write在未成功前不放弃CPU，可能一定程度上会影响效率。这种情况是不修改库代码的最终选择。

相关搜索

• renegotiation
• ssl renegotiation
• 端口隔离的作用
• 监听端口的隔离
• 如何关闭ssl重协商
• ssl重协商漏洞
• 关闭ssl重协商
• tomcat关闭ssl重协商
• ssl协商过程