目录

一、问题描述

二、分析

1.curl工具定位

2.对比正常client连接过程

总结

---

一、问题描述

    对接某服务器过程中，对接失败，报错Handshake failure；server hello协商加密套件OK，如下
        Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)

    且server未发送server key exchange，存疑。

二、分析

1.curl工具定位

     抓包看内容较少，Handshake failure错误设计情况较多，选择curl工具trace定位具体问题：

curl -v https://xxxxxxx --cacert ca.crt --trace trace_connect.txt
-v 让 curl 在执行时输出详细的信息，包括请求和响应以及一些错误信息等
--trace  将所有的请求和响应、对应的报文内容输出到指定的文件中

      查看日志发现，报错ecc cert not for key agreement，应该是server选择的加密套件和certificate不匹配导致的，由于我们是client，需要分析为什么其它client无问题，是否哪里能力不支持。

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* ignoring certificate verify locations due to disabled peer verification
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* error:1411713D:SSL routines:SSL_CHECK_SRVR_ECC_CERT_AND_ALG:ecc cert not for key agreement

2.开源代码分析

        根据报错SSL_CHECK_SRVR_ECC_CERT_AND_ALG，找到ssl客户端连接代码中int ssl3_connect(SSL *s)，处理SSL3_ST_CR_KEY_EXCH_A状态时，使用ssl3_check_cert_and_algorithm校验失败；和之前发现server未发送key exchange消息对应；
        虽然在server处理代码int ssl3_accept(SSL *s)中未发现明显问题，但server未发送key exchange消息肯定还是和tls前期协商有关。

3.对比正常client连接过程

        对比正常client连接过程，发现，server优先协商的加密套件是TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384，由于client不支持该套件，其次才协商上了TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384，但可能服务器并不支持该套件；修改client支持起该套件后问题解决。

        加密套件定义位置：

        OPENSSL_GLOBAL SSL_CIPHER ssl3_ciphers[]={ }; 

总结

        介绍了curl工具协助定位tls连接问题，tcp连接报错Handshake failure可能原因是协商的加密套件存在问题导致。

---